1. Security updates. No feature updates are required (Which is sensible in my opinion.)
2. The federal election happens later this month. Take this plan with a grain of salt.
3. The original article by heise.de mentions that the federal government will push these plans during negotiation of the EU wide laws. The government thinks that the plans of the commission do not go far enough. However it's unlikely that Germany will implement stricter rules on a national level.
Note that WKRL and DIDRL (two new European directives) will be in effect in Germany starting Jan 1, 2022. They include a consumer's right to updates that allow the device to keep working (including security updates).
But they don't specify an actual period for updates (this will have to be decided by the courts). And, what I find worse, they force the seller to provide the update, not the manufacturer. If the seller is not able to do that (which will be the case most of the time), they can be relieved of their duty.
I'm eternally grateful every time I can complain to the seller, and hold them liable for the product for at least 2 years here in Europe. I once tried getting in contact with a major manufacturer about a broken device, and they did absolutely everything to make my life hard and draw the dispute out, even when I had video evidence of the failure. I just gave up at the end. So yes, the seller has to be held liable, and if the product is bad for business, the seller will not want to carry the products. If sellers stop buying unreliable, hard to update devices/vulnerable devices, maybe it will make enough of a dent on the bottom line.
It was a case with Samsung, but I've had bad experiences before with other brands too like Lenovo. The only reason I've got my money back with the Lenovo case, was because the seller was so tired of lenovos responses, he just gave me the money back because he thought their customer service was hopeless and it didn't lead anywhere. I think good service from the brands themselves is the exception, and judging by the ratings they get here in Denmark, it seems to be true.
> they force the seller to provide the update, not the manufacturer.
This (like warranties) is normally because there's no actual relationship between the consumer and the manufacturer. You do enter a contract with the seller, so they can be held liable when the law is broken.
For smartphones this can be different, since they tend to come with EULAs, but not necessarily.
So for smartphones devices, if you buy from Apple and Google directly the law should apply.
By support extension (through paywall?!) I’d think it will be a small step away from applying to all.
> And, what I find worse, they force the seller to provide the update, not the manufacturer. If the seller is not able to do that (which will be the case most of the time), they can be relieved of their duty
I'm not familiar with the Android world these days, is it still common for mobile carriers to be a bottleneck for updates? If so, it sounds like this could at least be a solution for that.
I don't think security updates are quite enough. Sometimes you need updates to keep functioning. For example support for TLS 1.0/1.1 or older signature algorithms was widely removed, which can prevent old clients from connecting to most servers.
I view this as a breaking change in the behaviour of many internet servers, which happened to be motivated by security. Which is different from fixing the security of the software on the device.
Some other examples of non security issues that might require modifications:
* Widespread adoption hosting multiple services on the same IP, relying on SNI for TLS to function. While this is in TLS as well, it's not a security issue. In practice it was adopted slowly enough that it didn't cause many problems
* A quick switch from IPv4 to IPv6 (lol)
* Y2K (happened before smartphones)
* timezone database changes (e.g. if the EU abolishes DST)
* Regulatory changes (e.g. which frequencies the phone may send on)
* A third party service the phone relies on for essential functionality gets shut down
As a practical matter, it's a far cry from something like backporting a vulnerability patch. How likely is it that you can actually get TLS 1.(N+1) without a breaking change to an API?
I'm honestly surprised, I expected the overlap between "everything new supports this" and "actually turned off" to be bigger.
So realistically, after 5 years without updates, the phone would be a brick. That's still 3 more useful years for people who care about security, and perhaps more importantly, 3 years where people who don't know about the importance of security updates or can't afford to care remain secure. This also assumes no non-security updates at all.
Well, to be fair here, the phone would still be able to make phone calls and send/receive texts, so it would hardly be a brick.
As a practical matter, stuff like supporting a newer version of TLS is at the application, not the OS level, so the user would just have to get an update with their browser to be able to use newer TLS. [1] Supporting newer TLS, for a browser, is little more than recompiling the browser; even stuff like Lynx and newer builds of Dillo have current TLS support.
[1] Windows XP stopped being updated by Microsoft in 2014 [2] but Firefox up until 52.9.0 (2018) runs in Windows XP.
[2] The post-2014 point of sale updates were quite limited in scope, and can not be seen as general OS updates
True, the brick was an exaggeration. I thought about the "applications bundling SSL libraries", but especially on a phone, I expect enough things to break to result in a user experience that most would not be willing to accept.
For me, if my phone still made phone calls, still sent texts, still got critical security updates, but I were forced to get Firefox from the app store to browse the modern TLS 1.2 web, I would consider it still quite usable.
For the average user who doesn’t know about security, having their phone updated w.r.t. security but having the phone’s built in browser break because it doesn’t work with modern TLS websites would be much better than having them have their phone compromised and critical information given to hackers. They would be able to get a new phone (or download another browser) if they want a modern browser with modern TLS; that’s a very different rodeo than the current situation of “update your phone or have security problems” with phones not even five years old.
Yep. But this is probably a good thing, since those out of date libs are likely to be vulnerable from today's POV.
To engineer the app work remotely safely on such vendor-abandoned devices you need to basically assume you're running on a malware or rootkit compromised device, and just hope that by using your self bundled components you'll have better chances to survive in the core wars game because your app is not being specifically targeted.
TLS adoption has been surprisingly slow historically. I don't know if any phones were affected. But .net on Windows 7 ran into issues with TLS deprecation (TLS 1.2 was disabled by default). And I think Windows update on Windows 7 and/or 8 broke due to upgraded certificate hashes.
If phones normally receive say 2 years of updates, any phone built since 2016 - thus eol in 2023, should support it (chrome/firefox were supporting tls 1.3 in 2017) - i.e in the next 18 months.
A vulnerability in TLS1.2 would need to be fixed (by implementing TLS1.3) in 7 years under "security patching".
Sure, but Germany has a lot of clout in the EU, and this might be a good point for –just a random pick– a new chancellor to show his/her concern for the people. I'm almost sure the new German chancellor could get that done in EU record time.
While I'd be happy for this plan to go through, I don't think most of the people will be happy with the side effects. Especially because of the spare parts requirements, I guess manufacturers will
1) Withdraw from EU market.
2) Reduce number of models on offer.
3) Raise prices.
1. No enterprise will withdraw from the EU market because of this. There are too many customers with too much money in the EU. It's a bigger market than the US.
2. That would actually be good, the amount of models aims at confusing customers. But also: Why would that happen? Many models can (and do) share the same spare parts.
3. Prices are already as high as they can be. They do not get lowered because production gets less expensive, they get lowered because of competition. This might have an effect on prices if the competition was very high and profit span very thin - which might be the case for the cheapest budget phones. For something like an iPhone? To my knowledge they are already utterly overpriced, as is tradition (https://www.forbes.com/sites/ewanspence/2017/11/08/apple-iph...), then it will have no effect there.
The question is, would it lower the total cost of ownership? A phone that lasts twice as long will cost roughly half as much (perhaps a bit more if repairs are needed).
There is also no good reason for the cost of security fixes to vastly increase the cost for manufacturers if they slow down the release cycle for hardware and software. This isn't 2010 after all. The pace of meaningful improvements is considerably slower.
Most iPhones hit the second user market whether gifted or sold on.
They have a far higher trade in or resale value than any other brand.
It actually causes a bigger second hand market of phones if they have a longer life. Plenty of users still want the latest or there abouts. While others will happily go for the nearly new.
The benefit is receiving security updates. People may not choose to update their phones with security in mind, which is all the more reason to do it. Security updates is a place where consumers can be shortchanged simply because they are invisible, the consumer may not be aware that the security of their phone has been breached, and it is the sort of thing that consumers rarely think of until something bad has happened.
As for cost, I don't see why it would have to go up all that much. Apps are already upgradable on phones and much of the OS is hardware independent. So the only real pressure point is with the kernel and other hardware dependent code.
Expensive phones don’t necessarily have much more long term software support than cheap ones and the cost is typically shared across the full product line.
Yes Apple provides longer support than Android phones, but a high end iPhone and a low end iPhone get the same term of updates, just as a high end Samsung and a low end Samsung get the same term of updates. A highend Samsung absolutely could have longer support which would improve its value. At the point where this is being built for high end phones, the marginal cost of including support for low end models is very low.
Users of low-end phones would still benefit from the extended support lifecycle because their device and data would remain secure for a longer period of time.
They're free to purchase second-hand phones, if they want to buy an even cheaper device. When most phones are supported for 7 years instead of 2-3, the market of second-hand phones that are still supported will expand greatly.
Beyond just battery flash slowly wears out over time, degrading performance. Based on my Nexus 6 I would love it if the EU dictated batteries must be replaceable, but you need an overabundance of flash so a few years in there are still cells left to balance wear across.
The Nexus 6 automatically throttled performance based on battery left, but at some point the battery wore out to the point that less than 1/2 an hour of use got you below that threshold. After that the phone was very laggy and frustrating to use. No way anyone would want 5 years of that experience, updates or not.
Second-hand phones will massively go up in price if this happens. Not a solution.
Not even going into the problems with second-hand phones and that poor people de-factor have zero legal rights as they don't have the money to take sellers to court.
Instead of buying a 1-2 year old phone with 1 remaining year of support, the legislation would allow users to choose to buy a 6 year old phone with 1 remaining year of support. Since new phone releases apply downward price pressure on older phone models each year, the 6 year old model would most likely be much cheaper under the new legislation than the 1-2 year old model is currently. Budget-conscious users would appreciate having the 6 year old model available as a more affordable and equally viable choice.
Many used phone sellers/marketplaces offer extended warranties on second-hand phones, which risk-averse buyers should purchase.
> Not even going into the problems with second-hand phones and that poor people de-factor have zero legal rights as they don't have the money to take sellers to court.
This thread is about EU law.
In EU you don't have to take sellers to court, you just have to nag customer protection authorities until they do.
It might take some time: Google still hasn't gotten a massive fine for abusing its position in search and ads to kill competing browsers despite my reports but I will not be surprised when it happpens.
PS: come on guys and gals and do write to your local competition authorities. The sooner we can get this sorted the better.
A very capable smartphone currently costs ~200€, so if prices rise by 50% (an unbelievable amount), that would be 300€. Certainly not nothing, but car repairs or a new dishwasher are much more expensive.
I expect the poorest to benefit the most from extended longevity, since more affluent people "need" the better camera or a more fashionable design the most.
I know quite a few people with >3 year old smartphones, but mostly with custom roms, since stock firmware isn't usable anymore.
1. 100 euros is a lot of money to the poorest people in society. Many of them can't afford a car or dishwasher.
2. "longevity" means nothing when most people keep dropping their phone. Even used phones that appear perfect can start bootlooping months after buying because of damage caused by the first owner and the eBay seller won't accept returns by than, even if you could prove it was not caused by you.
Most people I know get a phone case to limit damage to their phone. A case is an inexpensive investment that usually pays for itself many times over.
Someone who is really clumsy or in a situation where they are much more likely than average to drop their phone should purchase phone insurance.
And for uninsured people who happen to break their phone, it would still be cheaper to repair it than to get a new one. Repaired phones still benefit from longer support lifecycles, and the proposed legislation would ensure that spare parts are affordable and available.
A case is fantastic at protecting the outer areas of the phone by being a layer that comes in contact with the ground. They do fuck all to protect the internals as the forces still exist and can break a phone months down the road from the drop.
That contrasts sharply with my experiences, having dropped phones that were adequately protected by cheap cases on many occasions. These phones were still working fine years later, with no internal or external damage. Users who are more concerned about phone damage can buy tougher multi-layer cases, which are still great investments.
A repair in Romania (EU, unlike UK) has a labor cost of 10-20EUR depending on the complexity; in most cases the "repair" is just replacing a component that has connectors, so it takes minutes, or swapping a new battery. A £100 fee sounds like science-fiction or lack of common sense.
4) Use components for which open-source drivers are available.
Phone vendors would then be able to build the drivers from source, possibly reducing the cost of shipping updates.
In the modern day Smartphone market you are practically dealing with three groups. Apple, Samsung and Chinese Brands.
These three represent over 80% of market and closing it to 90%.
1) Withdraw from EU market - I guess most people dont realise EU as a market itself is 2nd just behind US.
2) Reduce number of models on offer - Parts aren't that different across models.
3) Most likely answer - Although it doesn't cost that much at all. You can still get a 7 years old iPhone 6 repaired, it is just costly, as it did 7 years ago. The incentive pushes you to buy a new Phone.
Come on. Every time the EU tries to implement a consumer protection a whole contingent of people comes here to say that this will cause companies to leave the EU. China is so much worse in terms of constrictive laws and regulations and you can plainly see that companies don't care. They adapt and sell, that's how they work.
"Security updates. No feature updates are required (Which is sensible in my opinion.)"
The lines get blurry.
Is a modern browser a feature upgrade or security?
Well, both. But if the vendors really would just sort of fix their old mobile browser, you would still be stuck with a old browser unable to interact with the modern web.
Is it a feature update, that you want to install newer apps? (like another browser)
For this to make sense, it should enable you to update your whole OS of the devicey that it can at least install and update common apps. Otherwise its benefit is very limited.
> The lines get blurry. Is a modern browser a feature upgrade or security?
A modern browser should be a feature upgrade. A browser as modern as the one that came with the device, except without known security issues, should be a required security update.
Coincidentally no one develops the latter without the former, so you get the former, but I don't see that you are entitled to it.
If anything I think the law should be designed such that there's an argument that you are entitled to the version of the browser that came with your device with security updates and without any feature regressions, which is never available today since browsers do choose to remove features on a regular basis.
Replying to myself here, one interesting result of the "security updates without any feature regressions" interpretation is that it would be a very strong disincentive to bundling software. You would want to let users install their own browser instead, so that every browser feature isn't a feature that you need to maintain. It seems like it could completely eliminate shipping with apps like Facebook pre-installed, because Facebook is never going to commit to not removing features.
It's probably not feasible with todays software ecosystem to actually create that constraint... but I still really like the idea.
Often when apps like Facebook are bundled on lower-end Android phones, they are not uninstallable. This means they take internal memory and can't even be moved to SD cards, severely restricting the functionality and durability of those phones. The only way way to fix it is by rooting.
Non-essential or third party apps should be at least un-installable. I'd be ok with a law for that.
> But if the vendors really would just sort of fix their old mobile browser, you would still be stuck with a old browser unable to interact with the modern web.
This is a non-problem nowadays. We have long left the times in which browsers received essential features every few weeks. Using a browser with a feature set from five years ago you can still use all the most-visited websites perfectly fine. At the worst you're unable to use small, non-essential features of some sites. Maybe some ads look less fancy ;-)
Your problem today as a browser user is security against zero-interaction exploits, not missing out on some obscure brand-new CSS features. Security updates are thus what you need first and foremost.
Browser APIs are less stable than you might think. If you've ever had to develop web apps for smart TVs (Samsung, LG, Vizio, etc.), then you'll find that each model year is frozen on an old version of Chromium – some from 2016, some from 2017, some from 2018, etc. There are enough differences between them to make this painful. For example: multiple versions of the Media Source Extensions API, web components, CSS variables, ES6 modules, and web font loading patterns.
A browser is an application, one of which you can have multiple versions installed (even so modern OS vendors try to prevent that). If the system default browser in Android/iOS has a vulnerability, that should be patched. No one forces you to install the latest version of that browser as a security mitigation.
Re 1, yes it’s sensible as law, but I imagine Big Tech freaking out at the possibility of having to maintain some security-only update branch for every version a user might have started with.
I like this, but I think a reasonable alternative would be that for smart phones older than a certain age the manufacturer publish enough information for the creation of free drivers and software and unlocks for installing that software. One thing that makes me really sad is that I would probably be perfectly fine still using iPhone 5 era hardware if I had a free OS I could put on there with ongoing support. That's entirely reasonable in the desktop/laptop space so it strikes me as kinda sad that it seems non-existent in phones, when it's all just computers anyway.
The problem are the SoC that often have weird peripheral and drivers that require patched kernels (and often it's to interface with proprietary hardware that's under IP constrains).
>> SoC that often have weird peripheral and drivers that require patched kernels
This is a sad industry-wide mess which should have been fixed long time ago IMO.
It is unfortunately common for an Android device to come with a custom patched 2.x kernel with no plans for 3.x support. Then when a next Android is released it has a hard requirement of 3.x kernel. So no Android update for that SoC/device and no way to port this mess into the newer kernel.
If SoC/peripheral manufacturers only supply "software" as a custom hacked 2.x kernel branch they are basically supplying unfinished PoC-quality un-updatable garbage and such software should have never been released with a production device.
This is non-existent on desktop and laptop space where you often have mainline support for all the essential components.
Two options: the claimed IP on the interface is removed or said to never have existed in the first place, and/or prevent bootloader locking.
First one is a very good idea, as older IP law actually holds that interfaces aren't copyrightable. US IP law is schizophrenic on this last point considering the Oracle ruling. E.g. you're free to implement an interface for compatibility.
I am a proponent of this idea, but I could never figure out how to address proprietary blobs and third-party entanglements. Even Apple with their massive vertical integration likely cannot fully open source an iPhone 5, as there are proprietary bits like certain chip driver's software API they've agreed to not divulge that are still in effect due to the nature of many legal agreements to grasp for indefinite terms in these matters.
If you're gonna have a law about open sourcing things, you just add a clause that says IP agreements after the lock-up term ends are null and void and unenforceable at law. You can have privacy (of your IP) or property rights, but state institutions will only help you enforce one, not both.
Some people will argue that this will stifle innovation, because the manufacturers of the latest and greatest won't be incentivized to license their stuff. OK. Essentially I'm describing a bet on openness winning out over proprietary over time.
In my view, one other feasible good step would be to require companies to publish the source code of their phones, ie provide the option for people to download, compile and install the full sw stack. Like this even if manufacturers stop supporting their devices, people can step in and do it. At the very least it would make it easier to support devices than it currently is in third party ROMs
What about a law the forces vendors to either provide security updates or publish the source code? That seems like a reasonable trade off between consumer rights and ip protection.
Why not both? There is no compromise needed here. Both things benefit the public interest which, after all, should be the author of the law (in a democratic country at least).
> Why not both? There is no compromise needed here.
You're assuming that it's actually feasible to keep old devices up to date for that long. It may well not be. It gets substantially harder to maintain old branches the further mainline has diverged from them. The original engineering team has typically long since moved on. The magnitude of the issue, here, can be on the scale of "we now need several times as many engineering teams".
This isn't a matter of "security updates would be better than no security updates". This may potentially be a matter of "security updates for four years is economically feasible, security updates for seven years isn't". (I'm not saying it is infeasible, just that it may well be.)
Thus a neat effect of such a law would be that SOC manufacturers would not purposefully break compatibility as much as they do now. Sounds like a win-win to me!
Or, much more likely, they'll continue building new hardware as they do now, and let the length of software support for old hardware in one particular market be a software problem for the vendors selling into that market.
Don't assume that attempting to solve a problem with a law can only have one possible outcome, and can't possibly have a different outcome instead.
Frequently SoC manufacturer make quick and dirty changes to a fork of the Linux kernel. By the time the hardware actually ships, those changes don't work any more with the current Linux kernel.
Trying to make those work 2 years later is a huge effort -- probably worth less than just replacing the phones.
Mind you, I agree with you in principle, but I can see how in practice in might all go to shit.
If the code were open source, I'd be willing to bet quite a lot that this kind of code would get cleaned up and mainlined. Certainly for popular handsets from major manufacturers which probably account for the majority of handsets sold.
Thanks to the GPL this is already often the case (at least for the kernel). But vendor code is so abhorrent in quality, upstream efforts are few and far between.
I guess they gotta stop doing that then, huh? I don't see how consumers and society benefit from rushed, vulnerable crap software. Oh, right. Time to market. Race to the bottom. That's what we need more of.
It turns out that getting a bunch of programmers to do careful modifications to some C code base over a couple of months is more work than getting great many thousands of people across multiple companies to manufacture, distribute and sell new hardware to millions of customers.
Why would they? They get paid to put out crap, so they'll continue doing it.
Bottle water continues to come in plastic bottles, even though glass if far cheaper/easier to reuse or recycle. Plastic bottles are literally trash, yet it'll continue being produced if people keep buying it.
Near-disposable phones (both hardware and software) won't stop being manufactured if they continue being in high demand.
Actually, you do see. The price of your phone would be higher if Qualcomm had to hire competent engineers to make properly designed kernel changes for their hardware.
How much higher though? If you were to take the total extra expenditure on increased salaries for those engineers, and divide by the number of phones produced, the result is what? A dollar?
Sure, but when applying Marketing Math™, remember that all prices need to end in "49" or "99" to "sound cheaper" than the next incremental bump. So you'll end up with a device that is either $50 or (more likely) $100 more than otherwise.
Or they'll eat that $1 from their profit margins…eh, who am I kidding?
If they're rounding to the nearest $50, they're doing it based on the final cost. They're not going to base it on a what-if scenario of having a cheaper development team. So it's more or less a 2% chance of the price going up $50.
The price of your phone would be much lower if the software stack was truly Open Source, allowing distribution to remove clutter and spyware, and make older phones perfectly usable again.
> Frequently SoC manufacturer make quick and dirty changes to a fork of the Linux kernel.
SoC makers deliberately do this as a way to force phone manufacturers to buy new chips.
For example, if they release a chipset in 2020, it will ship with Kernel 4.14 (released in 2017). Why ship such an old kernel on brand new hardware you say?
Well Android 11 (also shipped in 2020) supports Kernel 4.14, but you can be pretty sure that Android 12 won't support 4.14. So that means that OEM's can't make android 12 work with that chip without a massive engineering effort (and by the way, a bunch of chipset blobs will be compiled against those kernel headers, so changing kernel versions is pretty much impossible).
So, the main reason to use a deliberately outdated kernel is to prevent last years chips running next years android release, without the chipset manufacturers permission and a share of the profits.
> and by the way, a bunch of chipset blobs will be compiled against those kernel headers, so changing kernel versions is pretty much impossible
Binary drivers can be reverse engineered and reimplemented for the new kernel. This takes a lot of effort since it requires following a "proper" clean-room methodology when doing so for interoperability purposes, but is otherwise doable. A complementary approach is to forward port the minimum set of features that's required for Android 12 to the older kernel, in a way that carefully preserves the portions of in-kernel ABI that the binary drivers depend on.
Reversing engineering is hard. It would be nice if the kernel didn’t trash it’s ABI all the time for ideological reasons. Hopefully a new OS (fuscia) will fix this.
> Meanwhile in Windows land: You can run 20 years old drivers, no problems. Hardware is a commodity.
You can sometimes run 20 year old drivers, assuming same ISA and that none of the ABI has changed, which does in fact happen, just more rarely. Windows 10 is certainly not compatible with 100% of drivers from Windows 7, let alone XP (20 years ago is 2001, so Windows 2000 is actually likely).
I think this is much more reasonable as well, for many kinds of devices. Either give people the ability to update the device themselves, or you have to supply updates. (I think 7 years is a bit much, but the duration is a quibble over a minor detail rather than a fundamental principle.)
The point is that there will be a lot of pushback from vendors. Meanwhile I doubt even 5% of the electorate actually cares about this. For that reason I don't think it's really "feasible".
>Meanwhile I doubt even 5% of the electorate actually cares about this. //
Representational democracy is supposed to work around the problem of an uninformed electorate. The question should be "if a member of the electorate understood this situation well enough would they care", representatives are supposed to use subject experts to help them answer that question and then use their political expertise to implement laws that move us towards a solution.
It's a big ask, and it doesn't work that well -- politicians often work at what will win them plaudits in the press (or what can be presented as a win, if they control the press), rather than actually doing their job.
Fundamentally though "the electorate doesn't care" is the wrong measure, there are a million things the electorate don't care about but would care about if they had the situation presented to them fully ... we pay representatives and advisors so we don't have to care directly ... that's supposed to be how it works.
requing operators to allow phone owners to update all OpenSource code, which is probably the majority of the Internet/network facing code in ios and android, could be doable.
I would prefer if instead smartphone makers were at least forced to add a tool so users could wipe the memory and install a free bootloader.
And would be great if they had to also provide a free OS, like postmarketos, lineage, Debian or something like that. It could be very rudimentary without a GUI, just drivers for GPS and Wifi. And they would not have to provide even security updates for that. So I would think that many companies would also prefer that.
Literally the only reason I stopped using my last two phones was that the security updates stopped streaming in. Even now they sit in a drawer, perfectly functional, abandoned by Google.
It's one of the reasons I moved from Google to Apple. iPhones 5-6 yrs old still supported. I always thought iPhones were too expensive, but I didn't take into account the upgrade cost every 2 yrs on Android.
Same here, I bought my first iPhone almost 4 years ago. It still works like the first day. I used to like constant change (installing different roms, customizing my phone, waiting for the next cool Android UI refresh, switching phones every 2 years etc). But as I get older I started to like consistency and the feeling of using my phone for years without thinking too much about updates and whether I would get them or not.
This seems backwards to me. You can still run modern Android versions on old phones like the OnePlus One thanks to LineageOS. There is no custom ROM scene for iOS devices.
You should not buy a cheap device from a manufacturer with bad SW update reputation.
Look at Samsung Galaxy S7 Edge - 5 years old device:
- Released with Android 6.0.1.
- Received 7.0 and 8.0 major updates.
- Has unofficial 11 support.
- Received September 2020 security update.
Cheap device manufacturers unable or unwilling to support software updates should be banned by law. It should be a part of their job. Instead, they often seem to release one "proof-of-work" initial release and then don't care and work on the the next model to repeat the same. Pretty sad.
Show me one exploit in the wild that you would download from Google Play or be affected by using an updated Google Chrome from the Play Store.
Just because security updates stop doesn't mean your device is immediately insecure and cannot be safely used.
The majority of the phone's actual updates come through Google Play Services.
Meanwhile, I can show you an exploit in the wild that affects virtually all iOS devices even though they're regularly patched up: Jailbreak methods and iMessage zero clicks.
There was a six-part series on Google's Project Zero blog at the start of this year called the "In-the-Wild Series" which included Chrome and Android exploits. In May, Ars Technica had a post called "4 vulnerabilities under attack give hackers full control of Android devices" which detailed more exploits Project Zero had found -- there were actually 50 in the Android security bulletin that month, four of which were zero-day exploits explicitly described as "exploited in the wild" by a Google researcher.
I'm not going to argue that iOS is some super secure fortress of impenetrableness, or that Android is some kind of digital petri dish that becomes immediately infected with the 500 Viruses of Bartholomew Cubbins the moment it connects to wifi. But there are Android exploits documented routinely, some of them are serious, and some of them have been found in the wild.
Its last security patch is dated August 5th, 2019.
Play Services and Chrome are fully updated.
Where is there an in the wild exploit that you can point me to? Proof of concept or otherwise. I'll happily load it up in Chrome on my phone and let it compromise my system.
Meanwhile there's a zero click iMessage exploit article still on the first page of HN.
What gives you the impression that Android security updates only involve Play Services and Chrome as opposed to the file system, bluetooth, wifi, CPU, and GPU stacks, or anything else? Do you have a reason for believing that any of the numerous drive-by Android remote code execution CVEs published since August 2019 can be mitigated without updating any of the vendor and kernel components that Google had to update to stop them?
Let's ask ourselves this basic question: If Play Services and Chrome could keep an Android Pie system secure, why does Google bother with a separate security patch date?
> Meanwhile there's a zero click iMessage exploit article still on the first page of HN.
Maybe because it's news and critical Android remote exploits are found often enough to not be news.
> Maybe because it's news and critical Android remote exploits are found often enough to not be news.
Then you should have no problem being able to find one that will exploit my phone. I even gave you the specific Android version AND security patch level to target.
Get at it instead of pointing to the sky and saying "look!"
Enjoy your phone. Or don't. None of us are your mom, so we can't tell you what to do.
> Get at it
Abrasive demands are unpleasantly childish. Not being your mom also means that I don't care if you suffer from your own negligence. You can either keep yourself abreast of Android platform security woes or not. As Captain Planet says, the power is yours.
Dude, I literally mentioned articles with in-the-wild exploits that have been found for Android this year. "Yes, but those are from a few months ago, they are fixed now, and there is a CURRENT one for iOS" is not the "checkmate, iSheep!" move you apparently think it is.
I think these requirements are very reasonable and we have an existence proof that it is doable.
I know that Apple supports its hardware for seven years in California (and not other US states as far as I know) due to state law. I can’t imagine other manufacturers are immune to this same law.
...and listed, like the Lisa, under "Mac desktops" for some reason. But aside their organization, the comprehensiveness of this list is actually quite satisfying:)
Providing firmware-updates and spare-parts (especially batteries) should be a requirement for all-purpose-computers i.e. laptops and desktops. And also for smartphones with user replaceable operating-system. For devices which are only appliances (smartphones with boot-lock and worse) this also extends to the operating-system itself.
This makes devices more expensive? The prices will be higher but the value you get also. I'm talking about companies which uses adhesive strips and unusual screws with tiny buckles (Apple - iPhones) or the ones which glue the display onto the baseboard (Google - Pixel). Or companies which used to provided user-replaceable batteries with notches, which now uses screws inside the device (okay!), but now also a firmware to ensure that the user won't get a replacement battery some years later (Lenovo - ThinkPad). Otherwise Lenovos ThinkPads are good example, step-by-step manuals, explosion diagrams, well maintained replacement-part numbers...and yes, more expensive.
yea funny story about that. I have a google pixel 3 xl. Was in great condition. No cracks or issues. So I'm in the medellin airport waiting for my flight to Lima when I'm talking to a friend and notice that a crack is forming alongside my phone. To my horror, the battery decided to swell open so far that it cracked open the cell case. Here I am with a phone that as far as I know, is about to shit the bed and I'm in the middle of a foreign country on my way to ANOTHER foreign country with no way of activating a new phone. (google fi requires the phone be in america during activation.)
Luckily in Lima, I was able to track down someone that could doa. replacement. This phone was clearly not designed to be repaired as I saw him slowly melt layers of glues and pull apart different pieces to do the actual battery replacement.
He managed to get it working but now the finger print reader isnt' working. So here I am currently in latin america with a phone that has a cracked case and a broken fingerprint reader. I'm waiting till I can stomach coming back stateside to replace this phone because repairability was never a concern.
I'd go even one step further: EOL software and hardware should be forced to be open-hardware (at least open schematics) or opensource. If you're not willing to support a product anymore then it should not be possible for it to simply turn into a brick because you turned off a server.
This would either create a market where companies will sell the license to support old products to other companies, or old hardware and software would finally be able to be supported by the community. There wouldn't be a need to reverse engineer or develop stuff in a "clean room" for fear of litigation.
Sounds great until companies sell the license to maintenance as the last buck to squish from a product to a third party that will jack up the price just to keep the service running. Better to either force an open source/schematics approach and let the community keep it, or force to sell a certain number of licenses for maintenance.
Your statement is valid for individuals. But as a society, we could value reparability. And laws are there to enforce what the society values, not the selfish individuals you and me are part of.
That is irrelevant to the discussion at hand. Yes, free repairability would be fun, but as everything comes with a cost, values are encoded as trade offs between desirable outcomes, rather than the desirable outcomes themselves. When some desirable outcome is not obtained in society, almost always the reason is that there are other tradeoffs being made. So society values affordability, competition, performance, longevity, quality, repairability, customizability -- and that's just on the product side. Then these product trade offs compete against things like labor market protections, use of resources for competing products, etc.
When Apple decides to solder RAM into the motherboard, it is making a trade off between performance and repairability. When Tesla chooses megacasting that might result in a fender bender totaling your car, they are choosing reliability and lower production costs over repairability. Just bemoaning that some product is less repairable and that society values repairability so therefore some dark force must be working to subvert society's values is not a useful or insightful analytical approach. Everything boils down to tradeoffs.
Society is looking only one immediate issues: Is it comfortable. Only later the notice the long term consequences.
That is the reason why Microsoft was able to dominate the desktop market. Now wonder, the number of professionals on the desktop market is low. Despite the harmful effects of the UNIX-Wars, Linux managed slowly to take leadership of servers, super-computing and some professional devices (Lenovo ThinkPads, Dell Developer Edition).
Naturally some consumer test boards would hint on long term effects and consumers would adapt ("Don't buy car X from Z, it has problems with the engine after 40.000 km.") computing is very fast changing and one bad decision can bound you for years. A large base of Windows users cannot switch, they are not able to switch because they bought sadly hardware from a vendor with not open drivers, or a specially crafted bureaucracy. Of course XMPP existed and was more secure but WhatsApp was more comfortable. And even despite Signal is better, they sheer group pressure is extreme. And your Apple-Music account and all the invested money on the App-Store and your GMAIL-Account...
Interesting enough, if you don't buy the most expensive device you get replaceable batteries. If you buy rough phones ("professional") you get replaceable batteries.
Industry is quite good teaching leymans what the have to buy "blingbling" and then just lock-in the buyers. Of course they would appreciate repair ability - they just don't know it better at time. It actually US which fail to help them before they are in the next trap. Schools now using foreign clouds and Zoom. Holy...why we failed to show them Matrix and Jitsi? Why we didn't improved comfort?
10 mm vs 7-8 mm for class leading phones. Maybe the Xcover Pro is rugged enough to use it without a case/sleeve ("Drop-to-concrete resistance from up to 1.5 m"), so it might end up being thinner in practice.
If there was no e-waste, you’d have a point. The problems come when negative externalities are not priced in. Then we’re forcing people to pay those costs, though they may be distant in time or space.
This is an odd question. There are "losers" and "winners" with the state of any market. Currently, those of us that prefer repairability are the "losers" in the smartphone market. I therefore put your question back to you.
Why do you think the market is providing people the products they want? This may be self-evident for you; it isn't for me. Markets are useful, but they don't work well. People want to be forced to spend an extra buck for guaranteed free returns and another extra buck for minimum warranties, and maybe another buck for 7 year of updates. They also want the resulting costs to be distributed amongst everyone, which makes them trivial. This isn't a particularly unusual idea in a continent that has tended to embrace socialized healthcare.
A big enough majority of people wants it, anyway, to vote for representatives that write these laws. I'm sure there is a small minority of oppressed Randians who suffer terribly from all of this.
Imagine powerful and lightweight laptops only sold in Americas and Asia while in Europe one will only be able to buy bulky (because repairability) and slow (because high-end manufacturers focus on less regulated markets) versions.
Here's a "win-win" scheme which benefits both consumers as well as manufacturers/retailers without running up the costs for either: mandate the release of a device tree for all devices at least a year before the last vendor-supplied update so the users can migrate to any AOSP-derived distribution - LineageOS being the most well-known. The device tree should be complete, i.e. it needs to contain any needed drivers in either source (preferable) or blob form so the device will continue to be fully functional when used with a third-party distribution. Doing this will drastically increase the useable life span of devices by mostly removing software obsolescence as a factor. Hardware will still age, performance will eventually lag too far behind current devices but seeing as how I'm using several devices from around 2010 (Motorola Defy/Defy+) for specific tasks those 7 years can easily be extended without any additional cost to either vendor or consumer.
Project treble should actually be really close to this, come to think of it. And I kind of think that that's theoretically supposed to be part of Google's certification process for Android, though I suspect there are caveats (ex. without unlocking the bootloader it doesn't help).
iPhone 6s (not 6) level of performance and above is really enough for most people to do normal every day tasks (not gaming). People are going to be keeping their devices for longer lengths of time. Security updates for longer periods are essential.
Android phones just hit the "good enough" point a few years later than the iPhone ecosystem. My Samsung S7 (2016) is roughly as fast as my 6S (I have both for developing, and they're both plenty fast enough for everyday usage).
I don't think consumers are that interested in processor speeds anymore. Cameras are probably the biggest selling point for new phones these days, followed by battery life and display quality.
My S8 was reasonably priced with a 1440p screen. High refresh is horribly supported on android and nothing like display port adaptive sync. I don't to pay a new ultra price for what I already have.
I believe industry noticed that 1440p on 75mm width display is overkill (or say there are other points should be improved than resolution). It's good thing for battery and price.
I only replaced my 6S a few months ago, and found it perfectly good to continue to use, not just around the house but in some outdoor uses where my phone might be at risk. Yes the 12 has some features that are nice, but upon a few months’ reflection really its biggest advantage (to me) is that it is smaller.
Gaming worked fine on a game boy. I support the end of arms race in gaming and a move towards power capped gaming rigs with games to match. Other sports have done this and it has many benefits above and beyond CO2 reductions.
Early humans (at least some of them, I gues…) lived happily in the caves. We should ban everything and move back into caves. Just imagine how much co2 would that save!
Software updates should be indefinite, like Linux distros, which can still run on 15 year old hardware just fine.
The future ought to be something like PinePhone (but with better hardware) that can be customized to run a variety of OS with consumables such as batteries easily user replaceable.
> like Linux distros, which can still run on 15 year old hardware just fine
First, let's remind that LineageOS does not run on 15 year old smartphones (and they drop support for a device when there is no upstream support from vendors on the same Android version).
One issue is that unlike x86/x86_64, there is no generalized abstraction platform (similar to BIOS/UEFI/ACPI description tables) that enables "one kernel to rule them all" i.e. you need some custom adjustments on your kernel for your SoC and board. Since a few years we have device-tree which improves a lot the situation, but I understand it does not cover everything (i.e. there would still be some missing aspects compared to UEFI/ACPI with regards to hardware description. Maybe some embedded experts can comment ?). Besides it is still not always implemented in chipset vendor's BSP which sometimes still rely on board files (where the data is not easy to extract from a binary kernel, noting that a lot of low-end OEMs do not properly comply with GPL and do not publish their sources)...
> One issue is that unlike x86/x86_64, there is no generalized abstraction platform (similar to BIOS/UEFI/ACPI description tables) that enables "one kernel to rule them all"
Windows on Arm devices use UEFI + ACPI, including Windows Phone starting from Windows Phone 8 (2012!). That allowed even the latest releases of Windows 10 Mobile to work on totally unsupported devices (1st gen WP8 devices) when that existed.
It's not an Arm problem, it's that the Android world didn't bother really tackling the problem for a long time.
I think user karteum brings up good points, but they are more like industry excuses than reasons. It's clearly possible to clean up this mess, but the OEMs and OS vendors simply won't bother since there is no regulatory reason to do it. This move from Germany is a great first step, but it's a step down a long road that the industry will fight at every exit.
This is a bit disingenuous. The problem is that every soc manufacturer wants custom data to pass to their driver. With ACPI, you need to standardize this data and get it published in the yearly spec update. With device tree you just check in your new device tree bindings alongside your driver in the kernel repo. Device Tree blobs are only stable with respect to the kernel version they were built for. It also doesn't have to worry about being OS independent. SoC manufacturers are happy with this arrangement because it lets them iterate quickly. It is a much lower bar with much lower costs compared to ACPI. In recent years, ACPI has started adding support for encoding data which is non standard by allowing key value data, but using that sort of defeats the point. Those fields aren't usually documented and only the driver written for it understands how to interpret that data. Again, that forces ACPI blobs to be versioned alongside drivers. There is completely unlike how x86 works where everything really is standardized and you don't need specific drivers operate every peripheral on the board. Of course even on x86 you can have more specific drivers which are more optimized or expose additional functionality, but generic drivers can an do exist which get you decent support. Beyond device tree/ACPI this means adhering to standardized register layouts and things like that which is completely off the table with arm soc manufacturers.
Windows doesn't have that issue on Arm, you can just boot the newest Windows on Arm release on a random SoC from the past that (if it's the same arch of course, 32 bit or 64 bit have different drivers) as long as the work was initially done first.
For ACPI, the vendors themselves tend to avoid changing bindings between generations for Windows there. Compounded with a stable driver ABI, things continued to work stably within all of Windows Phone (NT based, 8.0 to 10)'s lifetime, which had security update support until December 2019.
Windows RT 8.1 still gets security updates today, and will continue to do so until January 2023.
Linux not managing to standardize on a proper driver ABI _or_ stable bindings with the drivers in the kernel tree is just a Linux problem, and doesn't even affect other kernels on the platform, which mandate ACPI or something else.
> There is completely unlike how x86 works where everything really is standardized and you don't need specific drivers operate every peripheral on the board
Nope, on x86, the meaty bits like the GPU and such do not have a stable register interface or anything remotely near that between generations. :)
On Arm systems, the interrupt controller (GICv2/3/4), timer (arch timer, since Cortex-A7/A15), IOMMUs (SMMU) and other standard devices were standardised since ages now (Apple is their own bubble and doesn't apply to this discussion). One of the remaining issues so far is PCIe hardware quirks/erratums, but that's getting solved.
But Qualcomm isn't interested in making their Linux drivers work with their ACPI definitions, they are stable between generations on Windows though, and not changed needlessly over there. (which allowed us to work to bring AArch64 Windows on the Lumia 950/950 XL using drivers from other SoCs too)
While you cherry picked examples that work for your arguments, I would say that they arent entirely correct. On x86, you can use a bounded number of drivers and boot successfully on a large number of boards. This is because things like buses, storage and display are standardized. This is not true for ARM. Every manufacturer does its own thing. Yes there are bits which have been standardized and shared, but for the most part that's not the case. As a result you cannot really make a single image that boots on a large number of boards without also including a very large number of drivers. Windows phone only ran on a limited number of SOCs, primarily Qualcomm.
Also for what it's worth, Qualcomm does update their ACPI definitions between SoC generations. They also fork their drivers to match. If there was a stable driver ABI they could probably do the same on Linux but that's not an option.
On server, ARM vendors went the PC route and just adopted standard interfaces used servers (pcie, sata, etc). This is large departure from SoCs targeting phones, tablets, and iot.
For QCOM the bindings for the base drivers are stable, and despite them forking drivers, the one for the others generally are - too
The biggest concern there is the PEP power management mechanism instead of using what ACPI provides.
> This is because things like buses, storage and display are standardized
That's a rosy view of x86. Quite some laptops ship with Intel RST set up such as stock Windows wouldn't boot on them before adding that driver. Display (frame buffer) is standardised too as UEFI GOP, but that no longer applies when the GPU driver takes over of course. Storage controllers & USB bindings are standardised too.
Doing a Qualcomm driverless boot on those platforms is very much possible, with storage and USB available, enough to install the OS and make it reach the desktop.
(and on a side note, as far back as the Snapdragon 810, PCIe was very much used. The Lumia 950 (XL) had their Wi-Fi controller over a PCIe bus.)
Laptops are definitely trending in the same direction as smart phones, I will not contest that. However my main point is that it's all much more standardized. Booting the system to the point you can prompt the user to connect to the internet and download more drivers is much easier on x86.
Qualcomm having "stable" bindings is a choice they've made. There is nothing forcing them to do that. The point is that they could not do that, because they know all images built for their phones will be specialized.
Qualcomm may use PCIe for one off peripherals, but it is not the bus used for most peripherals.
> SoC manufacturers are happy with this arrangement because it lets them iterate quickly. It is a much lower bar with much lower costs compared to ACPI.
You can also get away with ugly hacks and sub par devs. Doesn't matter anyways, you got all the money from selling the SoC, software is an afterthought.
> and they drop support for a device when there is no upstream support from vendors on the same Android version
Nope, they drop support when the community runs into issues with a particular model that it's impractical to fix. Upstream vendor support helps but is not required in any way.
Device tree "doesn't cover everything" because some device components are yet to be supported in the mainline kernel. Once mainline support is added, that enables a 'universal' kernel to provide that support via the device tree.
This is true. I have used Lineage OS with android 7.1 on a first gen Motorola G phone (that was declared EOL after the Android 5.1 update) and now on a OnePlus 5 with Android 11 (manufacturer dropped support after 10)
Wouldn't that cause them to skip features and pick cheap drivers? How many people would benefit (not theoretically, but in practice)? Average life span of a mobile seems to be 2 years and a bit. After seven years, very few users will be left. And it's not as if everyone ditches their phone because of lack of updates.
> And it's not as if everyone ditches their phone because of lack of updates.
Often it's because of lack of app support, which is in turn because of lack of updates. Of course some people will always want the latest phone, but there are plenty of people that don't, and the second hand market is thriving. This is especially true in countries with lower income levels. I went on a trip to South America a few years ago, and most of the young people seemed to be using iPhone and android phones from top-tier manufacturers, but several generations old.
I don't see why. Theorically it could benefit a lot of people and help community driven projects or companies wanting to provide long term support. For example, if you create a phone that relies on Qualcom socs, qualcom only provides a few years of support, once they don't provide any new driver you're screwed. Forcing the release of source code would at least help open source driver initiatives.
If phone manufacturers stopped producing 10 models every year and focused on making a single robust one, they would have plenty of resources left for actual maintenance.
Sure, but they're in the business of selling as many phones as possible which means getting you to upgrade every so often. Unless they settle on a business model that allows them to make money from your old phone, I see this continuing.
Honestly why should I care what their business model is, if it is detrimental to users and the environment. That's the whole point of laws, to discourage behaviour that we as society deem undesirable.
"Selling as many phones as possible" allows yearly upgrades, but instead of 10 different models per year they can sell 3 models per year with 3.3x sales of each model. I am looking at Samsung models on the market, they are close to 10, Apple has maybe 2 or 3.
How so? Apple also releases new models almost every year with very dubious quality. I remember some scandals about antennas, and more recently about RF interference with pacemakers, but i'm sure there's a lot more i'm unaware of. Apple prevents users from using the hardware however they please and blocks the bootloader. They don't even give you root on your own phone!
Also they're famous for making their products hard to repair. It's hard to find spare parts, hard to find their custom screw heads, and hard to tear everything apart. You can't even remove the battery without tools which is very user-hostile, bad for the environment, AND was a pattern "popularized" by Apple, because if any other hardware manufacturer had dared to do that, they would have sold exactly ZERO phones.
All in all, Apple is close to the worst manufacturer i can think of to get inspiration from, although on specific topics (eg. LCD screen solidity) they are definitely not the worst.
Yeah, that is definitely the ideal future. Problem is that it has to be a well organized entity behind this. The open source community is very fragmented and can't spawn a reliable product for the mass consumer in the way current companies can.
While the idea that companies are held responsible for all theyr actions are good, there is one big problem. If the rist of failure of a product is to large, companies build shell companies that can go bancrupt. It is done so in oil shipment companies and i am sure there are other good examples. Nothing has been done against that even after huge oil leaks where the responsible companies have been very obvious.
(I do agree to longer enforced support on devices nevertheless)
This requires hardware manufacturers to work with kernel maintainers. It’s hard enough just getting them to publish the driver source code and not screw the user over for removing “value add” user space software.
Basic video is the keyword, on its heyday of GNU/Linux drivers it was capable of OpenGL 4.1 with hardware video decoding, then it got replaced with a driver that does OpenGL 3.3 and that is about it, thankfully the Windows drivers have been kept up to date.
The Nokia XR20 is one of these devices, it was released in August 2021. However according to https://www.nokia.com/phones/en_int/security-updates it is not guaranteed to receive security updates after August 2025. Something is wrong.
I love that they are closing all of the loopholes at the start - can’t raise the cost of the replacement parts over time, have to deliver them within a defined timeframe, etc. Combine that with meaningful penalties for non-compliance and I’m sure there are a lot of executives cursing.
I’d love to see the same thing applied to lightbulbs - instead of throwing away the entire bulb because 1/n leds have failed, be able to replace the failed led. I’ve seen a number of YouTube videos where a guy tears down “burnt out” led bulbs and every time he’ll find a single led that is dead or dying and he’ll bypass it and the bulb works fine. However he usually destroys the plastic bulb piece getting it open - would be great if those screwed or snapped on.
They already have a similar law in place for car parts. Manufacturers have to supply them for 10 years. And also 3rd party garages have to be able to buy them. And compatible parts from another manufacturer are mostly legal (can't be protected by copyright).
Extending something like this to software and security updates is a promising idea.
It's hard to see how this could be enforced meaningfully. After all, who gets to decide if the updates represent a reasonable effort at bug fixing and security patching? What's to stop a company throwing out rudimentary updates as a box ticking exercise? In some ways that could be worse by creating a superficial appearance that phones are up to date.
I think there are some pretty clear-cut cases where it's easy to argue that a phone isn't up to date. For example: a critical severity vuln in the Linux kernel that's already been patched upstream >6m ago, but that phones don't have yet.
If this legislation starts to get the SOC manufacturers and device manufacturers to play ball, I think it could be a huge win.
You write down a set of pretty good guidelines and then let it go to court when a manufacturer is found lacking. Court decides. Update guidelines, repeat.
Force listing specific CVEs that have been fixed. A big enough issue currently is that different devices with the same chipsets won't always get the same firmware fixes, thus this ckuld easily be hepled via market competition - if a device A has a fix and device B doesn't, the manufacturer of B can either explain it or pay the fine.
Sounds wonderful, but the entire Android platform relies on patches from upstreams (Linux kernel devs, Google, device driver vendors. Numerous other open source projects that contribute critical components). Timelines like that simply aren't possible. It would kill Android stone dead.
I upvoted because it's an actual concern, but don't agree with your point. Of course non-profit vendors should be excluded from such regulations, providing a best-effort solution.
For other vendors, that would actually be a feature. It would incentivize hardware manufacturers to stop bundling bad/broken Androids with their hardware, open the bootloader and partner with serious free-software organizations who won't break your system or backdoor it. If you really want to roll out broken software for your customers and not give them a choice, pay up.
Then the commercial upstreams will have to provide patches in time in order to still be able to sell their products downstream-wards.
For the open source upstreams... I've heard they accept patches. If not, the source is open, the downstream vendors can fix that. They can even put together a pool, pay into it together, and use the pooled money to develop (and hopefully upstream) a patch...
These are massive companies with revenue in the billions of dollars. If this was regulated, they would figure it out. Frankly, in a lot of cases, it's their own fault that phones aren't updated anymore, not because of any inherent difficulties. If a handful of volunteers can push the latest Lineageos to 7 year odl devices, then Samsung can too. It's just that they have no financial incentive to do so and there are no regulations forcing them to implement what's necessary for long-term support.
This will put many smaller brands out of business, driving up prices on the poor. Most lower end brands barely make a profit as if (often selling at a loss when doing sales).
They don't even have to do their own security updates. If they stick to vanilla Android, they have much less work than if they customize the ROM for every one of their devices. There might even be an industry-wide push for Google to make it easier to update phones independent of firmware blobs (beyond project treble), because suddenly there will be financial incentive to push as much work/effort onto the most obvious candidate.
Random updates can break capability with the firmware if anything that firmware relies on in the kernel changes. Would still require them to fully test every function before each update.
They have no financial incentive to do so because people don't care. So why should the government try to substitute its own remote, bureaucratic judgement?
People generally don't see long-term or on a societal level. Do you think most people wanted seatbelts or the founding of the EPA? A lot of times these are issues that are outside the purview of individuals, outside of their visibility. Most people only care about a small number of things like where their next paycheck is coming from and what to wear going out tonight.
2. The federal election happens later this month. Take this plan with a grain of salt.
3. The original article by heise.de mentions that the federal government will push these plans during negotiation of the EU wide laws. The government thinks that the plans of the commission do not go far enough. However it's unlikely that Germany will implement stricter rules on a national level.