Make user agent RFC 9110, add popularity contest, improve update check dialog - #8948

Small Nitpick:

How about using a tooltip to describe what the popularity contest does / sends instead of being on the dialog ?

Edit Edit,

Come to think of it i would like this to not be tied at all to the update check..

Perhaps we should have this instead be a button you can press on the dialog to report this way its a onetime report not every update check

two check boxes

That's an idea. I'll try it out and see what it looks like.

Please explicty show the data to be captured.

It woudl be nice to see im gonna send this info

"dfv1.24.0,linux,wayland,x86_64" or something like that to show exaactly what is sent.

Please explicty show the data to be captured.

It woudl be nice to see im gonna send this info

"dfv1.24.0,linux,wayland,x86_64" or something like that to show exaactly what is sent.

Nice idea.

Lots of places to use auto .

Can you add some initial translations for your new strings with google translate and tag the translation team to look at them .

I'll take a look.

My first issues here got lost in the long long

It was this. I see some issue with this

1. I can't be in the popularity contest and not have updates on ☹️
   • This is not ideal. These are two separate things and i could see a few reasons users may want to send popularity data without checking for updates. The most common being those who have deskflow via a package manager.
2. The popularity reporting is reported when you do an update check.
   • This is going to skew our data towards users who restart the app or reboot their machines being more popular. Just think of how popular my (or your) computer config will be if we were to turn on the popularity contest as is.

So what can we do to fix this....

• Popularity and Online check should be untangled.
• We should only report the install once sending the popularity info when the users presses OK on this dialog
• We need to remember this somehow or fingerprint the install we could use something like https://doc.qt.io/qt-6/qsysinfo.html#machineUniqueId to keep track upstream if an id has reported its version info and with that version info. To be fair idk how i feel about fingerprinting but the alternative of saving in settings can result in duplicate data if the user resets their settings this is the only approach i can see avoid that issue. However with both we can avoid sending data if we don't need as well as filter existing info from being used in our stats.
• We report X11 or Wayland, this can change per boot.. this just begs the question of collecting usage data.. Now are users ok with this... So we end up with more a slider of what can we share from NONE - Popular only - minimal stats - full usage. Cause one we find one data point that is useful you start to think about how others could also help.
  • This brings be back to initial concern of usage tracking and reporting at all. For us to use it we need to attach some kind of identifier for the install / machine. This is just more unnecessary breadcrumb that could be potentially used against the reporter by a bad actors. I am aware of how this sounds but all data points can tell you something.. Im not saying we would not sanitize any data we share, but am just saying if we store it its possible someone steals it from our db. This kinda of collection always give me pause its nothing about this patch at all.

• I can't be in the popularity contest and not have updates on ☹️

Fair point. The original idea was just a case of measuring the data that was being sent anyway. Was meant to be a nice little quick add on. Then the privacy discussion happened and things got complicated.

• The popularity reporting is reported when you do an update check.

The API only records it once and then ignores all further requests from that IP. Obviously not perfect, but I was just aiming for 'good enough'. I get that it's inefficient to keep sending it, so we could certainly have a setting state entry to record that it was sent. That'd need to be reset each time the version number changes (edit: or we record the version number in a popularityContestLastVersion state entry), as the version number is measured too. I can see that kind of server/client state management getting a bit complicated. (edit: maybe not if we use the popularityContestLastVersion idea)

Well you need to also be careful w/ using a state entry since those files are expected to just be removed sometimes. This is why I was thinking the route of a machineID then we send this w/ and we can then on server side see oh machine ID is has been using 1.24.0 now new version is 1.25.0 and we just say oh we seen machine:version so lets +1 the new version and on the server our check will now be machine:1.25.0. this way if they downgrade we can also look to track the numbers of users who have downgraded and from what version to what other one.

Ok, that's interesting. So instead of having the state management burden on the client side, we shift it over to the server-side where it's much easier to fix state bugs.

The trade-off is that we would be sending the request every time the GUI starts. Before I start making changes, are we on the same page?

No im saying you need to do both.. we don't want to send messages when we don't need to (client check) and we don't want to add messages from the same machine @ version to teh tally (server check)