I'd like to talk about adding an randomized, rotating UUID to DNF and rpm-ostree updates which we could use to better count installed systems. The IP-based counting we currently use is deeply flawed, and we'd really benefit from getting more accurate numbers.
This would
* let us make better strategic decisions based on our actual base of installed systems, and
* help us demostrate growth and impact to various sponsors.
To be completely candid: this would be incredibly useful as I advocate for Fedora within Red Hat, but no one @redhat has directed me to ask for it. And its *not* just Red Hat — this would be useful in talking to our various hardware partners too and other potential sponsors.
Long ago, we had Smolt, but this was opt-in and didn't present a very complete picture. I'd like to propose we do something similar to what openSUSE describes here: https://en.opensuse.org/openSUSE:Statistics. That is: A completely random UUID used only for this purpose, and used for counting rather than tracking.
We could refresh the UUID periodically (like monthly) to ensure that long-term tracking wouldn't even be an option (while still distinguishing between short-lived cloud or test instances). And of course there would be some way to opt out.
Recently Canonical has implemented a much greater amount of data collection https://lists.ubuntu.com/archives/ubuntu-devel/2018-February/040139.html, and while maybe we might want to look at reviving an opt-in system, I don't think we need that right now. (Historically, we've had a lot of resistance to similar proposals as opt-out, and the value of opt-in is low.)
Basically, all I want is that UUID plus CPU arch plus ID, VERSION_ID, and VARIANT_ID from /etc/os-release. (And, I'd also like to start using VARIANT_ID for labs, spins, docker images, etc.)
What do you think? Does the suggested plan make sense?
On Thu, May 3, 2018 at 4:39 PM, Matthew Miller mattdm@fedoraproject.org wrote:
I'd like to talk about adding an randomized, rotating UUID to DNF and rpm-ostree updates which we could use to better count installed systems. The IP-based counting we currently use is deeply flawed, and we'd really benefit from getting more accurate numbers.
This would
let us make better strategic decisions based on our actual base of installed systems, and
help us demostrate growth and impact to various sponsors.
To be completely candid: this would be incredibly useful as I advocate for Fedora within Red Hat, but no one @redhat has directed me to ask for it. And its *not* just Red Hat — this would be useful in talking to our various hardware partners too and other potential sponsors.
Long ago, we had Smolt, but this was opt-in and didn't present a very complete picture. I'd like to propose we do something similar to what openSUSE describes here: https://en.opensuse.org/openSUSE:Statistics. That is: A completely random UUID used only for this purpose, and used for counting rather than tracking.
We could refresh the UUID periodically (like monthly) to ensure that long-term tracking wouldn't even be an option (while still distinguishing between short-lived cloud or test instances). And of course there would be some way to opt out.
Recently Canonical has implemented a much greater amount of data collection https://lists.ubuntu.com/archives/ubuntu-devel/2018-February/040139.html, and while maybe we might want to look at reviving an opt-in system, I don't think we need that right now. (Historically, we've had a lot of resistance to similar proposals as opt-out, and the value of opt-in is low.)
Basically, all I want is that UUID plus CPU arch plus ID, VERSION_ID, and VARIANT_ID from /etc/os-release. (And, I'd also like to start using VARIANT_ID for labs, spins, docker images, etc.)
What do you think? Does the suggested plan make sense?
Yes. I think we should go forward with this.
josh
Definitly work a lot better than the current IP system. Every computer in the house behind my router I'm guessing currently counts as one? I've currently got 6 F27 installs right now...
Richard
2018-05-04 13:28 GMT+02:00 Richard Shaw hobbes1069@gmail.com:
Definitly work a lot better than the current IP system. Every computer in the house behind my router I'm guessing currently counts as one? I've currently got 6 F27 installs right now...
Richard
council-discuss mailing list -- council-discuss@lists.fedoraproject.org To unsubscribe send an email to council-discuss-leave@lists. fedoraproject.org
Just to make sure the privacy question has been discussed or we have a +1 from legal. EU has very restrictive privacy laws and cookies laws, and I think any kind of tracking is also a privacy question here in EU. The problem is we don't ask people if we are allowed to do that (like cookies).
On Fri, May 04, 2018 at 02:14:33PM +0200, Robert Mayr wrote:
Just to make sure the privacy question has been discussed or we have a +1 from legal. EU has very restrictive privacy laws and cookies laws, and I think any kind of tracking is also a privacy question here in EU. The problem is we don't ask people if we are allowed to do that (like cookies).
Yeah, I ran something very similar for upgrades by RH legal. Also, the fact that SUSE is doing it is a good sign for whether it meets EU law.
On Fri, May 4, 2018 at 10:51 AM Matthew Miller mattdm@fedoraproject.org wrote:
On Fri, May 04, 2018 at 02:14:33PM +0200, Robert Mayr wrote:
Just to make sure the privacy question has been discussed or we have a
+1
from legal. EU has very restrictive privacy laws and cookies laws, and I think any kind of tracking is also a privacy question here in EU. The problem is we don't ask people if we are allowed to do that (like cookies).
Yeah, I ran something very similar for upgrades by RH legal. Also, the fact that SUSE is doing it is a good sign for whether it meets EU law.
Vitally important and long overdue. Big +1.
-- Matthew Miller mattdm@fedoraproject.org Fedora Project Leader _______________________________________________ council-discuss mailing list -- council-discuss@lists.fedoraproject.org To unsubscribe send an email to
council-discuss-leave@lists.fedoraproject.org
On Fri, May 04, 2018 at 06:28:56AM -0500, Richard Shaw wrote:
Definitly work a lot better than the current IP system. Every computer in the house behind my router I'm guessing currently counts as one? I've currently got 6 F27 installs right now...
Yeah, exactly. And in large institutions it can be even worse at schools and large corporate networks.
On Thu, 3 May 2018 16:39:41 -0400, Matthew Miller wrote:
I'd like to talk about adding an randomized, rotating UUID to DNF and rpm-ostree updates which we could use to better count installed systems. The IP-based counting we currently use is deeply flawed, and we'd really benefit from getting more accurate numbers.
Basically, all I want is that UUID plus CPU arch plus ID, VERSION_ID, and VARIANT_ID from /etc/os-release. (And, I'd also like to start using VARIANT_ID for labs, spins, docker images, etc.)
What do you think? Does the suggested plan make sense?
What about forgeries?
On Mon, May 7, 2018 at 4:13 PM Michael Schwendt bugs.michael@gmx.net wrote:
On Thu, 3 May 2018 16:39:41 -0400, Matthew Miller wrote:
I'd like to talk about adding an randomized, rotating UUID to DNF and rpm-ostree updates which we could use to better count installed systems. The IP-based counting we currently use is deeply flawed, and we'd really benefit from getting more accurate numbers.
Basically, all I want is that UUID plus CPU arch plus ID, VERSION_ID, and VARIANT_ID from /etc/os-release. (And, I'd also like to start using VARIANT_ID for labs, spins, docker images, etc.)
What do you think? Does the suggested plan make sense?
What about forgeries?
Can you elaborate on what you mean?
josh
On Mon, 07 May 2018 20:15:56 +0000, Josh Boyer wrote:
What about forgeries?
Can you elaborate on what you mean?
Don't you fear computer vandalism? Script kids or other vandals exploiting an oversimplified counting mechanism to fake the statistics.
On 7 May 2018 at 18:17, Michael Schwendt bugs.michael@gmx.net wrote:
On Mon, 07 May 2018 20:15:56 +0000, Josh Boyer wrote:
What about forgeries?
Can you elaborate on what you mean?
Don't you fear computer vandalism? Script kids or other vandals exploiting an oversimplified counting mechanism to fake the statistics.
They can do that already by just flooding the proxy servers with valid looking requests for data. If the data turns out to be useless because of it, then it stops getting recorded. I don't think there is much we can do with publicly facing mirror servers which wouldn't be taken offline by 3 jerks and a small IoT botnet. [I don't think any of the projects could stand that either.]
The larger amount of problems will be how much of the data will report that it is a PDP-11, Vax740, long strings of uuencoded /dev/random, non-existant variants (Fedora Ubuntu variant), etc. But again I expect that Debian popcorn and similar tools have to deal with that as much as anything else.
In the end, the user is able to send whatever they want to the Fedora Project proxy servers.. we can choose what to do with that data to a point, but if they want to take us offline or jam some service.. they can do it now.
council-discuss mailing list -- council-discuss@lists.fedoraproject.org To unsubscribe send an email to council-discuss-leave@lists.fedoraproject.org
Adding a 'hard symmetrical 3-DES' replay resistant MAC (message authentication code, here) of the response data $STRING with a well known seed $SEED, whacked with a 'included in the reply' plaintext, time of post $EPOCH_SECONDS_SINCE_GMT seems a good way to cut down on IoT devices
$STRING $EPOCH_SECONDS_SINCE_GMT $3DES ( $SEED . $STRING . $EPOCH_SECONDS_SINCE_GMT )
We know $SEED, and can derive local $EPOCH_SECONDS_SINCE_GMT of course
On the receiver on post-process side, one could do a quick drop on posts more than 15 min off: $EPOCH_SECONDS_SINCE_GMT and if one seems to being over-run with forgeries, actually verify the $3DES decodes correctly for selected IPs
-- Russ herrold
council-discuss@lists.fedoraproject.org