4 ms·

Be careful what you wish for, this type of legislation may unintentionally prevent consumer level device modifications like rooting and custom roms which allow

Be careful what you wish for, this type of legislation may unintentionally prevent consumer level device modifications like rooting and custom roms which allow security researchers the ability to find these issues and basically restrict this to an NSA level of funding. If I were qualcomm that'd be my first response in order to minimize effort on my part. Ideally Google would just produce a version that was more directly update-able.

lvs 10y ago
First, a nitpick that the FCC makes regulation not legislation, and it could do this under existing authority. Second, I think a fine solution would be to force open the buildable source including all drivers and firmwares upon EOL. If top-down security updates will stop, then all components must be open source at that point.
- mjevans 10y ago
  All information required to build, package, and install; as well as a license for anyone using or working on affected hardware to the copyright and patents involved for use with affected devices.
- vanattab 10y ago
  Aside from one being voted on by an elected body and on and unelected body what exactly is the difference between regulation and legislation?
andrey_utkin 10y ago
I think qualcomm or anybody would have hard time justifying how rooting prevention (which actually already has some place) helps here. I hope this trend also eventually brings us proper no-bullshit free and open-source firmware. As long as there are organizations to request some sanity from vendors.
sbhere 10y ago
Disagree. How about a simple "devices selling in excess of 500 units must have security devices updates provided for four years from the first date of sale"? Legislation doesn't have to be onerous. Automobile manufacturers are required to produce parts for a certain number of years in support of their vehicles...
- ultramancool 10y ago
  > How about a simple "devices selling in excess of 500 units must have security devices updates provided for four years from the first date of sale"? Legislation doesn't have to be onerous. Even this is problematic, you still generate the a large incentive for the manufacturer to prevent reverse engineering of the device. If no one can find the exploits because the vulnerable firmware is not readable, the drivers are heavily obfuscated, etc, then they don't have to provide any updates and only dedicated actors with access to funds will have any chance at success. In order to prevent this you may have to make the legislation _more_ onerous and require the manufacturer releases to the owners the ability to sign updates and reverse engineer the device. Something like this needs very careful consideration not to create perverse incentives and to maintain competition and pricing.
- dlgeek 10y ago
  How frequently? What constitutes a security upgrade? Who defines what types of bugs qualify? Can I release an annual patch for 2 super-huge bugs (let's say kernel-level RCE) found in the 18-to-6 months prior to the patch release, and ignore data leakage bugs in that time frame as well as a kernel-RCE that was found only 3 months before my release and still remain compliant?
mtgx 10y ago
That's if the only goal is "security". But we're talking about updates here. I don't think updates and user flexibility are mutually exclusive. If you do modify your device in a way that it can't be guaranteed that the updates will secure the device anymore (which shouldn't be an issue for the vast majority of user modifications), then you simply lose that "warranty" for updates, or the company is no longer responsible to keep you up to date. But there are ways in which Google and OEMs can guarantee that for instance an OS image that's clean always resides on a locked-down partition, and that users can always "restore" their devices from that, no matter what other ROMs and whatnot they install on their devices and how many times they unlock the bootloader. The only exception to that may be people that tinker with the lock-down restoration partition as well, but for most custom ROM users that shouldn't be an issue. So this way 99.9% of the users can still be guaranteed updates, if they want them.
- ultramancool 10y ago
  > If you do modify your device in a way that it can't be guaranteed that the updates will secure the device anymore (which shouldn't be an issue for the vast majority of user modifications), then you simply lose that "warranty" for updates, or the company is no longer responsible to keep you up to date. I'm not saying that the updates must work on modified devices, I'm more saying that the incentive changes to preventing reverse engineering so that exploits don't happen and updates don't need to happen. Preventing that sort of user level modification, combined with heavy obfuscation and locked down firmwares does prevent reverse engineering by most amateurs and many professionals without a near-unlimited budget. If you can't read the executable for the IPC service, you can't reverse engineer it and you can't find exploits in it.
djsumdog 10y ago
Google needs to fix the broken AOSP model. I did a post about this a few months back (http://penguindreams.org/blog/android-fragmentation/ http://penguindreams.org/blog/android-fragmentation/), but the TL;DR is that Android needs to be a lot more like Windows: 1) Install the base, 2) install the drivers, you're done. It's a little more difficult with embedded hardware, yes. But Google could create a standard source-package format and cross-compiling tool-chains to simplify this process. Or they could do something like the VESA standard for x86 to ensure you'd always have a display. Google -> Manufacture -> Carrier is asinine. The first thing any power user does with a Windows laptop is wipe it, completely, and reinstall from his or her MSDN copy using the serial number from that laptop. Even non-power users still get all the standard Windows updates without any help from Dell, HP, etc (plus the bonus of bloat/spyware updates from said manufactures). Even if Google didn't want to retroactively do this, they could start with Android O. It's not really in their advantage to, as it works out better for them if people have to buy new shit they don't need every two years to keep getting security updates.

lvs 10y ago

First, a nitpick that the FCC makes regulation not legislation, and it could do this under existing authority. Second, I think a fine solution would be to force open the buildable source including all drivers and firmwares upon EOL. If top-down security updates will stop, then all components must be open source at that point.

mjevans 10y ago
All information required to build, package, and install; as well as a license for anyone using or working on affected hardware to the copyright and patents involved for use with affected devices.
vanattab 10y ago
Aside from one being voted on by an elected body and on and unelected body what exactly is the difference between regulation and legislation?

andrey_utkin 10y ago

I think qualcomm or anybody would have hard time justifying how rooting prevention (which actually already has some place) helps here. I hope this trend also eventually brings us proper no-bullshit free and open-source firmware. As long as there are organizations to request some sanity from vendors.

sbhere 10y ago

Disagree. How about a simple "devices selling in excess of 500 units must have security devices updates provided for four years from the first date of sale"? Legislation doesn't have to be onerous. Automobile manufacturers are required to produce parts for a certain number of years in support of their vehicles...

ultramancool 10y ago
> How about a simple "devices selling in excess of 500 units must have security devices updates provided for four years from the first date of sale"? Legislation doesn't have to be onerous. Even this is problematic, you still generate the a large incentive for the manufacturer to prevent reverse engineering of the device. If no one can find the exploits because the vulnerable firmware is not readable, the drivers are heavily obfuscated, etc, then they don't have to provide any updates and only dedicated actors with access to funds will have any chance at success. In order to prevent this you may have to make the legislation _more_ onerous and require the manufacturer releases to the owners the ability to sign updates and reverse engineer the device. Something like this needs very careful consideration not to create perverse incentives and to maintain competition and pricing.
dlgeek 10y ago
How frequently? What constitutes a security upgrade? Who defines what types of bugs qualify? Can I release an annual patch for 2 super-huge bugs (let's say kernel-level RCE) found in the 18-to-6 months prior to the patch release, and ignore data leakage bugs in that time frame as well as a kernel-RCE that was found only 3 months before my release and still remain compliant?

mtgx 10y ago

That's if the only goal is "security". But we're talking about updates here. I don't think updates and user flexibility are mutually exclusive. If you do modify your device in a way that it can't be guaranteed that the updates will secure the device anymore (which shouldn't be an issue for the vast majority of user modifications), then you simply lose that "warranty" for updates, or the company is no longer responsible to keep you up to date. But there are ways in which Google and OEMs can guarantee that for instance an OS image that's clean always resides on a locked-down partition, and that users can always "restore" their devices from that, no matter what other ROMs and whatnot they install on their devices and how many times they unlock the bootloader. The only exception to that may be people that tinker with the lock-down restoration partition as well, but for most custom ROM users that shouldn't be an issue. So this way 99.9% of the users can still be guaranteed updates, if they want them.

ultramancool 10y ago
> If you do modify your device in a way that it can't be guaranteed that the updates will secure the device anymore (which shouldn't be an issue for the vast majority of user modifications), then you simply lose that "warranty" for updates, or the company is no longer responsible to keep you up to date. I'm not saying that the updates must work on modified devices, I'm more saying that the incentive changes to preventing reverse engineering so that exploits don't happen and updates don't need to happen. Preventing that sort of user level modification, combined with heavy obfuscation and locked down firmwares does prevent reverse engineering by most amateurs and many professionals without a near-unlimited budget. If you can't read the executable for the IPC service, you can't reverse engineer it and you can't find exploits in it.

djsumdog 10y ago

Google needs to fix the broken AOSP model. I did a post about this a few months back (http://penguindreams.org/blog/android-fragmentation/ http://penguindreams.org/blog/android-fragmentation/), but the TL;DR is that Android needs to be a lot more like Windows: 1) Install the base, 2) install the drivers, you're done. It's a little more difficult with embedded hardware, yes. But Google could create a standard source-package format and cross-compiling tool-chains to simplify this process. Or they could do something like the VESA standard for x86 to ensure you'd always have a display. Google -> Manufacture -> Carrier is asinine. The first thing any power user does with a Windows laptop is wipe it, completely, and reinstall from his or her MSDN copy using the serial number from that laptop. Even non-power users still get all the standard Windows updates without any help from Dell, HP, etc (plus the bonus of bloat/spyware updates from said manufactures). Even if Google didn't want to retroactively do this, they could start with Android O. It's not really in their advantage to, as it works out better for them if people have to buy new shit they don't need every two years to keep getting security updates.