3 ms·

Security is topic that is definitely worth taking very seriously, and worse, it's in contrast with an industry fundamentally designed around planned obsolescenc

Security is topic that is definitely worth taking very seriously, and worse, it's in contrast with an industry fundamentally designed around planned obsolescence. I don't have estimates, but I think it's safe to estimate that there are millions of otherwise perfectly valid phones that either are in use, with serious vulnerabilities (in particular, bluetooth ones) and are not going to be patched, or have been thrown away because of that.

CrampusDestrus 3y ago
As long as smartphone device drivers are proprietary there will be an upper limit of how much a phone can be updated. Not to mention that Android and iOS get more computationally intensive each version way quicker than Desktop OSs do. Windows 10 from 2012 and Windows 10 today basically run the same. Sure, if most drivers were open source like on desktop linux we could tweak them to work with newer and newer Android versions, but what happens when AOSP gets a computationally expensive update (i.e. embedded ML voice recognition or realistic TTS)? then you would have to create custom versions of AOSP that only have the stuff a particular phone model can handle and this would create and unbareable ecosystem of poorly maintained distributions
- ryukafalz 3y ago
  > what happens when AOSP gets a computationally expensive update (i.e. embedded ML voice recognition or realistic TTS)? You disable those features on lower-spec phones or fall back to a low-resource alternative. If I'm on an older device that can only run eSpeak instead of a more realistic but expensive TTS engine? Fine, I'll run eSpeak! You don't have to bundle everything together into an image for each device. If you want to disable stuff, do it at runtime. Or if you really need to remove stuff due to storage limitations, have a small manifest that can be used to build an image with unused things excluded. This doesn't have to be "oh we need to make completely custom versions of the OS for each device", this is basically "install these packages, don't install these ones". Modularity!
arsome 3y ago
What percentage of those will actually be exploited in the hands of typical users? There's not exactly worm grade exploits flying around for these devices. Most of the vulnerabilities require you to be loading sketchy apps, many of these are checked on Play Store by scanners, so unless you get very unlucky or sideload sketchy apps, probably not a concern. Web view and most other network exposed components are updated from play store, since stagefright they sandboxed all codecs, etc. It's really not that bad for a typical user to just run an unpatched phone, certainly better than a Windows machine with local admin where downloading and running one executable is all it takes. At least on an unpatched Android device they get some level of sandboxing.
- johndavidback 3y ago
  I tend to agree here - of course security is a concern and the horror stories are just that, horrific, but how often (specifically on mobile) do they happen? And with such a significant amount of our personal data now on devices - photos, health, financial - if there were constant massive exploitation there'd be relentless pressure to improve.
- izacus 3y ago
  > What percentage of those will actually be exploited in the hands of typical users? There's not exactly worm grade exploits flying around for these devices. There have been large set of attacks against modems and media decoders that do not require any kind of app installation. iMessage is a constant source of iOS CVEs. Media codecs are a constant source of headaches in the Android world as well and they require a driver update to fix (since most of them are HW decoders). Pretty much all of the big security issues in the last year required no user interaction on Android or iOS to exploit.
- pizza234 3y ago
  > What percentage of those will actually be exploited in the hands of typical users? There's not exactly worm grade exploits flying around for these devices. In addition to the sibling post, Bluetooth is another attack vector. A phone I had to abandon in the past was a Nexus 5X, which I believe has a set of very serious Bluetooth bugs. I don't remember the details, but they were very easily exploitable (as in: either doing nothing, or just keeping the BT menu in the foreground, which is a common operation).

CrampusDestrus 3y ago

As long as smartphone device drivers are proprietary there will be an upper limit of how much a phone can be updated. Not to mention that Android and iOS get more computationally intensive each version way quicker than Desktop OSs do. Windows 10 from 2012 and Windows 10 today basically run the same. Sure, if most drivers were open source like on desktop linux we could tweak them to work with newer and newer Android versions, but what happens when AOSP gets a computationally expensive update (i.e. embedded ML voice recognition or realistic TTS)? then you would have to create custom versions of AOSP that only have the stuff a particular phone model can handle and this would create and unbareable ecosystem of poorly maintained distributions

ryukafalz 3y ago
> what happens when AOSP gets a computationally expensive update (i.e. embedded ML voice recognition or realistic TTS)? You disable those features on lower-spec phones or fall back to a low-resource alternative. If I'm on an older device that can only run eSpeak instead of a more realistic but expensive TTS engine? Fine, I'll run eSpeak! You don't have to bundle everything together into an image for each device. If you want to disable stuff, do it at runtime. Or if you really need to remove stuff due to storage limitations, have a small manifest that can be used to build an image with unused things excluded. This doesn't have to be "oh we need to make completely custom versions of the OS for each device", this is basically "install these packages, don't install these ones". Modularity!

arsome 3y ago

What percentage of those will actually be exploited in the hands of typical users? There's not exactly worm grade exploits flying around for these devices. Most of the vulnerabilities require you to be loading sketchy apps, many of these are checked on Play Store by scanners, so unless you get very unlucky or sideload sketchy apps, probably not a concern. Web view and most other network exposed components are updated from play store, since stagefright they sandboxed all codecs, etc. It's really not that bad for a typical user to just run an unpatched phone, certainly better than a Windows machine with local admin where downloading and running one executable is all it takes. At least on an unpatched Android device they get some level of sandboxing.

johndavidback 3y ago
I tend to agree here - of course security is a concern and the horror stories are just that, horrific, but how often (specifically on mobile) do they happen? And with such a significant amount of our personal data now on devices - photos, health, financial - if there were constant massive exploitation there'd be relentless pressure to improve.
izacus 3y ago
> What percentage of those will actually be exploited in the hands of typical users? There's not exactly worm grade exploits flying around for these devices. There have been large set of attacks against modems and media decoders that do not require any kind of app installation. iMessage is a constant source of iOS CVEs. Media codecs are a constant source of headaches in the Android world as well and they require a driver update to fix (since most of them are HW decoders). Pretty much all of the big security issues in the last year required no user interaction on Android or iOS to exploit.
pizza234 3y ago
> What percentage of those will actually be exploited in the hands of typical users? There's not exactly worm grade exploits flying around for these devices. In addition to the sibling post, Bluetooth is another attack vector. A phone I had to abandon in the past was a Nexus 5X, which I believe has a set of very serious Bluetooth bugs. I don't remember the details, but they were very easily exploitable (as in: either doing nothing, or just keeping the BT menu in the foreground, which is a common operation).