Phoning home after updating firmware?

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 in a pull request, which will hopefully be merged before 1.0.4 is released. 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/client.conf
  • We have an official GDPR document which we’ll upload after it’s been reviewed — we’ll probably link to that from the Privacy panel in GNOME

Comments welcome.

Published by

hughsie

Richard has over 10 years of experience developing open source software. He is the maintainer of GNOME Software, PackageKit, GNOME Packagekit, GNOME Power Manager, GNOME Color Manager, colord, and UPower and also contributes to many other projects and opensource standards. Richard has three main areas of interest on the free desktop, color management, package management, and power management. Richard graduated a few years ago from the University of Surrey with a Masters in Electronics Engineering. He now works for Red Hat in the desktop group, and also manages a company selling open source calibration equipment. Richard's outside interests include taking photos and eating good food.

5 thoughts on “Phoning home after updating firmware?”

  1. 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.

  2. 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.

  3. 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

Leave a Reply

Your email address will not be published. Required fields are marked *