On Mon, 7 Jan 2019 at 15:34, Lennart Poettering <mzerqung@xxxxxxxxxxx> wrote:
>
> On Mo, 07.01.19 13:28, Matthew Miller (mattdm@xxxxxxxxxxxxxxxxx) wrote:
>
> > On Mon, Jan 07, 2019 at 06:24:14PM +0100, Lennart Poettering wrote:
> > > > * The Fedora community cares about privacy and is adverse to tracking
> > > > measures. We don't want to track; just count.
> > > Uh, so what's the story there? i mean, if you pass over the uuid you
> > > make clients trackable, regardless if you want to make use of that or
> > > not...
> >
> > Not if we don't keep them for long. One idea is to rotate them fairly
> > frequently. But this is mostly a statement of intent and might be more about
> > how we build the backend than about what we force in the client.
>
> Well, that's entirely intransparent to users, what fedora does with
> the uuid is entirely a blackbox for clients if you do it this way.
>
> I wonder if it is worth introducing an entirely new tracking concept
> here if you actually don't want to track but just count. The NTP
> approach has the benefit that you introduce no new tracking concept at
> all, but you just use the data that is pretty much generated
> anyway. It also makes this all feel less one-sided, after all you
> provide them with a deal: fedora gives the user correct time, the user
> is therefore counted.
The problems with NTP are the following:
1. The administrative headaches of regular
blocks/takedowns/ill-advised security emails because our servers are
attacking someone's box on port 123. [As funny as this sounds, getting
regular angry emails from some site whose security tool has decided
that 123/{tcp,udp} is a major threat still occurs. ]
2. NTP bandwidth while small per system grows a lot as you wrack up
servers randomly checking in. Having a pool of servers around the
world would require us to get NTP GPS clocks, getting the datacenters
to put the antenae out and a bunch of other items. [The budget for
this is non-zero.]
3. Logging NTP does not cover the problem the UUID is trying to help
solve.. there are two places where we undercount and overcount
systems.
a. systems behind nat firewalls all show up as 1 ip address. ntp or
yum or gnome-hotspot ask multiple times during a day.. but not a set
number. Just looking at my 3 home systems I see around 1 to 80
connections depending on what i have done that day.
b. systems on short lived dhcp ranges. multiple major isps use
various methods which make a system look like multiple boxes. The
system will show up as 123.45.67.89 and 2 minutes later the same
system will be 89.76.54.123 [made up ip addresses.. but various
carriers seem to do this.]
c. when ips are reused and nat'd (the nat over nat).. you combine a and b.
4. NTP is a high security problem when you concentrate it to a set of
servers. These become servers that everyone wants to hack even more
than build systems. These problems range from DDOS to active hacks.
5. Which leads to us being in charge of the security of every kerberos
and SSL session which relies on our clocks to be available and in
sync. That leads to other administrative headaches where sites will
complain that our servers broke one of those because the services was
DDOS'd, ASN rerouted, off by N amount, UDP replayed etc.
Most of the above except for 3 are solvable but would require
additional resources which have been hard to get in the past.
> > > BTW, afaik Ubuntu counts installations through NTP: they provide their
> > [..]
> > > Of course, doing it that way would mean fedora would have to host NTP
> > > servers...
> >
> > Hmmm. We have fedora.pool.ntp.org, in fact. I'm not sure who actually runs
> > that!
>
> That's fedora's allocation of the public NTP pool project, see
> https://www.ntppool.org/. That's hosted by all kinds of people
> voluntarily.
>
> I guess the question is if hosting an NTP server is more or less work
> than hosting a uuid counting server, and whether the privacy issues
> the uuid solution brings are worth it.
>
> BTW, iirc intel used to count installations through the http ping
> check in their captive portal detection. Fedora runs a similar service
> which is used by NM, no? maybe that's a nicer solution too: add a http
> header field to the ping check that each client sets to "1" on one of
> these ping checks a day, and "0" all other times. Then you count how
> many non-zero ping checks you get within a 24h window and you have a
> really good idea how many users you have. All without any explicit
> tracking. And again this appears to me is a much better deal to me
> than the uuid/dnf check that has been proposed, as you can say "we
> provide you with ping check functionality therefore we count you":
> both sides get something out of it.
We do this but have I have found it to have problems with the NAT over
NAT.. where we know a system should show up 288 times in a day.. but
have seen multiple class C where every IP address shows up 1-8 times,
but spread over a day. Are these groups of 255 systems only on for a
short time (which could be true with certain CI environments) or is it
1 system getting a short ip address lifetime?
I am not going to say that UUID is the only way to solve this
problem.. and am open to looking at other alternatives.
> (my educated guess is that mozilla might do the same actually, since
> firefox appears to have such a http ping check built in now too)
>
> Lennart
>
> --
> Lennart Poettering, Red Hat
> _______________________________________________
> devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
> To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
--
Stephen J Smoogen.
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
