I think your average smartphone owner doesn't understand all this anyway. They look at their 3-year-old phone and say "it works fine and does what I need it to do", look at the new ones on the market and say "I don't see anything compelling there to justify that price tag", and so they don't buy a new phone. Most people don't realize that their phone has gaping security holes in it that will never be addressed.
Except many times the update will ask to expand its access to information in your phone it shouldn't need. So you choose between explicitly granting permission for unnecessary data access or don't update and hope you don't get owned via a vulnerability in that app.
So instead of finding someway to block or spoof a developer telling you they need different permissions, you'll wait around until some hacker breaks into your shit feeling like you beat the system?
In an imperfect system, you end up with imperfect solutions.
This is a tradeoff. Do I accept the developer demanding access they do not truly need, or do I accept the risk of a hacker gaining access to my phone through the developer's application?
If a hacker gains access to my phone through the developer's application, what do they gain access to? At the maximum (hopefully! unless they springboard to another hack and pwn your whole phone or other applications) they have what the application has access to.
Attack surface management is a lot more complex than just "always stay on the most latest shitware that the developer can shove down your throat"
Fully agreed. Running a smartphone and worrying about its security seems at odds. Rather, we should treat our "phablets" like public, insecure terminals, with "spy" sensors anyone can access given sufficient effort.
Security isn't as big of an issue with many of these devices as you might think. Unless it is years out of date, Play Services still gets updates, the system web view still gets updated, Chrome still gets updates, and in many cases the vendor will still roll out an emergency patch if there is something serious.
That's a huge guessing game, though - remember StageFright? You could have a phone with an up to date Chrome, up to date Play Services, and still be trivially exploited simply by viewing a standard video file. (Not to mention wondering which of your apps uses an out of date embedded web view)
I would submit that the number of people qualified to safely make (and update) that risk assessment is extremely small, and all of them would recommend updating to a version which patches problems rather than hoping you can dance around them.
StageFright was patched on a LOT of devices that "no longer received updates". The concern with embedded web views is overrated, as Android actually updates those via Play Services now.
For all of the talk of how awful this is, actual exploits are almost unheard of.
Whether or not security is important depends on what you do with your phone.
I don't use my phone for banking or payments and there are no compromising pictures or dangerous files on it. I don't have a pressing need for Android's latest security update.
Well, that's not a real issue, is it? It's purely a decision from the manufacturers to be assholes to their customers. There is no technical need that'd prevent them from creating updates. Especially Samsung (which also produces the SoC in-house for all relevant markets).
Hmm. It's all Google's fault. I don't have to wait for the manufacturer to update my Windows PC. Heck I was able to install Windows 7 on a Mac Mini without any support from Apple. Not to mention I updated a 9 year old Dell Core 2 Duo to Windows 10.
And whenever they broke that API, that actually happened — suddenly updates stopped being usable by your system.
Also, be aware that ARM has nothing to enumerate devices, has no BISO or UEFI. An OS image will only ever work on a single device.
As I detailed in another comment in this thread, the issue is this collision of the Linux concept of mainlining everything, short support windows, manufacturers that can't update drivers for every microchip they sell all the time, and Google and OEMs somewhere in there.
It's always been a clusterfuck, Google didn't create it, but they sure made it worse.
Windows driver API has been far from stable from Windows Vista. One of my computers came with Windows Vista (a 2009 Dell Pentium Dual Core - not the Core 2 Duo I referenced) and it still runs Windows 10.
Microsoft provided drivers for the standard PC hardware that was in my 2006 Core Duo Mac Mini and Windows 7 recognized all of my hardware - usb, sound, graphics, Bluetooth, Ethernet etc.
Microsoft goes out of its way to provide drivers for the most popular PC hardware. Mac OS is Unix (i.e certified by the Open Grouo) and doesn't have that problem.
Edit Rant:
But why are printer drivers still a thing? Apple introduced AirPrint for iOS 4 back in 2010 and for MacOS a few years later. I never have to worry about printer drivers when I update my OS. New printers bought in 2017 work perfectly with my 7 year old iPad without having to worry about drivers.
> But why are printer drivers still a thing? Apple introduced AirPrint for iOS 4 back in 2010 and for MacOS a few years later.
Have you looked at the unimaginable amount of crap a typical Windows printer driver forces upon you? It's not just the driver, it's usually also a stripped down license of some image editor, an "update agent" (because Windows 7 does not have an "app store" or a centralized driver distribution that does not phone home like Windows Update does and often enough carries fossilized drivers only), a toolbar for multifunction printers, a watcher that nags you to buy new original cartridges, a scanner agent because there is still no standard for scanning without drivers, much less so over network or cross platform, a selection of adware... and God help you if you have printers or MFDs from different vendors.
The only way to not have this ridiculous mess is buying enterprise printers - for example, the Z2100 plotter drivers are 4MB for Windows, and 16MB for the manager app, while the Photosmart printer driver can only be had as a part of a 145MB download, there is no such thing as a "driver only" package in the consumer space. In enterprise environments (or small offices) the situation sucks even more because you can't really deploy them via GPO, you have to extract the drivers by hand.
Your problem may be more your choice of vendors than anything else. HP's big printers (e.g. M600 family) are still pretty nice, but I've started to avoid them for anything smaller, and god help you if you look at the truly low print volume stuff from them.
HP printers are excellent in terms of hardware build quality: the Z2100 plotter in my company is a decade old, of which it stood 6 years around unused - gave it a full cleaning, new cartridges and heads a new carriage belt and it was back to mint condition. Oh, and there are still new cartridges and ink tanks made, and there are still recent drivers.
And for most of the consumer gear from HP it's the same: even for really old stuff you can find new tanks/cartridges, drivers for new and old OSes and I've yet to see a HP printer fail in a way I could not fix myself with a service manual.
The problem I always ran into was customers getting the consumer gear and wanting me to make it print from their server, with drivers only from HP and no support for server operating systems.
My response to anything HP that wasn't good-sized obviously-business-targeted printers became "I can probably make that work, but it's going to cost you more in my time fiddling around with it than just getting a more appropriate printer."
One area in which MS was lackluster upon drivers was some of their own products - for example the force feedback joysticks, still on sale at the time, never got a Vista driver out of MS and became a glorious paper weight overnight.
That and apart from an initial few months of unstable GFX drivers, was utterly solid.
On a side-note, I believe Core Duo2's was the last Intel chips to not include any form of inbuilt `management` silicon and as such,still favoured by some paranoid/security prudent types.
Have you looked at the unimaginable amount of crap a typical Windows printer driver forces upon you?
Yes. I go out of my way to run a clean crap free Windows PC. Even going as far as either buying from the business line of laptops or buying from the Microsoft store. But the minute I install a printer driver....
It's even worse for people like my parents, they search online for printer driver and usually end up downloading crapware from a third party site unaffiliated with the printer manufacture.
Check printer specs first and select something with built in PCL or (better) Postscript support. With native Postscript you may even be able to just get a PPD file as the "driver."
Won't help as much if you want color though, particularly inkjet color.
And for your parents, see if they're putting the current year on searches - on Bing and DDG that ends (or did end recently) in much worse results because the original sites often don't include dates but malicious ones have all the same keywords plus the year. In my recent experience adding the year meant > 90% malware results on the first page.
Google was much better about this a month or two back.
Still, Google could impose update requirements for Play Store access, for example.
Regardless of stable driver API or not, it is up to the OEMs to make it happen, if they actually cared about it.
I am pretty negative about Project Treble, it won't change anything, because only Oreo devices have it (0.3% currently) and OEMs are still expected to be the ones pushing the updates.
Why does the kernel and driver ABI matter for upgrading userland? On desktop Linux I can by and large use a new kernel and chroot into an old install, or vice versa, and things still work. It would seem that Android userland is unnecessarily coupled to a specific kernel version. It should be able to upgrade independently.
Agreed in principle, but a decent amount of the new security features present in more recent Android phones are due to new kernel features. It's just a sign of the relative immaturity of the platform that this is the case.
Can you provide some detailed examples of that being the case? Genuinely curious to know.
Usually I hear that sort of thing and think somebody isn't being creative enough with fallback behaviors for when the feature isn't there, but I guess it would depend heavily on what the feature is.
I guess I probably misspoke. I was thinking about https://android-developers.googleblog.com/2017/08/hardening-... ... but those certainly don't require userspace changes (probably). And even the case where you'd want the new kernel features (but can't upgrade due to driver ABI incompatibilities), they've backported to several old kernels that are in wide use in Android... though I note that my 2-year-old phone is on an older kernel than most of those features were backported to.
Your kernel brings in the device tree with itself.
It is primarily to allow the drivers linked in the kernel to detect whether they should load and try to talk to hardware. It doesn't replace bus enumeration when running on totally unknown hardware.
Basically yes, but that's often not good enough either. Lots of third party code OEMs end up with in their kernels, unmaintainable, and often incompatible with anything.
Well, it's not true that "ARM has no method to enumerate devices". It does have that; it's just that hardware manufacturers are bad at using it properly. (That's not to say it's not a huge problem; it's just that it's an economic/business/social one, not a technical one.)
I mean, it sort of does and sort of doesn't, but the hardware manufacturers just aren't used to thinking about things in the proper way. Just like the hardware is a black box with no user serviceable parts inside, as far as they're concerned the firmware (because that's still how they think of the OS and everything on it) is a single binary blob with no user serviceable parts inside, even if it's actually just linux and Android. And just like all the hardware parts are designed and qualified for a particular design, the same goes for the software: when you buy your hardware you get a software with it and that's that. As far as they're concerned it's just another component like a screen that gets customized to work with everything else and goes in the box, then is never touched again.
Maybe they pull the stuff Nvidia does: write an interface kernel module, then have the driver itself in a library that the module loads. Since the actual driver is never part of the kernel tree...
And courts have decided that it's not enough if you have some contributions to the kernel yourself or are a user to force them to release it, you have to have made significant contributions to force them to release it via the courts.
And Torvalds and the major kernel maintainers all refuse to enforce the GPL, and actively campaign against doing so.
It'd be a long legal discussion to properly answer your question, but luckily OEMs make it easy for us:
On most phones, there are zero external kernel modules loaded. The SoC vendor bakes it all into the ketnel, and the OEM gets the kernel as a blob. Which means all of it is subject to the GPL.
Yep, I had to go sleep (yeah, that dreadful thing!).
But this was my main area of attack. You compiled the drivers directly into the kernel. Making it all GPL. Now, as a strict reading, I have to have the device to make the request. That's not difficult. Ive phones from a lot of US named companies.
I just want the rights enumerated in the GPL as granted to end users. I'm no kernel maintainer. Just a cranky person who wants the GPL enforced as any license.
> I just want the rights enumerated in the GPL as granted to end users. I'm no kernel maintainer. Just a cranky person who wants the GPL enforced as any license.
Yeah, it turns out it’s not that easily enforcable. There are still court cases going on, but the current legal situation seems to be that unless you’ve contributed significant code to the kernel, you have no legal leg to stand on.
Because the OEM is simply saying "yes, we violated the GPL, and infringed the copyright of the developers", but the only ones who could sue against that would be devs that contributed significant amounts of code.
It doesn’t help that not every manufacturer (especially ones from China) don’t release the source code. And when they do, they sometimes contain opaque binary blobs that don’t tell you what is happening.
Your PC, including your Mac Mini, has BIOS/UEFI/other firmware with both boot-time and run-time services. Additionally, it has a hardware, whose sole purpose is to detect and enumerate all the other hardware.
Mobile phones and other embedded devices have none of this.
First, Google didn't design anything. They were looking for partners for their OS and these partners used their existing design. The first HTCs were almost identical between their Android and Windows Mobile versions.
Second, there are reasons why the embedded systems do not have them. Apart from increased complexity (bad for the designer and manufacturer), increased energy consumption (bad for consumer, and being a competitive disadvantage too), very few of both, embedded devices manufacturers and customers, even count on using other software than the one supplied. From the point of view, there every cent of saved costs on the device makes millions in margin, that would be wasted money.
Google didn't design the operating system? Microsoft didn't design computers either but they have been steering PC manufacturers for over 20 years since Windows 95 and the plug and play initiatives.
Google didn't design the hardware - when we are talking about firmware, booting, pci enum, etc, we are obviously talking about hardware. Their partners did and they reused their existing design.
Microsoft basically strongarmed the PC vendors - they either did what Microsoft said, or didn't ship Windows with their wares. Windows, which was the only game in the town, if you wanted to sell PCs.
Google didn't have such luxury when they started with Android. They needed to be everyone possible to be with them onboard and the "lets throw out everything you have and design new hardware from scratch" doesn't make for a good start.
In mobile, Microsoft also reused Qualcomm's reference design. But contrary to Google, they used ONLY Qualcomm's design, that's why their system looks united. All the WP phones are basically the same board.
So now almost 10 years later, what "other game is in town" that stops Google from taking more control over the hardware except either incompetence or neglect? You won't sell many Android devices that don't run Google Services in the West.
They do design their hardware now. See how they bought HTC.
However, that does not mean you will get an open device now. When was the hardware openness so important, that it played a major role in purchase decision at statistically significant rate?
For 99,999% of people, it doesn't. They want an appliance that works out of the box, without bothering with alternate firmwares. So that's what they are getting.
There's no motivation to put UEFI and PCI into the hardware, just like there wasn't 10-15-20 years ago, when the first designs were made.
This is a function of market share and customer loyalty, and thus Apples ability to tell carriers to f-off. iPhones will sell regardless whether the given carrier does sell them or not.
On the other hand, iOS updates do cause problems and then it's the carriers, who scramble to modify their networks to make iPhones work (remember when Brits didn't have mobile data for a few days after an update?). They would not do it for Xiaomi or Sony.
Apple rested control from AT&T and the few mobile carriers around the world that were selling the iPhone during the first year with less than 10 million devices sold. There was no reason that Google couldn't do the same. You even had to wait for Nexus updates back in the day that were sold by Verizon.
Apple already had loyal customers, who were ready to buy the devices without regard to mobile operators. iPhone was just continuation of computers and especially iPods.
Also true for Windows 10 Mobile. (My phone gets an update today, why doesn't yours?) Android is the only smart phone platform that carriers still have a say in.
That was not true for Windows 10 Mobile. Some devices never received the update.
What was indeed the insult on top of the injury - the WM devices were all Qualcomm Snapdragon devices. They were never so varied as Android devices are.
It was not true for Windows Phone 8, and therefore some carriers interfered with the deployment of the upgrade. It is true for Windows 10 Mobile, however. If a device is supported for Windows 10 Mobile, all updates are carrier independent. The "Upgrade Advisor" app Microsoft released to the Windows Store effectively allowed you to circumvent the carrier and upgrade to Windows 10 Mobile, replacing the Windows Update source for your phone with Microsoft's.
Ah, so that is how it went. I knew some devices WP devices (didn't note version) never received the updates.
However, the part about them all being the same Snapdragon devices with slightly different cases, cameras, etc. is still true. Microsoft doesn't have to solve how to make a release for Exynos, Kirin or Tegra devices.
The other neat thing they did which included WP8 was that their Developer Preview would do the same thing with the Windows Insider app. If you signed up for test builds, you'd get updates regardless of model or carrier, to the latest build offered. (And a lot of never officially supported phones can use Windows 10 via this method.)
That being said, this was only kindasorta a good thing, because it didn't always have working third party drivers attached. My old Samsung ATIV SE was super glitchy, particularly in the touchscreen department, when I upgraded my phone absent Samsung's blessing.
But it was one more place Microsoft kinda demonstrated even their mobile OS builds were more or less hardware independent, which is a huge contrast from Android.
They have no incentives to do so. I would like Samsung to make it into a business. Have folks pay 5 dollars per year if they want to get ongoing security updates for older devices. I would pay in an instant.
For reference Red Hat charges around $425/yr for extended support. Obviously the situation is different because Red Hat has a lot more software to support but they also have a fewer products and more customers that care enough to buy it. But I think the upshot is that a $5/yr extended support contract is a bit of a pipedream.
Just as an order of magnitude estimate we're assuming that it's about 100 times more effort to continue maintenance of a general purpose Linux based OS than a general purpose Linux based OS on specific set of hardware. And that's before you realize that the market for this support contract is just frugal IT people with specifc Android phones that haven't worn out from use. So not much luck with a 'we'll make it up in volume' analysis.
Google is maintaining Android so why would you assume it would cost massive amount of resources for Samsung to port or backport some security fixes now and then? The comparaison with Debian does not make sense.
I don't think not providing updates makes them assholes. Its just the reality of the traditional software model gradually becoming obsolete. They paid the developers to write software, and as a consumer we paid for that software. The cost of additional development has to be borne by someone. The success of the subscription model from biggies like MS, Adobe, Blizzard, SAAS startups, etc has shown that atleast one other model is viable. Its up to others' to show that there can be others.
I have a rooted device, so I can basically make apps do what I want and stop them from doing what I don't want. IMHO that's far better than Google's vision of "security" where they want to be in control and even consider the user an attacker.
