Even in the low-end/unbranded devices, I'm seeing a gradual removal of hardware features and general lack of parts (screens, cases, etc.) availability, while replacement parts for models several years old are still plentiful.
So that left me switching between a budget of about 60 MB for games and unnecessary apps, though I can squeeze in a little more by clearing all the caches.
Now suddenly Samsung bugs me to update to the latest version of Android. The new update would take up hundreds of megabytes. My space was already highly limited.
I eventually gave in to curiosity and updated to Lollipop. The phone became unusable because I didn't have the space to install the apps I needed.
Phones keep losing features like micro SD (and like end-user replaceable batteries) because too many purchasers do not value those items highly enough to refuse to buy any phone that lacks an SD card slot or a user-replaceable battery.
Start refusing to buy any phone which lacks a micro SD slot, and the manufacturers will bring back the micro SD slots (granted, purchasers need to send the makers feedback that they refused to buy phone X due to lack of a microSD (and lack of a user replaceable battery)).
But buying a phone (any phone) which lacks one or the other simply signals to the makers that it is ok to drop those features, because the phone still sells.
I bought a brand new Android phone about 4-5 months ago. It has both a microSD slot (now holding a 128G SD card) and a user replaceable battery. I picked it because it had those features and I valued their presence. If enough others would get fed up with the lack of one or both, and start refusing to buy any phone without one or both, things would turn around.
And this is exactly the problem. That no one cares. If enough cared, the first phone without a jack (iPhone, right?) would have been a sales flop, and maybe the message would have gotten back to leave the jack in the phone.
Instead, it sold, which tells the makers that dropping the jack was no big deal, people still bought it anyway.
The entire thing is a shit storm, every player seems to be against the end user (that is paying for everything, go figure). There's a protection racket on the form of patent rights enabling the shit to go on, but it can not reasonably survive on this shape for very long.
Valid point, but the apps may just be refusing because most phones don't have an SD card anymore, and the authors are either being lazy or don't care (I don't know which) and simply failing to code in support for something they think seldom exists anywhere.
Although in my case, all my apps that I care about using the SD card are using the SD card. But then again I have 98% FDroid apps installed, so those may just be better behaved apps.
Ahhh Android - I only use iOS because I hate it slightly less
Example: Last time I updated my iPhone, the music app got an update and now they are trying to shove iCloud down my throat. Not to mention needless UI changes when I was more than satisfied with how it was before.
I think what needs to happen across the industry is a complete decoupling of “feature” from security patching. Too many people are exposed because of exactly the kind of unwanted UI upgrades you describe.
Security is used to euthanize perfectly working systems and harass users for money. Security has become dangerous for the user in that aspect.
That's a cynical and paranoid mindset. Bloat is a lazy tendency not a malicious evil and developers tend to optimise for the latest and greatest if left unchecked and forced to consider backwards compatibility.
> Better have a bricked phone but secured phone?
lets just say don't do any financial transactions on the device or appreciate the general openness of your phone to malicious actors who might use it for nefarious purposes.
As a user, do I care whether my phone is unusable because the developers wanted specifically to render older hardware unusable or whether it was just through their negligence in failing to consider older devices? Stupidity or malice, the result is the same.
lets just say don't do any financial transactions on the device or appreciate the general openness of your phone to malicious actors who might use it for nefarious purposes.
I keep hearing this, but what's the actual presence of malware on Android? If you're not installing shady apps from the Play Store, what's your actual level of risk? Android, even old versions of Android, are far harder to reliably exploit than say, unpatched Windows. As long as you're not installing free-to-play flashlight apps that require every permission under the sun, I'd say your exposure to malware on Android is far less than it is on PC. For the average user, they're still probably better off conducting financial transactions on their phone than conducting those same transactions on their malware ridden laptops.
Yes but whether we attribute the intent to stupidity or malice is important as per the general health of our thought process. Its likely laziness combined with malice when its noted. I imagine a dev getting up in arms about package size and then when the issue is raised its not given high priority because someone twigs the convenient side effect. That's the worst case.
Either way the mindset of paranoia is warped and self centred. Its not because they're thinking of forcing you to upgrade its more because they're _not_ thinking of you and instead the wide-eyed new sales opportunities that ship with greater disc space.
> I keep hearing this, but what's the actual presence of malware on Android?
oh wow, you're gonna play this game? I could tell you that its perfectly safe to trace the outline of a cliff with your feet and in many, many cases its going to be absolutely fine until the one case where the earth gives way and its not.
Let me put it this way; when I see the tagline:
> there are over a billion outdated Android devices
my first thought is:
> what's the most effective exploit to tap into that market?
the existence of security flaws encourages action and the hubris of not updating is the clarion call to those that exercise the exploits.
> I'd say your exposure to malware on Android is far less than it is on PC
This. What is this? This is complete conjecture. Get out of here.
> > what's the most effective exploit to tap into that market?
So??? What is it? Do let us know.
I'd venture to say that the fragmentation of that market makes it reasonably secure. Just like how the average router is incredibly insecure, and yet you don't advise people to avoid e-banking and just deal with their money in paper form and through face-to-face contacts.
Yes, you are technically right. But @quanticle is right, in practice: unless those users do some very stupid shit, they're pretty safe doing ebanking on their phones. (and those who do the "very stupid shit" are likely to do it on their computers, too)
I'm not claiming that Android is safe. Nothing is safe. But it does security professionals no good to be alarmists. If we cry wolf about literally every technology that ordinary people use, the result is not people giving up technology. The result is people ignoring security professionals.
If an ordinary user came to you and asked, "Where should I do my banking? On my phone or on my PC?" what would your answer be?
I wish I could quantify that. It's a hard task. But the store is not the only possible vector. On an old Android you're running a very outdated version of Chrome when looking at any pages / ads. That would be the most exposed/insecure element in the system.
The same is valid for the system WebView, but "only" since Android 4.4. It is updated via Play Store, independently from the base system.
> As someone who goes as long as possible without performing updates
I take that to mean without updating the apps either, not just the os. I've seen people reject any kind of upgrades.
You should rather hope for GNU/Linux phones. Linux devices (without the GNU part) is most of the time, just another locked device (see your Android phone, router, TV, etc).
The presence of GNU software pieces (or any software licensed under GNU [LA]GPL v3+) ensures the device is free of locks (or with user breakable locks).
That's not true, as the Linux kernel is still GPLv2. So while you could swap out the userspace GNU utils, the device manufacturer can still lock the bootloader which is perfectly fine with the GPLv2.
Even if the bootloader is unlockable (e.g. LG allows this btw), you will most likely be stuck to a specific kernel version due to proprietary binary blobs which nearly every phone uses.
So instead of a GNU/Linux phone, you should rather hope for a phone with complete open source drivers (or a GPLv3 kernel).
Yeah, probably. But the presence of packages like GNU libc can make it harder for the manufacturer to lock the device.
> ... kernel version due to proprietary binary blobs which nearly every phone uses.
Sadly, binary blobs are always an issue. In the case of Linux, this happened because many Linux developers don't care about binary blobs. If they did, you won't see any binary blobs (as it is a violation of GNU GPL).
> ... with complete open source drivers
My main point was to quote that 'open source' doesn't solve these issues. We should take software freedom more seriously.
> ... (or a GPLv3 kernel).
I wish we will not have to wait until the human civilization end in fire to see this.
It is mostly users, not developers, who don't care about binary blobs. The users then take the "pragmatic" approach of using binary blobs, but hey, stuff works for them.
See also the Nvidia binary driver. Who is the advocate for that? Users (hey, never had a problem and it runs my apps very well) or developers (whoa, we cannot develop Wayland/etc with this)?
Partly yes, but mostly No.
You are right that most people don't care about binary blobs. But the people who can enforce this are the developers. If all developers agree and enforce this, no on can include binary blobs in Linux kernel.
Also it would be wrong for a mere user to try to enforce it by law, because it might piss off the developers, which is really bad. Also, it might not withstand in court because the developers don't care.
> The users then take the "pragmatic" approach of using binary blobs, but hey, stuff works for them.
"pragmatic"? Most of us are concerned about our immediate problems, and thus we end up with temporary solutions (most of the time), sometimes because we don't have choice, sometimes because that's easier.
I recently got an ASUS eeepc which doesn't have graphics support, because when it was first released, the only support was a binary blob, which is now abandoned.
We will eventually face issues with these binary blobs, for sure. As we know, each day, new vulnerabilities are being surfaced.
But yeah, most of us won't care, until and unless something happen. But by then, it will be too late. Just like how many of us consider the importance of time only when we know we don't have enough.
So I don't think it is "pragmatic" in long term.
And yet, it is the users who have the ultimate power over developers of such hw/sw. No, not courts, that's the entirely wrong solution.
Such solutions are being developed only because there's money in it. It is only up to the users, whether this factor is true or not. If they care about sources, they would not purchase hardware that requires blobs. If they don't care, and reward the developers with their money for the blobs, whose fault it is?
glibc is LGPL, so I don't see how that should change anything?
> (as it is a violation of GNU GPL).
IIRC it's a gray area.
glibc requires libgcc, which is GPLv3 (with runtime exception). The same for libstdc++.
The kernel really is the problem here and where there's no GPLv3 code used at all.
I think what you're arguing is that Android isn't GNU/Linux or that Android isn't libre like what we've come to expect from desktop distributions of Linux.
Librem 5, the phone that focuses on security by design and privacy protection by default. Running Free/Libre and Open Source software and a GNU+Linux Operating System designed to create an open development utopia, rather than the walled gardens from all other phone providers.
What's the worse that could happen?
When your device is compromised by hostile actors I guess it depends on what your nightmares are, but getting framed for child pornography and/or blackmailed for it is a popular one. Or getting your cloud accounts hijacked and all your stuff compromised. Or getting the bad guys access to your employer's network. Etc.
Collectively a widespread Android device botnet could take down a lot of infrastructure, or start a war, or ruin everyone's days with ransomware. I'm sure more imaginative people have thought about it.
2. Ability to throw a fully persistent implant onto the device (via Wi-Fi exploit + pivot to AP kernel exploit)
I'm all for trusting computing devices to act as one's agents, but attempting to do so with anything resembling a modern mobile phone is barking up the wrong tree.
Even though just having one means taking the location-tracking hit from negligently designed cellular protocols, further exposure can be mitigated by using these little snitches for as little personal activity as possible.
I already explained a mechanic of causality whereby assorted end nodes being owned up actually increases our security, as it helps keep at bay the simplistic/totalitarian philosophy of tracking/controlling communication. But don't let that get in the way of the malunderstanding that is ultimately driving this nebulous desire for promised "security".
How is that number changed by not using public wifi?
Porn sites are not where most malware comes from. Ad networks are. I've had more attempts at virus and malware installs from 'legitimate' sites that have had poor control of their banner ads.
>How is that number changed by not using public wifi?
You are, quite falsely, assuming that non-public wifi, say your friends house, is any more protected.
"Not significantly" would be a valid answer to the second question. However, you seem to be answering "are home routers entirely secure?", which wasn't my question: my question was about real-world risk levels (i.e. "_are_ public wifi points significantly more likely to deliver threatening payloads", not "_could_ they be").
I'd still be interested in an answer to the main question.
An impersonal passive botnet would likely do less damage than status quo "apps" that are built to siphon as much personal data as possible.
Never mind these few Mifi devices that I have - default configs that listen on wan telnet with static passwords! Well known domestic manufacturer, not worth attempting to report - the manufacturer obviously did not care, has long moved on, and there's countless other models with the same problem.
The panacea of every node being secure with an identifiable owner fell apart long ago. You can either cling to that belief in a fundamentalist manner (and prop up the totalitarians who wish to track communication ever more). Or you can work on understanding how non-technical people actually attempt to moderate their own exposure to these insecure-by-design surveillance devices.
You don't help anyone by feeling better because instead of having the vendor maybe sniff on you, a hacker can do it instead.
I also haven't found any apps yet that intentionally waste my monthly datacap.
Likewise, my point about losing a datacap was that it was preferable to having more personal info backhauled into commercial surveillance databases. It's not an either-or and I'm not desiring either one - just calling attention to the larger context of user-security versus the myopia of marketing/corporate security.
You either get security updates at the possible downside of sending more data to some database of a known vendor or you get the very possible risk of being part of a slide on DEFCON Fail Panel by some unknown blackhat.
I choose a known advesary over an unknown any day.
The modern non-technical but security-conscious person concedes that their devices are pwnt by (ie they are forced to trust) AppGoogAzon anyway, and simply shies away from trusting technology. The phenomenon is what it is - I'm not advocating for it, but advocating for understanding it.
Furthermore, are you saying that you actually know all the players in the commercial surveillance industry?!
I'd appeal to your same argument of known versus unknown, but point out that at least the motives of the rando blackhat are known. Whereas the surveillance industry will be innovating new ways of monetizing their malicious databases for the next century!
I don't know all the players in the. Surveillance industry but I'm not as paranoid to believe they are worse the. Black hats.
You probably also have little probability of knowing the actual intentions or motives, which actually helps little in threat mitigations.
It's true that drive by black hats could be looking to snarf up all the personal information they can, and selling it into the corporate surveillance databases. I just think it's less likely than they're looking for a quick hit to defraud some banks.
It's not a matter of "paranoia" (there we go again with the handwavey maligning subjectivity!), but of looking at the outcomes. It's paradoxical - the things we think of as "bad" really are not that worrisome, because the shared goal is to correct them. Meanwhile the things we think are "just the way it is" form an insidious creeping trend.
I have very little fear of say my bank account being drained, because if that actually were to happen, then we're in general agreement that it will be made right - from bank policy on up to common law. Whereas if my de-facto mandatory insurance rates mysteriously double, there is both little immediate recourse and many people will even argue in support based on the just world fallacy!
Binary Security is a sign you failed at security. You can be not secure at all, somewhat secure, etc, against a set of threat models or anywhere in between those steps.
Whether or not you have properly prepared against a threat model and you are confident in defending against it is a binary property (or rather, two binary properties) but the underlying security is not.
I don't trust Apple or Google to have my best interests at heart at all, but I am quite confident that neither of them will literally try to extort me with ransomware or kiddie porn. It's weird that you're equating the two.
Even if every American owns one of those outdated Android phones, 2/3rds of the phones would still have to be owned by people who don’t have SSNs.
But you already knew that didn't you? You deliberately misinterpreted what he meant by identity theft.
I am a USian. The nonsensical concept of "identity theft" has been promulgated by the surveillance industry to avoid responsibility for their own negligence. A person cannot become a "victim of fraud" in the way you describe. The banks are the only parties that stand to be defrauded, and they could avoid this by stopping to pretend that a few bits of semi-public information is enough to identify a person. So far it has been more profitable to keep the gravy train of easy credit rolling, which is fine. But that doesn't mean we should bear the burden for them!
When someone earnest talks about their "identity being stolen", I prefer to think of them as complaining that one of their friends bought the same pair of red Nikes or whatever.
You're trading off convenience.
That said, I think companies that require up-to-date devices for security fixes deserve less leeway about the contents of their non-security releases. I've gotten multiple smartphone updates which I considered entirely harmful - they traded cosmetic or vendor-friendly changes against worse battery/performance/usability - and I think "let us break your device or you can't have security" is an unacceptable proposition.
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.
Right, but it is the tradeoff.
Of course it shouldn't be, but unfortunately it is.
Damned if you do, damned if you don't.
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"
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.
For all of the talk of how awful this is, actual exploits are almost unheard of.
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.
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.
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.
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.
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.
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.
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."
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.
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.
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.
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.
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.
Isn’t that the purpose of a device tree?
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.
I own Crappy unupdated Android one of. And the drivers use the Linux kernel. Last I checked, they need to release source for their drivers.
So where is it? And why can't we upstream those patches and "fix" android?
The OEM never releases the source.
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.
Two questions: why? and why use the GPL if you’re not going to enforce it?
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.
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.
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's a lot of work, who is supposed to do that?
Some bits of the N900 kernel are still in the process of being upstreamed afaik.
The source helps little since it's just opaque garbage with little to no meaning.
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.
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.
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.
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.
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.
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.
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.
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.
Maybe those little phone repair shops should offer installing it for a small fee as a service.
There is also postmarketOS which attempts to bring a standard Linux distribution to old phones, but it's still in an early stage.
I'd certainly spend $100 more for a configurable phone.
Just replaced a battery in a six years old Samsung smartphone in 20 seconds. It did not even cost me $10. Incredible value compared to the hassle to do this on todays phones, if it is possible at all.
I see a lot of XP computers around, but it's been years since I've seen a 95/98/ME computer.
(Actually, now that I think about it, I think my dad still had a 98 or ME computer two years ago so he could use an old scanner.)
Edit: There was no CM support, no way to delete bloatware, forcibly disabled SD storage support, and non-optional updates that eventually rendered the device unusable. The two end-user choices were to either remain offline or get stuck in "not enough free space" loops.
The case is all scratched up, the protective glass has been replaced two times already (and is up for another replacement soon, touch tends to stop working on cold days in bottom part of the screen), but I am holding on to it, because I haven't seen any newer phone that I wouldn't hate.
They're all either too big (remember when it was cool to have as small phone as possible?), or they lack features like unlocked boot or even a SD card slot.
I'm thinking of going back to some dumb feature phone, if I can find one with good support for importing contacts from outside.
Supporting/updating devices requires active planning, but then you get cries over companies that actually do perform updates and get the whole 'planned obsolescence' conspiracies.
So if your (example) Samsung device gets updates for 2 years, then the planned obsolescence for that device is 2 years + a few months. The amount of months depends on the severity of the security issues discovered. Also, it may not be "planned" obsolescence, but it sure is "accepted" (from the vendors point) obsolescence. Which is even worse.
On a side note, as a customer I don't care about internal structures of companies. I want updates. If they can't deliver that, open source everything.
And most Android manufacturers are hardware companies - their margins are too thin to support/maintain the software side of it. 90%+ of their R&D budget is hardware. It's the same as HP's computer division. No they are not a software company, they use MS Windows as the OS and make sure the correct drivers are present/integrated. This is exactly the same on Android. They buy off-the-shelve chipsets, integrate their drivers - which are developed by the chipset manufacturer - into Android, pour over some crappy GUI customization, in many cases developed by a 3rd party, and they're done.
The software update case you wrote is a good example of planned (or accepted) obsolescence by the developer.
By far a bigger problem is manufacturers shipping their own version of Android that is sometimes incompatible with the SDK. I've had to implement some ugly hacks for Samsung before, which is unfortunate because of how popular their hardware is. It's becoming less of a problem over time though.
Worst case scenario: An Android zero day that can be spread via WiFi or Bluetooth that infects devices in a cryptolocker style. The more versions it can affect, the better.
Shoot. Probably shouldn’t give people ideas, especially when I have an Android device. At least it runs LineageOS and can be updated easily...
Edit: To clarify my idea, imagine the Windows XP crypolocker viruses, but for Android instead, spreading not through cell towers or WiFi routers, but instead spreading via the cellular/WiFi/Bluetooth chips in the devices.
I’m starting to wonder if I should buy a portable Faraday cage for my devices...
But I agree, at this point the security issues are a bigger concern.
There's a pretty wide range of iOS devices now, but they're all similar, they're all good (or were good when they were released), and you can check your app on them in the Simulator. Just last week I was able to find and fix some bugs in an app that only showed up in certain combinations of screen sizes and iOS 10 or 11, without needing any real devices.
Samsung has many, many more devices; some of them are very good but lots of them are very bad; they do offer some testing infrastructure but it's not as comprehensive or convenient as Xcode; and they frequently make breaking changes to Android without any documentation. A recent example is their "game tuner" which automatically runs games at lower refresh rates and/or screen resolution. Depending which API you use to check the screen dimensions (and Android being Android, there are plenty to choose from) a game can end up displaying at the wrong size.
For example, in Interface Builder there's a toolbar with buttons to switch between different screen sizes. But it would be a lot easier if they just made the UI freely resizable (in Interface Builder, not necessarily on the device).
iPhones shove updates down your throat as a user. They're so persistent that inevitably most people will accept the new update - and even if you're stubborn like me, eventually your apps will no longer be supported under the newer OS's, and you are forced to update to keep using them. The problem is that the OS upgrades invariably slow down older phones, so even if you're perfectly happy with your iPhone to begin with, it starts to act slow as it gets the newer OS's. It's good that Android users can at least avoid this particular kind of planned obsolescence
And we have the monster that was Windows XP because of users thinking "updates" are "forced" down throats.
iOS is correctly celebrated for having such a high adoption of the "latest and greatest", and certainly hasn't become the demon that is the unpatched Android landscape.
So thankfully, from NetSec to the end user, it's a fantastic thing that iOS keeps devices more up to date than android.
Older hardware has older chips (and possibly slower memory) so... a larger size alone would still likely have an actual processing speed impact, no? The newer OS and app versions are developed with chip/memory speed "XYZ" in mind, and that's the target they aim for. That the OS does run on older hardware is great, but if your memory size goes up 2-3 times for apps, I can not imagine that there's 0 speed impact.
Apps are definitely bigger and slower, but that's separate from whether the OS is faster or slower.
Anecdotally (and I agree) iOS 11 is slower than 10 for many of the same tasks -- things like switching apps, opening the camera, opening the keyboard.
Is it? I'm a developer --- and a consumer, as are most --- and have always kept to the principle of as much compatibility as possible, mostly by not gorging on new features for the sake of new features, and a "do what you can with what you have" approach. To me, spending a little extra effort to get much more compatibility is well worth it, since I've been on "the other side" and know the horrible experience of not being able to use something just because the developer didn't bother to think about anything but the "new and shiny"; that seems to be something a lot of developers completely ignore or even oppose.
There are outliers in either direction, but these days the minimum supported version tends to be either API Level 19 if you're conservative, with a stead shift towards ... API Level 21. For reference, Oreo is API Level 26.
Perhaps we might look at this as a set of goals:
1. Users shouldn't run software with unpathed vulnerabilitities.
2. Users shouldn't have to discard devices after a small number of years (1-3, from date of purchase, in many cases).
3. Hardware, OS, and software vendors should have a functioning ecosystem in which they can operate profitably.
Unfortunately, the economics of hardware + information goods with an ongoing support liability but a one-time purchase point are pretty much pathological. This isn't a new problem. It's one that AT&T and IBM solved, in the 1930s and earlier, by leasing rather than selling hardware. IBM has continued that model through the present, for its enterprise computing hardware. There are few general-public devices that fall under this category, though.
This disconnect between business model and products leads to a lot of unaligned incentives between makers and users of product.
That's the innocent looking root of evilness - no bad people required.
Market economics works for commodities.
For wages, it tends to subsistence levels.
For public goods (including information) it under-provisions.
For rents (fixed-quantity goods or services, including both land and attention), this tends to absorb surplus valley.
For assets and risk-based elements, I'm still sorting out the dynamics, though they also appear to be poor.
There's various precedent for much of this:
* Adam Smith's classifications of types of goods: commodities, wages, stock (capital), rents, assets (gold and silver), interest, and "expenses of the sovereign" (public goods).
* Various economic-sector classifications. Alexandre Dumas, Simon Kuznets, Clark, and Beniger come up with 3-5 elements, generally: extractive/sourcing, manufacture & construction, transport and distribution, risk and finance (especially FIRE), governance and information. I'm finding these fascinating.
* Industrial classifications including SIC, NAICS, and ISIC.
* A classification of technological methods I've been looking at for a few years, including materials, networks, information, control, knowledge, and power transmission & transformation.
But yes: inoformation and markets play poorly. Software and systems incorporate both information and risk elements. (And probably others.)
Also, Generic Phones Inc. don’t see any money in pushing out pure security features — only big players get that benefit, because it’s a type of quality thats a tragedy of the commons thing.
I’d change the laws by international treaty to require security patches for all devices for whatever the 2σ lifetime is. If the manufacturers don’t want to do it themselves, then an open source requirements and a sales tax to fund hiring developers to fix it.
If we had 2 different channels of updates: security and feature, then this wouldn't be an issue.
I completely agree with you about the laws and open-sourcing.
It may be true that "normal" users don't understand security or take it seriously enough, but in my opinion just blaming them isn't fair.
Imagine your car being painted in new colors and handles in the cockpit being re-arranged in unpredictable ways every time you have it serviced.
That's basically what Software updates often do to users.
We constantly force users to re-learn how to use a piece of Software, very often without good enough reason. Additionally updates at some point force them to buy newer hardware, even though they probably neither wished for the changes in the Software nor for new hardware.
That's why I totally understand casual PC users who're not gonna stop using Windows XP as long as it lets them do what they use their PC for.
In my opinion commercial software should be regulated to either provide security updates (distinct from feature updates) or be open sourced.
I have seen this first hand with my 4S. The updates slowed down my phone, which I was perfectly happy with. Unfortunately, Apple blocks you from restoring your phone's OS back to when it worked great. Heh, and then I bought the 6S, so I suppose Apple got my money anyway.
It is bad for consumers as well, since you only have so much time.
If you want to install an app for the first time, where the current version is incompatible with your OS, you can't.
Believe me, I've tried.
Apple's productivity apps (Pages,Numbers, and Keynote) also still work and sync with iCloud.
On the other hand, I also rediscovered an old first generation iPod Touch (iOS 3). Nothing that requires network access except for the built in apps still works.
This is a truism and from my experience it rings false. I ran an iPhone 5 for four years without feeling degraded.
FWIW, as background, I'm an ex-overclocking PC enthusiast and I consider myself very sensitive to any sorts of performance lag.
But yeah, android was a total resource hog when it got started because of Java, and it's gotten worse and worse.
But, he might have thought of the complaint as so typical it has become a saying, and a truism by argumentum ad populum, but in his eyes false. Besides, most truisms are true only until they are not (a truism example). The Sun is hot. One day it won’t even be (exist).
It doesn't, you don't have to update iOS. You can keep an older version. The same with Android. The only difference is that AppStore won't serve you older app-versions that would still work for your iOS version, after some time. While PlayStore still serves you much older app-versions.
Gathering the old data from archive.org snapshots was a pain, I'm glad I saved someone else the trouble :)
One thing that's missing from this data is the actual number of devices in circulation, as said in the article it's only the market share among Android devices, and only those which access the Play Store. Having access to that data would make the graphs much more interesting, but unfortunately I have no idea where to get it.
I'll bet this means an enormous number of outdated devices outside the first world are missing. In particular, any area without cheap and reliable data access is probably eschewing the Play Store for some kind of local-area app sharing like Zapya.
Not your fault obviously, these are fascinating stats as is. But I'm also really curious how many smartphones have gone "off the grid" without being retired. Generalizing from Myanmar , I suppose Facebook's internal device data would be the best source.
People would like to be secure, but they shouldn't have to pay that much for a security patch and they don't want to downgrade their systems.
And 2 years is the best-case scenario. Compare to nearly 5 years for iOS devices (which, as far as I can tell was prompted only by a move to 64-bit SoC). It's beyond me that Google hasn't taken a more extreme approach to keeping their devices up-to-date.
This issue was predicted (and observed) years ago, almost since the release of Android in fact, and is only getting worse.
That is all due to Google's own choices.
The Kernel has no stable ABI for drivers.
Manufacturers only ever develop a driver for their chips once, and then send that to the OEM. They never update.
The Linux Kernel LTS gets 2 years of updates, Google's fork about 4.
From the day a Kernel is released, to the day it ships in a phone, usually 2 years are spent integrating the blobs and code drops from the chip manufacturers.
On every kernel upgrade that breaks the ABI, those 2 years would have to be redone from scratch.
Linux can't mainline support for every exotic piece of hardware that ever shows up in a device.
Manufacturers can't keep maintaining several developers to update every single chip they release.
Google can't keep Android on 6 year old kernels forever.
Now combine these facts, and you'll see the issue.
Whenever a security issue or design change happened, their driver would also get updated and fixed with the rest of the kernel.
What the hardware manufacturers SHOULD do is create hardware with a well defined control interface that they CAN make public. Any 'secret sauce', uploaded firmware blobs, etc, should be free to re-distribute since they were too cheep to ship a ROM or EEPROM with the firmware for their device with the device.
For example, SAMSUNG might build your device, and get all of their own code openly.
But now for the US model, due to CDMA, they need to use a Qualcomm processor.
That needs a blob, and Qualcomm won't release that under an open license, nor update it.
So the OEM can either just not have CDMA support, or accept foreign blobs.
It works like this all way down the stack, down to even camera chips.
And then these devices all have custom hardware. Often hundreds of customly designed parts, with custom drivers, only ever for a single device.
Think of the Moto Z Play, withthe replacable components. Samsung phones with facial scanners. LG phones with 3D display.
One-off features that'd never get mainlined.
STILL, that stuff should be equivalent to a firmware blob that should have been baked in to a ROM or EEPROM. The actual driver controlling it should be able to be open, and for regulatory compliance should use 'magic numbers' as specified for the configuration; which as a fact of how to use that device must be configured already /not/ be covered by copyright (in the US at least).
But they don’t.
So while you’re absolutely correct from a technical perspective it’s still a consequence of Googles strategy, and a problem for us all.
Yes of course it's not free and you can save money by leaving users stranded. But it's myopic to claim it's the fault of Linux.
Let’s imagine you try to build a phone.
You buy an SoC, and you get a single kernel build. If you’re lucky, you get a few binary kernel modules.
These will never be updated.
You will always be stuck on that kernel version.
No manufacturer of ARM SoCs for phones currently provides ever updates for these.
Linux LTS Kernels get 2 years of support.
Now, tell me, how do you support a kernel that was dropped by upstream, with proprietary drivers that you can’t do anything about? I’m not sure if you’ve ever tried porting a custom ROM to such a device, I have. By the time Android was on the 3.11 kernel, I had a device still using kernel 2.6. It was insanity, half the functionality wasn’t working, we were reverse engineering and hacking together the rest, and still barely got anything working. It’s impossible to use a decade-old kernel with modern Android userland, yet that’s what you ask for.
But even for the self caused major version jam,
the "get 2 years of support from upstream" is a heavy understatement and even after the n years of community LTS support ends, it's just the baseline you get for granted and you can diy more.
Due to Google’s pressure, it’s now 6 years.