[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: fwupd / LVFS and user privacy

On 12 May 2018 at 16:48, kardan <kardan@riseup.net> wrote:
> I stumpled about this article[1]

I refuted most of this article, and being honest it's mostly just FUD.

> about LVFS which tells that fwupd.org
> is hosted on Amazon EC2. However a traceroute tells me fwupd.org answers
> from a scaleway cloud which belongs to the French Iliad
> telecommunications company[2].

The millions of daily metadata requests are handled by the CDN, which
used to be Amazon, and now is BunnyCDN (depending on how old your
fwupd is).  Firmware requests are handled by the scaleway server, and
for both we have a privacy policy here: https://fwupd.org/privacy --
I'm happy to expand on any bits that are unclear.

> According to a merge request the site is
> planned to be migrated to the Linux Foundation[3]. Please give me a
> hint about the current situation and if there is a timetable for
> the migration.

I don't know a timetable myself, but we're aiming for a gradual
transition over the next year or so. There now exists a LLC for the
LVFS to insulate the core Linux Foundation (like they do all their
projects) and we've addressed all but one of the pre-migration
technical issues, so it should happen at some point. I'm just waiting
for the LF to update the public keys with the new LLC name before

> There are several claims regarding privacy issues so I opened a bug
> report[4] to sort them out and check if fwupd is really affects user's
> privacy.

I'm happy to clarify anything, but I'd request you read the privacy
policy and the refutations in the FOSS post comments before you ask me
a specific question.

> The article also mentions a QA team auditing the .cab files. I would be
> glad to receive more information how this process works and if the
> reports are publicly visible.

The hardware vendors are "onboarded" by me when they start uploading
firmware, and they are restricted to the private and vendor-specific
embargo remotes. Once I'm comfortable they know what they are doing I
change the permissions so they can upload to testing and public which
is available to everyone. As part of the upload process any
non-required files are removed (with a few exceptions), the firmware
is signed using a detached signature, and the archive is repacked.

> Also I am confused about this blog post by System76[5], especially the
> opt-in to collect user's data without their knowledge:

I don't know why they said this. I think they were referring to the
optional opt-in post-firmware "success/failure" report which we use to
automatically disable firmwares with high failure rates, and also to
debug what's going to wrong on real hardware. We literally ask the
user on the console to confirm the entire JSON blob that's uploaded,
so I'm not sure how I can be more transparent...

>> If you want to use LVFS, disable the data collection. There’s no need
>> for it. Understand that the first instinct of the project leaders was
>> to unnecessarily opt-in data collection from user installations.

This is incorrect, and really below-the-belt all things considered.

>> Understand that you’re electing for your distribution to communicate
>> with third party servers. The more servers your distribution
>> communicates with out of the box (especially as root),

fwupd doesn't download anything as root; all metadata and firmware is
dowloaded in the session and passed to the daemon as fd's which are
then verified using either GPG or PKCS7.

> the more
>> surface area there is for vulnerabilities. Heavily scrutinize any
>> addition of a third-party server for updates.

The metadata (which is downloaded without opt-in in Fedora) is hitting
the CDN, and there are no logs kept or processed there. Distros are
free to mirror the metadata if they want.

>> Understand that if you are a company specializing in Linux-only
>> devices and considering using LVFS, you are handing your private
>> sales data to LVFS. We suggest hosting LVFS on your own servers.

You certainly can mirror the LVFS (and this is what we advise to our
more secretive customers using RHEL) but I really don't know what the
comment about sales data is all about.


Reply to: