Somebody made a proposal on the fwupd mailing list that the machine running fwupd should “phone home” to the LVFS with success or failure after the firmware update has been attempted.
This would let the hardware vendor that uploaded firmware know there are problems straight away, rather than waiting for thousands of frustrated users to file bugs. The report should needs to contain something that identifies the machine and a boolean, and in the event of an error, enough debug information to actually be useful. It would obviously involve sending the users IP address to the server too.
I ran a poll on my Google+ page, and this was the result:
So, a significant minority of people felt like it stepped over the line of privacy v.s. pragmatism. This told me I couldn’t just forge onward with automated collection, and this blog entry outlines what we’ve done for the 1.0.4 release. I hope this proposal is acceptable to even the most paranoid of users.
The fwupd daemon now stores the result of each attempted update in a local SQLite database. In the event there’s a firmware update that’s been attempted, we now ask the user if they would like to upload this information to the LVFS. Using GNOME this would just be a slider in the control center Privacy panel, and I’ll leave it to the distros to decide if this slider should be on or off by default. If you’re using the fwupdmgr tool this is what it shows:
$ fwupdmgr report-history
Target: https://the-lvfs-server/lvfs/firmware/report
Payload: {
"ReportVersion" : 1,
"MachineId" : "9c43dd393922b7edc16cb4d9a36ac01e66abc532db4a4c081f911f43faa89337",
"DistroId" : "fedora",
"DistroVersion" : "27",
"DistroVariant" : "workstation",
"Reports" : [
{
"DeviceId" : "da145204b296610b0239a4a365f7f96a9423d513",
"Checksum" : "d0d33e760ab6eeed6f11b9f9bd7e83820b29e970",
"UpdateState" : 2,
"Guid" : "77d843f7-682c-57e8-8e29-584f5b4f52a1",
"FwupdVersion" : "1.0.4",
"Plugin" : "unifying",
"Version" : "RQR12.05_B0028",
"VersionNew" : "RQR12.07_B0029",
"Flags" : 674,
"Created" : 1515507267,
"Modified" : 1515507956
}
]
}
Proceed with upload? [Y|n]:
Using this new information that the user volunteers, we can display a new line in the LVFS web-console:
Which expands out to the report below:
This means vendors using the LVFS know first of all how many downloads they have, and also the number of success and failures. This allows us to offer the same kind of staged deployment that Microsoft Update does, where you can limit the number of updated machines to 10,000/day or automatically pause the specific firmware deployment if > 1% of the reports come back with failures.
Some key points:
- We don’t share the IP address with the vendor, in fact it’s not even saved in the MySQL database
- The MachineId is a salted hash of your actual
/etc/machine-id - The LVFS doesn’t store reports for firmware that it did not sign itself, i.e. locally built firmware archives will be ignored and not logged
- You can disable the reporting functionality in all applications by editing
/etc/fwupd/remotes.d/*.conf - We have an official GDPR document too — we’ll probably link to that from the Privacy panel in GNOME
Comments welcome.
I would vote for “privacy issue”, but as most privacy paranoids, I don’t have a G+ account.
It’s great to hear that the system is being designed for privacy and with the GDPR in mind. It may hypothetically be illegal in some countries to own a certain type of device, and information about such a device could leak out through this type of report. The only privacy buzzwords you’re missing is differential privacy, but I’m not sure it could be used for anything but fuzzing the DeviceID.
Remember to erase the IP of the data subject from server logs as well.
I would like to have a comment on this. Lots of people could there be saying “Privacy issue.” But those people may not be in Google+ (for the same reason)..
So the percentage of people voted for “Privacy issue” may be much less than the actual number of people concerned about it.
Hi Richard,
I can see this being useful, but IMHO the report contains much too much information. If you read-up on guarding privacy and e.g. also the new EU laws on this (*), then the first rule is store only what you absolutely must store and nothing more.
The machine and device ids to me seem like guid-s here, which is not good. There is no need to identify a specific machine (duplicate reports should be rare), al that is really needed is e.g. updating the EFI firmware on an Asrock B150X Pro2S to version 1.234 failed/succeeded.
*) Which you are arguably breaking by sending in formation which can be used to (indirectly) identify a person
Regards,
Hans
We actually have a GDPR statement now: https://fwupd.org/privacy
I can’t see why it’s necessary to store unique identifiers if the purpose is only to tell how many success or failures there were to stop deployments in case of many failures.
I think this is too much information, but I can live with it as long as nothing is sent by default like the shady american style where silence equals to acceptance.
Also please do know that a poll about privacy issues that requires you to have a G+ account is worthless as many privacy conscious users are not using services from The World’s Biggest Advertising Company.
Came by this way from updating the BIOS on my Dell XPS9550, caught up on your blog, and read the sad news about the ColorHug+. Can’t leave a comment there, but this is perhaps closer for the point I want ot make. While an inexpensive, Open Source friendly spectrophotometer for color matching is a really cool thing, I have a feeling the LVFS is both more important and will have a larger and longer lasting impact on the world. You are the carrot to the stick of GPL enforcement for device manufacturers who want to (need to!) take advantage of open source to built cool devices. It’s one thing to tell manufacturers “You need to provide firmware security updates”. It’s another to follow that up with “and do that right over there, just like the big boys Dell and HP and …” Potentially solving the “Internet of Things – the ‘S’ tands for ‘Security'” problem can’t be overstated.
100% agree, thanks for writing this comment.
What’s the current default behavior? I’m not using gnome so there is no slider.
Tweaking /etc/fwupd/remotes.d/*.conf isn’t convenient as every fwupd update will wipe custom settings.
The files are marked as %config
I strongly believe, that participation in phoning home should be “opt-in” by the user, not “opt-out”. Debian does this right with the “popularity-contest”. During installation users are asked to participate, the default answer is “no”.
Btw.: If you ask e.g. on Diaspora* or any other social network with a more privacy aware community, you might get different answer than on G+ or Facebook.