Debian surely doesn't depend on Lenovo or Asus to release OS updates for my laptop. Apparently it's not "everyone else" that needs this but it's some sort of dependency for mobile (qualcomm?) devices
I have trouble understanding why this is different on mobile devices. People keep speaking of blobs but that doesn't seem to be a thing in laptop/desktop hardware, unless they mean something like the firmware running on your wifi card and uefi chip? But those can be interfaced with from any kernel version, afaik, so I don't get it
Debian does not write the whole software stack running everywhere on your system. So if you want your system to be "supported", as in, "if a security flaw is discovered in a firmware, I want it patched and I want my firmware to be updated", then you need whoever writes that firmware to do it.
That's a dependency: if you want your system to be secure, you depend on the software running on your system to be patched when a security flaw is published.
Interesting, so any security patches to kernel level and above (AOSP code, browsers, other apps) can still be fully up-to-date when the manufacturer says a device is out of support. Not sure I understand the fuss then that Fairphone had about selecting a SoC with long support. Really thought it was some sort of problem updating the kernel or other AOSP components when using manufacturer blobs
The attack vectors against this firmware are virtually always physical right? As in, hardware access in one way or another (including radio waves reaching the device), not something that can be routed over a (cell) network
Debian surely doesn't depend on Lenovo or Asus to release OS updates for my laptop. Apparently it's not "everyone else" that needs this but it's some sort of dependency for mobile (qualcomm?) devices
I have trouble understanding why this is different on mobile devices. People keep speaking of blobs but that doesn't seem to be a thing in laptop/desktop hardware, unless they mean something like the firmware running on your wifi card and uefi chip? But those can be interfaced with from any kernel version, afaik, so I don't get it
Debian does not write the whole software stack running everywhere on your system. So if you want your system to be "supported", as in, "if a security flaw is discovered in a firmware, I want it patched and I want my firmware to be updated", then you need whoever writes that firmware to do it.
That's a dependency: if you want your system to be secure, you depend on the software running on your system to be patched when a security flaw is published.
Interesting, so any security patches to kernel level and above (AOSP code, browsers, other apps) can still be fully up-to-date when the manufacturer says a device is out of support. Not sure I understand the fuss then that Fairphone had about selecting a SoC with long support. Really thought it was some sort of problem updating the kernel or other AOSP components when using manufacturer blobs
The attack vectors against this firmware are virtually always physical right? As in, hardware access in one way or another (including radio waves reaching the device), not something that can be routed over a (cell) network