Hacker News new | ask | show | jobs
by mixmastamyk 1238 days ago
Don't know much about it yet, and it is undoubtedly is a useful service. However looking at that page boasting telemetry and noticing an always running fwupd process running here as root it looks like this is probably leaking information thru its comm channel.

Does anyone know why this is running 24/7? I don't expect my firmware to be changing minute to minute. I need to get OpenSnitch running to keep an eye on these things, heard it was making it into Debian and hopefully derivatives soon.

3 comments

> this is probably leaking information thru its comm channel

It's really not. The fwupd process doesn't have any internet access at all -- all communication is done through a socket over DBus. All the telemetry is done with the user explicitly opting in -- we even show the JSON in the terminal that is going to be sent.

> Does anyone know why this is running 24/7

We auto-quit on idle or for low memory conditions -- unless you have hardware that's expensive (either in terms of power, or time) like thunderbolt and synaptics MST. The resident RSS is tiny as we mmap all the data files which can be paged out by the kernel -- we can even run fwupd on the tiny BMC processor as well. I'd be interested in what OpenSnitch says, but the D-Bus interface is the only way in and out. Interesting, the daemon doesn't actually do any policy actions itself; all actions have to be initiated by the front end -- which includes downloading new firmware metadata.

Good to know. Why is it a root daemon and not a command/library if other tools are directing it? If I had to guess, so the end user does not have to elevate to superuser to initiate actions?
Yes, mostly that. Depending on local policy, it might be possible to upgrade [only] signed firmware from the correct vendor without authenticating. Downgrade always requires authentication for obvious reasons. Most firmware requires you to be root (some even CAP_SYS_ADMIN) to just enumerate the hardware and read the firmware version.

The other main reasons is that some hardware is really, really slow (like 8 seconds to query a dock PD version, or 12 seconds to query a thunderbolt retimer version) and you can't really build a GUI that can do firmware update operations with potentially minutes of delay for each action. Also, cache invalidation is hard if you can't see the device uevents and usb hotplug events.

Now that I think of it, I don't want this happening without my approval/confirmation. Super password seems like a good way to gate it.

(Thought I'd seen a GUI for firmware but can't find it at the moment.)

Oh no "leaking telemetry". Heavens.

I think what yesterday's SSD discussion revealed is that an open database of "leaked" SMART data would be of immense value to users and should have happened years ago. It sucks that privacy derangement vetoes the development of things of real value.

> privacy derangement

Are you using this to refer to the attitude of companies that want to collect as much data as possible whether or not they have a clear and good use for it, or the attitude of users who are no longer willing to trust large-scale data collection efforts?

Chances are high that lots of people here are in fact working for said companies, delivering data collection tools, so there is that…
He works (or worked) for Google, and the experience gives many of his comments a warped perspective. Which is why I'm genuinely unsure where he's trying to lay the blame for the status quo that even well-meaning telemetry efforts cannot be trusted.
I don't really get where you think the well has been poisoned by Google or any others. Telemetry projects that I am familiar with at that company, like chromeos-wide profiling, are conducted with best in the industry privacy, and they result in a significantly improved experience for users.

Big Tech does not want your stupid private data. It is in all objective respects toxic waste. But they do want to know if your CPU is overheating, or your SSD is failing early, or if your programs run slowly. Telemetry is good and valuable.

> Big Tech does not want your stupid private data. It is in all objective respects toxic waste.

This is so obviously contradicted by the actual behavior of Google and most other tech companies, big and small. From the inside, you may see a clear distinction between telemetry and the truly creepy amount of personal data collection happening in other parts of the company. But you should have no trouble understanding how end users are less able to draw that distinction, especially when they are not offered the choice to only opt-in to some of the data collection and "personalization".

So, do you really think that a user being suspicious of large-scale data collection means they're deranged?

I'll decide that for myself, you insensitive clod!

I can imagine your future assault robbery trial. "But your honor, stealing his wallet was good for him! Couldn't get into the bar that night and gave his liver a well-needed break." :-D

On the bright side, you can finally mask it in latest Fedora without Software store going haywire and spamming you with useless error messages about it being unavailable.

Still waiting for that to arrive in next Debian…

I’m sure it’s useful to Dell users, but not much to anyone with DIY setups.

> Still waiting for that to arrive in next Debian…

This is the second comment I've noticed "waiting for it to hit Debian" and I don't understand.

  hbarta@olive:~$ apt-cache policy fwupd
  fwupd:
    Installed: 1.5.7-4
    Candidate: 1.5.7-4
    Version table:
   \*\* 1.5.7-4 500
          500 http://deb.debian.org/debian bullseye/main amd64 
  Packages
          100 /var/lib/dpkg/status
  hbarta@olive:~$

It's even on Raspberry Pi OS and I wonder if it serves any purpose there. Pi firmware is updated via APT unless I misunderstand what I see getting updated (raspi-firmware). Would fwupd handle updates for USB connected devices such as SSDs?
Sorry, I should’ve worded it better.

I’m waiting for fixes to Software center, so that there are no visible side effects after masking fwupd. I do know this was addressed in or before Fedora 37, but is an issue in current Debian stable.

The only time I saw fwupd itself working is when it attempted to update uefi firmware in my VM :)