I remember when Let's Encrypt announced they were going to do this in summer of 2019. They listened to community feedback and postponed.
I really want to shout out the LE team for how they handled this. Back in 2019 I was one of the loud people urging to you to reconsider. You massively overshot my wildest hopes on this issue - I never expected you to delay this switch for 4 1/2 years. That's incredible. Thank you for showing this level of care for the TLS ecosystem.
Let's Encrypt is switching to a different root certificate (their own root certificate), which means that extremely outdated devices will no longer be able to access servers using Let's Encrypt certificates.
The biggest concern is old Android devives. By "old", I mean devices using a version of Android from the Obama administration. Android 7.1 is the oldest version that will work, and it was released on October 4th, 2016.
At this point, roughly 6.1% of Android devices are running a version of Android that will be impacted by this change. It's likely that most of these devices are in relatively low-income countries, so depending on your audience this may be much lower or much higher. (If your primary audience isn't in a developing country, it's likely much higher.)
This change will affect you at some point after February 8th, 2024. (Specifically, you'll be affected the first time your LE cert renews after that point. If you're using one of the common clients, it will be up to 60 days after that point.) If you want, you can configure your client to support legacy devices longer, but only up to June 6th, 2024. After then, if you truly need to support very, very old Android devices, you would need to switch from Let's Encrypt to a different (possibly paid) CA.
Only you know for sure if you need to support these very old devices. Most web sites don't.
Its not even 10 years old. The hardware is aging but the only reason its “outdated” is due to a software lifecycle forced by one or more corporate entities. These are an obvious tool to force sales/upgrades.
I’d be nice if this community weren’t so quick to defend planned obsolescence, especially at a 2-3 year pace.
Be nice if government out in laws to force at least a decade of "consistent operations" (it works as well at year 9 as year 1).
Theres really no reason that can't be done, it's not like phones have the amount of variety as PCs and MS and Linux have both managed to handle some much older hardware.
And also any apps that make API calls over HTTPS, regardless of webview, right? I believe they cannot use HTTP, only HTTPS. However, I'm unsure whether they can disable certificate verification. Presumably not, for the same reason...
The typical tax-related depreciation term for computer hardware is 5 years over here. Which is already half of what typical office equipment is expected to last. After which it is usually resold or given away to goodwill. 2016 is just 7 years back, so there will quite certainly mobile phone where the tax writeoff period isn't even through which are affected by this. Truly hilarious!
When talking about security updates it most certainly is. You can’t blame LE for that. That responsibilty lies squarely on manufacturers who are not even maintaining the bare minimum of security patching like an up-to-date root cert list.
I have lots of clothes that I wear that are much older than that. And most that are newer than that use designs from long before 2016. They are only newer because the older ones wore out from use. I can only think of a few articles in my closet that could be identified definitively as newer than 2000 by appearance. I imagine this is true for many men, less often for women I suppose.
That is even worse when you consider that tech brands often design their full lineups with the buying-power of rich countries in mind, their lowest option each year often being way too expensive to the lower classes on developing or poor countries, so there they often advertise previous years' models as the official budget option (often two, three or four years behind). As result that "2016" is more like 2018 in many countries, that is, someone may have walked into a reputable store, bought a "brand new" phone in 2018, and then it will be unable to access those websites just 5 years later.
Compare a 2016-era phone with the current equivalent (e.g. iPhone 7 vs iPhone 14) and there is a huge difference, many of the specs. are 4x those of the older model.
Don't get me wrong, I really don't like the whole 'disposable hardware' culture, but you can't deny there has been a huge leap in tech over the last ~7 years.
My mother has an iPhone 7. She just upgraded from an iPhone 5.
It works perfectly fine for her, it runs the two apps that she uses: Camera and WhatsApp. And the price was reasonable, only half of her weekly pension. There’s no way she could afford an iPhone 14, that’s a whole month’s income.
I still have an iPhone 7. With my usage, the battery lasts 1 or 2 days. I can read the occasional email, my newspaper, use Teams and Telegram when I'm not behind my laptop. It even plays games. What more do I want?
I'm with you, apple stans, but it's worth pointing out it's not the apple devices we're talking about here. That iPhone 7 can run iOS 15, which is out of date now, but only by two years. No letsencrypt certificate troubles.
Depends on how you define "out of date". Is iOS 15 getting new features? Nope. Can the iPhone 7 get iOS16 or newer? Nope. However Apple are still releasing security updates for iOS15, the latest update for iOS15 was just 20 days ago - https://ipsw.me/15.7.7 / https://support.apple.com/en-us/HT213811
EDIT: However, I don't suspect that iOS15 will be supported for much longer, iOS14 last update was back in Oct 2021.
And apple supports iPhones much better. Both iPhone 5 and 7 I believe have the isrg root now. My wife likes older iPhones for weight / size reasons and the longevity of these is impressive especially if you pay for a battery swap
My mom uses an iPhone 7. She took video of us brining out the cake to my child’s birthday. Let me just say, I won’t make that mistake again. The video quality is terrible.
I'm still using my LG G5 from 2016. On my 4th battery right now and will keep on using it until it dies. Still runs smooth browsing the web or even playing brand new 3d games. Batteries are 10-20eur on ebay. The cameras lack nothing and it unlocks with a finger print scanner on the back. This means that in the past 10 years I've spent about 550EUR on mobile phones.
About a year ago a friend of mine complimented me on a new phone, until I told him that it's my old LG, I just stopped using the case. He seemed annoyed after that. Must be because I got funny looks and giggles years back when I said I'll never buy a phone without a replaceable battery.
I have an iPad Pro (1st gen, 2015) that I continue to use as a (secondary) daily driver.
My laptops are both 2015 MacBook Pros.
I’m sure there’s plenty of use cases where the gains are valuable. If you’re a photographer, developer, gamer, or web browser without an Adblocker, I’m sure it’s immense. For me personally, the gains are questionable.
I have an iPad mini that's only a year or two older than that and software upgrades aren't supported, nor are there many (any?) apps available for that version of iOS
I don't agree, I have an iPad Mini4 from 2015, and that's still good for most day to day tasks (although it feels slower than in the beginning thanks to iOS updates being less optimized).
Same with my mid-2014 13" MBP. While my M1 MBP is a lot faster for things like building complex C++ code bases, for stuff like web browsing the old Intel Mac doesn't feel much different.
Compared to the incredible hardware progress between 1995 and 2005 (where a 2x increase per year was quite normal) it definitely feels like we're on a plateau since around 2010.
It is not a matter of the age of your hardware but your software. Ipad mini 4 got its latest OS update in 2023. The problem is that in the Android ecosystem it is unfortunately common to only have a short window of OS updates from the release date of the hardware.
Yes, but parent was specifically talking about hardware specs. And a 4x times increase since 2016 isn't much progress compared to the 'good ole times' ;)
Would you care to elaborate which device it is? 12 years old means it at the most could have come with Honeycomb when you bought it. Has the base OS been updated since? It is great that you bought a device which presumably got OS updates for many years, unfortunately that is not common for android devices. And the problem is, if it did not get an OS update, the truststore did not get updated, and thus it does not trust the LetsEncrypt root CA sometime next year. Except for Firefox which luckily comes with its own root certificate list.
Iphone 7 got an iOS update to 15.7.7 in 2023 and its truststore contains the ISRG Root X1 certificate: https://support.apple.com/en-gb/HT212773 I am unsure which apps you cannot install but a quick look in the app store indicates that Zoom, LinkedIn, Notability, 1Password, Disney+ and Netflix all support iOS 15.7. And in my anecdotal experience I could find no app with a minimum OS requirement greater than 15.7. As far as I can tell you need to go back to iPhone 4S to find an iphone which does not support the LetsEncrypt root certificate. That device is only 11 years old, so still worse than your Android device. And I do not think there is a workaround by using a different browser like for Android.
Interesting - what apps were working as new installs on 12 year old android but not iPhone 7? That’s unusual. iPhones update cycle is much longer and they usually ship w a recent iOS version when released
If your whatever device doesn't support a root CA from 2016, chances you should not let it connect to anything over the internet. Most bad software comes from "hardware" vendors, who think they can handle them the same as any other physical part. Stop blaming software people.
But usually these other devices can also update their software, it is quite unique for the android operating system to run old and unupdatable software.
Or they should if they are web facing. For security reasons at least.
I don't think devices have progressed much in the last 5-7 years. Before that, computers became almost twice as fast yearly. So yes I'm actually denying this. Devices haven't changed much in the last 7 years.
My current phone is a pixel 2 released in 2017. It's perfectly great and there's no reason it couldn't continue receiving updates other than planned obsolescence.
This "huge" difference is only at the top. If anything, the software has gotten worse... my parents hate the "new" gestures... if they didn't give the option for the old bottom row buttons it would be doubly worse.
The very few incumbents that control the modern web infrastructure have (for quite some time now) been intentionally breaking old technology, with absolutely no plans to change this for the future.
It's planned obsolescence, plain and simple. It's just surprising how frequently they obsolete things now. I fully expect them to "train" all the good little consumers out there to replace their phones every year lest most of the web stop working on them.
As someone who had to endure IE6 on the web, I disagree.
There is a difference between "planned obsolescence" and "not wanting to spend a disproportionate amount of development time making sure old devices work".
If 6% of Android users globally are on an ancient OS version, how many man-hours would it be sensible for my to spend testing that our systems work for them? How many of those 6% are likely to be paying customers for us?
Where could we source enough Android devices with pre-7.1 OS versions? How much time and money would that cost?
The small market share of old device isn't a given. There aren't few of them out there because we, the developers, make them unusable and people have to switch.
Most people don't care about having the latest specs, they want the latest features. If new features only ship to devices that are < 2 years old (like Android updates), older devices will quickly become obsolete. The hardware is still fine - I'm writing this on an almost exact 7 year old OnePlus 3 running a barely year old version of Android and the vast majority of things perform perfectly fine. Even the camera is perfectly fine even for modern standards now that I've switched to a modern camera app by tricking it into thinking my phone is a Pixel.
If we stop making old devices obsolete, dealing with old devices will be a lot easier.
The issue here is software, not hardware. An old Android device would be perfectly capable of running the updated root store if the manufacturers bothered to update it. IE6 also could be switched from, at least theoretically.
> If 6% of Android users globally are on an ancient OS version, how many man-hours would it be sensible for my to spend testing that our systems work for them? How many of those 6% are likely to be paying customers for us?
From a purely financial point of view, I agree. But it stills sucks for the 6% and indirectly this is one of the reasons for electronic waste.
In a way there is a long tail of consumers with smaller incomes and living in countries with weak currencies that benefit from computer hardware and software and services that are developed targeting wealthier consumers but still have to deal with the fact they aren't really the target market.
Isn't the EU advocating (or legislating) longer life spans for consumer electronics?
If so, I hope they're covering both hardware and software and configs.
That certs eventually expire is obvious to me now that someone raised the issue. But I wouldn't have foreseen the problem on my own. So I imagine policy makers will need to be informed too.
> Isn't the EU advocating (or legislating) longer life spans for consumer electronics?
Yes, there is legislation for this that mandates a number of OS updates and security updates. I'm hoping Android manufacturers will stop shovelling new SKUs and concentrate on a few they can actually keep up to date.
No no, that's just cave aged mayonnaise, and it sells for a premium. Throw in a blurb about hand crafted artisan, and it'll be a rocket to the moon looking sales chart. You just gotta know how to sell it. These aren't outdated Android devices, they're vintage legacy devices.
I just checked and my own phone is affected by this. Coincidentally I just started getting the "everything feels so slow" thing that seems to inevitably happen to old devices.
It's not that 2016 devices are outdated per se, as a counter point, see the iPhone 7, which runs now on iOS 15.x from 2021, but still receives updates [1].
It is cheap Android handsets stuck on Android 6 Marshmallow or worse that never have received an OS upgrade.
A lot of perishables (food, medicine, gasoline) get "outdated" pretty fast. Sure, as a concept, lettuce will stay with us for a long time. But an individual Bibb head won't last long, even under perfect conditions.
Phones from 2016 are ancient and you can buy newer phones dirt cheap. The Samsung A series costs almost nothing, same with all the cheap Redmi phones and Oppo and whatnot.
Throwing away a phone whose hardware may be perfectly working, but its manufacturer decided to be too cheap to use anything but walled-garden components, feels like an utter waste of resources.
(By walled-garden components, I mean chips whose suppliers make it difficult or impossible to develop an open-source driver.)
This might be less of an option then you'd think. Android software is often compiled assuming the CPU has comparatively recent instruction set extensions. Older devices, especially lower-end devices (which are more likely to be stuck on older software and more likely to be owned by people without the resources to frequently upgrade), might lack those extensions, making the app unusable. This is not a hypothetical. I've experienced this with FF a couple years ago (and even spent a couple hours trying to figure out how to build from source, but ultimately gave up.)
What extensions other than NEON are you thinking of? Neon was made a CDD requirement for Android 6.0, released on 2015. Even before that it was almost ubiquitous. The last shipping devices in any volume missing NEON were Tegra 2 tablets from 2011.
I'm disappointed that we can't come up with a way for encryption to work forever.
Like, if I find a knife from 150 years ago, it still cuts cheese. Sure - it isn't the most modern tech, but it still does the job it was made for. Even though cheese recipes have changed, they are still compatible with an old knife.
Yet a phone in 150 years will be 100% useless. Not only useless because other things have moved on, or because the hardware has degraded, but useless by design because root certificates expire.
We shouldn't be putting anything into consumer electronics with an expiry date.
A knife is an extremely simple tool and you're making a very modest requirement of it (that it should cut cheese). There's no way that a 2023 smartphone is equivalently simple, nor that "Just access arbitrary remote stuff over the Internet" is a similarly modest requirement.
Lets try something appreciably more complex and do an equivalently tricky task. Lets use an 1873 steam train to travel from London to Derby.
We run into more or less the same problem. Functionally, this can work, you'll have to buy the coal from somewhere and hire tankers to move the water where it's needed since there is no longer provision for that- but much harder you'll need to secure an extraordinary amount of special case paperwork to make this happen, because obviously your 1873 steam train isn't authorized to use this route, you will need to retro-fit safety equipment that an 1873 steam train was never designed to work with, and you will need to re-train people to operate it.
Don't worry though, you have preserved the important part - your 150 year old train is still ludicrously unsafe compared to its modern equivalent like the phone. Relatively minor impacts will turn the passenger compartments into kindling, with passengers still inside, because they're basically just a wooden box resting on a simple metal platform, not a monocoque design and even after fitting mandatory safety equipment the train can't effectively stop anywhere close to fast as modern trains if things go wrong.
The encryption itself will work "forever." (Realistically, very powerful computers could some day obviate contemporary encryption).
The tricky part about PKI and signed TLS certificates has little to do with the encryption and a lot to do with networks of trusted parties. People die and are born, relationships evolve, and so these networks are inherently dynamic.
Certificate expiration is a feature by design, and it's included for a reason.
> We shouldn't be putting anything into consumer electronics with an expiry date.
So you wouldn't have half the consumer electronics we have because nobody would be able to afford them.
We should be making consumer electronics with reasonable life expectancies. 150 years in the future I don't want to use something from 150 years ago that "still works", I want something that is new with more capabilities, that is cheaper, that does the thing better. Why create undestructible phones that will last 150 years when nobody other than vintage collectors will want them after ~10 years due to other problems with material degradation, fashion etc.
The optimal point is to not create discardable things, but it's also realising that if you're making something forever you're going to use up way more resources and people will still stop using those devices for other reasons, so you just created more waste.
Too short life = too much waste due to replacement needs.
Too long life = too many wasted resources per-device which will be abandoned for other reasons.
Last night I used some 100+ year old tools to poke a hole in something. But I almost bought a $10 awl last time I was in the store because the old tools aren't really fit for purpose, and they're really just decorations.
Have you ever tried accessing the modern web with a Windows 95 computer using Netscape Navigator?
Even if that computer had up-to-date certificates, basically nothing about it would be compatible with the modern internet. It's not just a question of of "expiry dates", it's that you cannot make any forward progress if you have to maintain backwards compatibility forever.
Internet protocols, file formats, hardware standards... all these things need to be able to change over time. Hell, with the old phone example, your biggest problem with a sufficiently old phone is whether it can even connect to the network - I recently tried using a retro Nokia as a backup phone, but realised that the SIM card I'd put in it was for a network which didn't offer 2G coverage. Phone couldn't even make calls or send texts because it wasn't 3G compatible.
Yes, and it worked hilariously well, because we've worked on bridge technologies for things like this: whether it's local proxies to strip or modify SSL or even just render an entire page as an image and transport it to the old browser as-is.
Solutions will come and go. Hell, what's stopping someone from building an on-device VPN that does the SSL translation itself?
Any solutions for the problem would still only exist in new devices. And the announcement does indeed mention that new devices will be able to update their certificate store.
> but useless by design because root certificates expire
Should be noted that the new design (Android 14) is to allow certificate updates to be separate from operating system updates. Not sure if this is done via a standardized API or something proprietary, so the problem of servers going down forever might remain.
A LOT (like, most of them) of commercial Android simulators use Android 7.1 (some even Android 5). Granted most people usually only use them to play games, but it's great that at least this aspect is covered.
Thanks for the summary. Are there paid CAs that provide tooling like certbot (or work with it)? I don't particularly care about LE or it being free but I like the tools and people using old devices who are easily scared by warnings should be able to use my website...
The protocol used by Certbot is called ACME, and is supported by a bunch of CAs, both free and not.
In addition to LE, there’s other CAs like sectigo, digicert, and Google Trust Services that support it. A few are listed here: https://www.acmeisuptime.com/#CA-Software
Android itself (I.e. Google) maintain thier own list; they manage it well IMHO but made a catastrofically bad desision to never update it outside OS versions (they have fixed this in the next release).
In principle whoever is building the Android system can choose whatever roots they want. In practice the Android Project is a Google project, and follows Google's policies.
Also in practice, Google's policies strongly resemble Mozilla's. Mozilla's root programme is overseen by mozilla.dev.security.policy, a public group. So, to some extent the answer to "Who governs that list?" is you do, much as (if you live in a democracy) it's your fault that your government is terrible. You could work hard to improve things. But, you probably won't.
You can add a root certificate to Android, but if you're not a superuser (haven't "rooted" your phone, different usage) you can only add it as a "user" certificate, not a "system" certificate. After I believe Android 7 apps will by default not trust "user" certificates, so this would not help you, but since newer devices should include the LE root cert this just might be a viable solution. It's still not perfect. It's confusing and (probably by design) somewhat difficult for a lay user to do. And Android will give you a scary message every time it starts, saying your phone may be compromised.
I think you could manually substitute in the old chain—up until the point the signature expires. That would get you until the September date. I wouldn’t recommend it, but that could be useful to buy just a little more time if one was desperate.
Had they gone ahead with their original plan as scheduled, then 1/3 of those using Android would have encountered certificate errors while attempting to browse Let's Encrypt secured websites. Since then people have moved to newer phones and the number of effected devices has drooped down to about 6%. There is still a bit more than a year left before the transition which will of course continue to move the numbers in a favorable direction.
Initially, they likely didn’t think they had a choice. The root that had cross-signed them was expiring. (And I wonder if anyone else was willing to cross-sign them.) It turns out that root expirations are handled differently (i.e. ignored) on some platforms, including the relevant old Android.
> Seems like Apple is doing a better job of convincing / allowing folks to move to a more recent version of their operating system.
Apple isn't selling $10 phones in developing countries. If you compare phones at the same price points from major manufacturers/carriers the difference won't be nearly as drastic.
I don’t know about percentages but I looked up Samsung galaxy phones[1], assuming that would be reasonably fair towards your claim (similar price points, etc). I observe:
- support lifetimes are better than before (now at 4 years by standard).
- but they don’t match up well with versions, eg the S8 support ended earlier this year running an android major version from 2018 (four and a half years earlier), the S9 will[2] stop later this year with a major version that will be four years old, the S10 stops next year with a major version that will be 3 years old.
That’s just what is available rather than what actually runs on existing devices.
For comparison, everything from the iPhone 8 onwards (released nearly 6 years ago) can run the latest OS version, much of it does, and some older hardware still gets the occasional security update.
My understanding of the android ecosystem is that pixel phones are much more likely to be updated than iPhones, though they’re at a lower price point which is why I didn’t look into them.
> My understanding of the android ecosystem is that pixel phones are much more likely to be updated than iPhones
I don't remember the specifics, but I migrated to iOS after being appalled at how quickly my Pixel phone was losing OS updates, including security updates. IIRC, it was due to lose updates after it was less than three years old.
I think all the Pixel devices had at least 3 years of security updates at least from the US release date. There may have been a few variants that released later in the year so they technically had less.
At least now now with Google's own chips (Pixel 6+) the guarantee is 5 years of security updates but still only 3 of Android version updates.
And how long after Google stops directly selling units as new anywhere in the world does Google offer security updates? That’s the more relevant number, no?
At the very least, marketing and packaging for units sold as new near the end of the security lifecycle should have a disclosure like: “We will try to keep this phone secure until [EOL DATE]. Beyond that date, use of this phone may leave you vulnerable to cyberattacks.” Honestly, that would be a great disclaimer to make a legal requirement for all phones, or even all connected devices for which the concept even makes sense.
(Disclosure: I used to work for Google over 8 years ago. But I never had any involvement with Android in any way, other than trying some versions of Android before they were released outside of Google and maybe giving some feedback internally. I’m certainly not speaking for anyone but myself here.)
> 3 years of security updates at least from the US release date
Which means that after an initial period of half a year of "production is still slow, you have to wait" and another half year of "we maybe start selling this to Europe now", for the device I've bought today, updates will last a mere 2 years.
Yeah but iPhones are the least secure phones. You might get 6 years of security, but the amount of 0 click exploits that were seen in the wild have caused death(Khashoggi at a minimum) and nude leaks(Bezos).
I have an S8, while the support may have officially ended this year, it has not received security updates for years.
The only thing I got in the last year was a gps firmware update. Security patch level is still April 1, 2021 so really it's been out of support for over 2 years now.
It's a shame because apart from this huge incompetence from Samsung it's the best phone I've ever had. The latest S23 is far inferior in terms of features. No notification led, no 3,5mm jack, lower resolution display than S8, cameras sticking out of the case, much heavier, no 3D glass, no heart sensor, no pressure sensitive screen. Oh and it's double the price I paid for the S8.
The few things where the S23 is better (CPU speed and photo quality) happen to be things I don't care about. But I do care about security updates.
100% this! I was bemoaning this earlier, I am using the S8 to do exactly the same as I did 6 years ago when I bought it but not only is it much slower than it was when I first bought it (for some reason) but various apps and integrations are already stopping support for Android 9 which is the latest version that Samsung have made available to the phone.
Only the other day, I got a message from Slack telling me their client won't support Android 9 any more, even though, like most apps, I still use the same features I always did.
Don't forget that Apple deliberately slows down your old iPhone when it decides its no longer useful for them to have a bunch of their userbase using old phones.
Plus, Apple users simply don't care about switching their phones, if Apple says they HAVE TO, they will.
> Don't forget that Apple deliberately slows down your old iPhone when it decides its no longer useful for them to have a bunch of their userbase using old phones.
Alternatively: Apple lowers battery drain to reduce the odds of your phone crashing:
The main problem with Apple's actions were: not being transparent about what they were doing (and why), and not giving users a choice (toggle) on whether they preferred speed or longevity.
Meh. Samsung (and Huawei) are still the best selling phones in developing countries.
Samsung could definitely both reduce the unnecessarily large number of SKUs, and better unify their software stack so they could update for 5 years all of their phones.
It's crazy how we went from PCs having the right abstractions, where you can easily keep a 10 year old PC updated, to this awful Android situation.
They are not. Samsung is #1 but after that there is a very long tail of Android smartphone manufacturers that most people in western countries haven't even heard of. Xiaomi, Oppo and Vivo for example all have double digit market shares globally, and combined sell more than Samsung. Realme and ZTE have >5%. The "others" section in most graphs is >30%. If you narrow down the price to say <$100 there is an even larger spread.
Expecting continued multi-year support from manufacturers and carriers is impossible at this range when the sole focus is on driving down the price and nothing else.
Sure. I don't know enough about those companies so I'm not complaining about them.
But I know Samsung has the money and manpower to drastically improve the situation, yet they don't care.
With the right abstractions, they would only have a single version of "Samsung OS", like you only have a single version of Windows/Ubuntu. And all devices within reason would be able to immediately update to the latest version of Samsung OS, like PCs can.
Go to a developing country and see the share of PCs that are running Windows XP and you will realize that things aren't that simple. The majority of the world doesn't care about OS updates, and they are definitely not spending money on it. They simply want stuff to continue to work exactly as it did when they bought it. Mobile phones already get updated at a much higher rate than PCs. The vast majority of PCs in the world stay on the version that the manufacturer installed throughout their lifetime.
And say in your example Samsung does get its shit together and spends a ton of money to upgrade every phone in the world...that's still ~25-30% of the Android population. What about the rest?
The situation is understandable for budget phones sold in developing countries, but that's almost entirely irrelevant to what companies like Samsung and Google do for their flagship products.
> With the right abstractions, they would only have a single version of "Samsung OS", like you only have a single version of Windows/Ubuntu. And all devices within reason would be able to immediately update to the latest version of Samsung OS, like PCs can.
Sorry, but that's just not how developing for mobile SoCs work, and, regardless, Samsung ships Qualcomm chipsets in many of their phones. Once the latest version of "Samsung OS" needs a kernel version beyond what Qualcomm is willing to provide binary blobs for on a particular chipset, that's it for updates to phones that use that chipset.
And sure, maybe they could keep "Samsung OS" limping along on an older kernel, with some missing or broken functionality, but that costs time and money. It's not unreasonable for Samsung to not want to spend it.
> that most people in western countries haven't even heard of. Xiaomi, Oppo and Vivo
Please stop considering US+Canada == "most western countries". Xiaomi and Oppo are big brands, quite popular in Europe (especially Southern Europe), and FFS Oppo are one of the major sponsors of the Champions League, one of the biggest and most popular football competitions in the world.
I've got a stack of Xiaomi phones because they randomly don't work with various south- and southeast-Asian countries' carriers, but not in any predictable or documented way. So I have my Sri Lanka phone and my Maldives phone and my Bangladesh phone, plus two different India phones because of course West Bengal has to be different.
Doesn’t this have more to do with the hardware bands available in the device rather than the carrier software installed on the phone? Perhaps as part of the race to the bottom on price Xiaomi forgoes hardware components that allow a given phone to operate on bands that are common outside the region it was sold in or the carrier it partners with. It would make sense if that was the case, because the people spending $20 USD on a phone typically aren’t going to be traveling a lot anyway
> It's crazy how we went from PCs having the right abstractions, where you can easily keep a 10 year old PC updated, to this awful Android situation.
I feel like TPM and some modern OSes and software requiring it would like a word in that regard. :(
But yes, it feels like PCs are generally more open to both updates and running different OSes instead of smartphones getting turned into e-waste because of the more closed ecosystem (drivers, bootloaders, support).
Samsung is garbage tier and on my list of Never Buy.
They have big marketing campaigns and their phones at max brightness with a cool default wallpaper. The crapware is annoying and the performance is average at best.
Yep. The "median" Android phone is abandoned by the manufacturer within a few years, and sometimes doesn't even see a major OS update. Given the variety of available models, projects like LineageOS can't even keep up with providing an alternative.
I've got a 2017 flagship Samsung Galaxy, and it only ever received 1 update in 2018 - so it was considered defunct by Samsung before my contract even expired. The earlier iPhone 7 it replaced got major version update support to 2021, and still gets minor patches, including one a couple of weeks ago.
Even comparing like-for-like on flagship products, the androids perform poorly when it comes to Long Term Support.
> Seems like Apple is doing a better job of convincing / allowing folks to move to a more recent version of their operating system.
Much simpler than that: Apple doesn't allow third parties to make iPhones, while Google allows third parties to make Android phones. Devices don't get updated because manufacturers stop providing updates for them.
> > Seems like Apple is doing a better job of convincing / allowing folks to move to a more recent version of their operating system.
Apple is doing a better job with operating system updates. On June 21, Apple released a bunch of iOS updates including iOS 15.7.7 [1] for devices going back to the iPhone 6s which was released September 2015--nearly 8 years ago.
There's no reason why the large Android OEMs couldn't do the same if they wanted to.
And that's with 81% of iPhone bought in the last 4 years running a version of iOS 16 [2] five months ago. When iOS 17 is available to be installed in two months, over 90% the installed base will be running iOS 16.
> There's no reason why the large Android OEMs couldn't do the same if they wanted to.
Wrong, there's a big reason: Qualcomm. Newer Android releases often bump the minimum required version of the Linux kernel. If Qualcomm stops supporting a particular chipset, they won't give you new binary blobs (part of what's known as a "board support package" or BSP) for the new minimum kernel version, so you can't update.
Google managed to negotiate with Qualcomm to get them to support old chipsets for longer, but it still falls far short of what Apple does. And now Google is making their own chips for Pixel phones and are doing 5 years of security updates (though still only 3 for major OS updates, boo).
And really, it just boils down to a shitty planned-obsolescence business decision. Apple knows that they will have enough people to buy (either first-time or upgrade) their newest shiny iPhone come release time every year, even if they continue to support 8-year old phones. Google doesn't have that confidence, so they don't put as much effort into upgrades for older devices. And that's Google, who makes fairly high-end phones; the makers of low-end devices know their users are price-sensitive and won't upgrade phones unless they have to.
So it's really two things: one is that they don't want to, and there's no market or regulatory force that pushes them to. And the other is that they truly are limited in how far they can support upgrades, much more limited than Apple is, since Apple controls the entire hardware and software stack.
Having said all that, do understand that I don't endorse or like the current situation here. My Pixel 4 stopped getting security updates (technically last fall, but Google pushed out a roll-up update a few months ago), and I'm frankly not ready to upgrade. The hardware is fine, the software is snappy, and it does everything I want it to. The Pixel 7a is probably my next best bet, but it is yet again a physically larger phone, and I hate that. But this is the situation, and these are the reasons for it.
> And really, it just boils down to a shitty planned-obsolescence business decision. Apple knows that they will have enough people to buy (either first-time or upgrade) their newest shiny iPhone come release time every year, even if they continue to support 8-year old phones. Google doesn't have that confidence, so they don't put as much effort into upgrades for older devices. And that's Google, who makes fairly high-end phones; the makers of low-end devices know their users are price-sensitive and won't upgrade phones unless they have to.
I'm not convinced. Apple controls the iPhone market and can do this, but no Android manufacturer controls the Android market. A brand that deliberately reduces its own devices' lifespan can't trust that its consumers will buy another device from the same brand. I think it's just a matter of not offering support being cheaper than some plan to reduced lifespan leading to new purchases.
OEMs could ship their own security patches. (They are already running frankenkernels. They have some in-house expertise for patching the kernel, making the image, etc.) They don't, because they don't want to spend money on it. (And probably a smaller factor is that they don't want to cannibalize the sales of their newer devices.)
As far as I understand price sensitive users will stop using apps that don't support their device instead of upgrading. (Or will try to roll back the update of said apps.) Providing base security updates wouldn't change this logic.
> If Qualcomm stops supporting a particular chipset, they won't give you new binary blobs (part of what's known as a "board support package" or BSP) for the new minimum kernel version, so you can't update.
This is the biggest reason Google is pushing for there being one version of the Android kernel, across all vendors: to make updates always possible.
They do, actually, via the Open Handset Alliance and Google Play. They are tied by what Qualcomm is willing to deliver in their BSPs, and that's basically 2 years of Linux LTS kernels. So the minimum support level is 3 years; two Android versions and one year of security patches.
Samsung and Google can do 5 years of support because of Exynos/Tensor, and Samsung basically spends the money to support older Qualcomm devices themselves.
Lots (probably even a majority, if we do headcount) of Android phones don't give a fuck about Open Handset Alliance or having Google Play frameworks installed at all.
Supposedly newer Snapdragon chips should get 4 years of security and Android OS compatibility from Qualcomm. I wonder when that 4 years starts because if it takes a year for phones to use a new chip, then it's still more like 3 years.
Microsoft allows third parties to make Windows computers. Windows computers still get updates, and the manufacturer doesn't have to push Windows updates.
Windows OEMs replace significant components of the Windows stack from the trackpad drivers and well beyond. One of my machines is a Dell and they've basically replaced Windows Update because they serve more driver and other updates than Microsoft (slight exaggeration).
Open source isn't the differentiator, IMO. OEM fuckwittery is. Just as Dell can junk up this $3,000 laptop with shitty drivers and shell extensions that are markedly worse than what Windows offers natively, so could other Windows OEMs.
The major difference here I think is that until the recent era, MS wasn't competing with those OEMs so they had little reason to try to one-up MS and every reason to leverage MS for as much of the update infra as possible. For the last 5-10 years, with the Surface line, Microsoft has been increasingly encroaching on the top OEM user base and some are fighting back by trying to outdo MS (and failing).
But I don't think anyone is putting the right blame here on Android. It's not the OEMs not serving enough software updates, it's that in many parts of the world, a 10 year old device can still connect to the network and the carriers are OK with that. That device, even it it was from Apple, would not be getting updates that late in its lifetime but large swaths of the world aren't so fucking hung up on phones as jewelry that they update every year, or even every two, or even every 5. Those ancient Android phones in Bangladesh, they're working just fine for their users and even Apple wouldn't be serving them any better with software updates.
Fortunately the community doesn't have the perverse incentive of a hardware manufacturer. If updates stop flowing it encourages people to buy new devices.
I'm not talking about "the community". There are multiple manufacturers/distributors of Linux laptops. They do nothing to stymie the flow of updates, even though your assertion about selling new hardware would theoretically apply just as much there.
It's a good comparison. I would speculate that it's the target market. If you're buying a Linux laptop you are likely very technical, and know about and want the latest updates. I doubt System76 would get many sales if Pop OS was based on Ubuntu 20.04 and wouldn't get any updates.
However with Android, companies sell 100s of millions of devices to consumers that are more concerned about price point than updates. There just doesn't seem to be the incentive for OEMs to care about it, if the majority of consumers refused to buy devices based on old OS versions or ones that didn't get updates, those devices wouldn't get made.
Rather Google allows manufacturers to control the OS on the phones. If they had kept control of Android instead of allowing dozens of manufacturer forks the update situation would be better (but Android probably wouldn't have been adopted by those same manufacturers).
They're currently trying to move some of that control back to the OS, precisely to enable updates. But unfortunately, in the process they're also moving many core pieces of functionality into Google Play Services and making them proprietary.
Regardless of OS upgrades, which Google and device manufacturers collaboratively do a terrible job with, there's no reason the CA bundle should be tied to the OS version.
Curl's ca bundle page says the mozilla bundle is about 200KB uncompressed, and my Android says the Chrome App is 25 MB, so a 1% increase in app size seems reasonable to keep things current.
Certainly, other apps might also want updated CAs, too, but do they need all of them, or only the CAs they might actually use?
Yes, that's going to be relevant in about 7 years. In the meantime, Google should just include a trust store in their browser. Of course, project Treble was supposed to save us by now.
IMHO, Google really should work on reducing the OS to the minimum needed, and make it possible for apps to share dependencies. If App A and App B use the same X, it doesn't really need to be downloaded and stored twice. For X including CA bundles, libraries, etc. Then you push play store publishers to update libraries and what not to what is commonly installed.
I like to build portable static executables, so I embed the CA roots in every executable I build that needs to talk HTTPS. It'd be great if there weren't so many mom and pop shops in the certificate authority business. It just boggles my mind how the Internet hasn't fallen apart, considering the only thing you have to do is compromise something like a printing shop in France that runs a CA as a side hustle.
I currently run Android 11, and I went through a while ago and disabled any CAs that were hinky or I didn't like what nation they were associated with. AFAICT, there was nothing at all that broke after I disabled so many of these trust anchors. I am not sure if the GP is saying that bundled root CAs can override OS-supplied trust anchors, particularly any which have been manually and administratively disabled, but that would be a disturbing, yet helpful, thing to know.
It's a lot easier to keep your customers' older devices up to date when you control the entire hardware and software stack on them.
Google really has very little say if some random low-end manufacturer doesn't feel like updating their customers. Sure, they can try to require that they provide updates for a certain amount of time in order to get and keep their Android certification, but at some point they'll just give up and ditch Android entirely.
And on top of that, Qualcomm just won't provide updated kernels and blobs for their older chipsets after a while. Google has managed to negotiate them up from their pathetic 18 months that it used to be, but Qualcomm still doen't have to play ball any further if they don't want to. And Google's making their own chipsets now, so they care a little bit less about that problem.
Not saying it's great, but that's just how it is. Android's model basically means it's just going to be that way. Apple's means they get more control over such things.
I get why this currently appears downvoted, but I do think this is a real factor. The camera improvements in particular drive device sales and keep people on a software upgrade treadmill whether they’d update their older devices or not.
To me the camera is probably the least important concern I have with a phone. I don't think I've used my camera yet this month. I would trade a camera for a smaller phone with better battery life.
That has reached some limits in the last few cycles, in my view. The cameras are almost all good enough for almost all users and the only place anyone cares now are the people with a grand to blow for very minor improvements, a fraction of the audience for the fraction of phone sales at the top end.
Look down market even slightly and the cameras on today's upper and middle mid-range or the those on a two or three year old hero phone poll exceptionally well with users today. Sensors, lens packs, and OIS are good enough and cheap enough for even very low light situations and everything else is software (or perhaps some new hardware as we get more ruin like "A.I." enhancements like portrait mode -- God damn if I have to see another photo with that exaggerated depth of field I'm gonna kick something, but even those effects don't need this years model as the hardware and software for that have filtered out over the last 7 years.
I think we're really at the end for the "I need (or even want) the new phone for a better camera." (note Samsung and others marketing moves to streaming and astrophotography as "normal" photos that most people care about are simply good enough.)
Perhaps something more computationally challenging like live deep fake video and things like that will drive sales going forward and that's "camera" sure (but also that AI chip) but photography, pictures, IMO, has reached a plateau and nothing exciting has happened enough yet in video to replace "outrageously better pictures" as as a that now fading upgrade cycle driver.
I think battery (and weight considerations) could be drivers in the near future. Fast charging, IMO, has been a bigger driver of revenue for phone makers than cameras for the last few years and I suspect we'll see marketing and user demand shifting to "does your phone run for a week without bending your spine" or "does your phone charge in under a minute" something like that becoming a focus in 3-5 years and cameras falling down to compete with things like cover glass which has also plateaued and mostly fallen off the users radar.
Apple's rumored battery and size bump and the EU's move to consumer replaceable batteries is a perfect storm for super fast charging, even at destructive levels, then OEM or 7-11 sales of replacement batteries. I imagine we'll also see optimizations in the rest of the hardware and software stack become a focus for that magical week of battery that's probably not a decade away.
Photography, like cover glass, is bound by some pretty daunting constraints of physics and I think we've hit "good as it's gonna get" or "good enough" or some combination of those for a while and so phone makers need something new to drive their annual or biannual upgrade cycles.
Apple hopes VR will be big and replace a lot of phone and pc use cases, perhaps the way the iPhone and iPad did so much of that 15 years ago, but I don't see that happening for another decade or three (I've used various head mounted VR kits since 1993; it's not happening any time soon.)
Android is too fragmented to say what that ecosystem is betting on over the next 5 years or so, but I'm gonna wager it's battery and screen followed by performance, camera, and then storage, durability and IP rating and all those other "a few small but big spending segments care enough to keep improving" features.
Almost all of the things that ios brings with update could be done with an android app update. I have been using ios since ios 9 and my usage is exactly the same since both in ipad and iphone: swipe or search for the app you want and use it.
I would be more concerned about security updates though. What percentage of ios and android have all security updates released say t-7 days before applied?
This is probably a big part of why people don’t generally opt out of iOS upgrades: they’re basically just annual app upgrades packaged together (notwithstanding some pretty conspicuous Safari updates in recent point releases), anything OS level is mostly iteration on a mostly stable core and has been for almost a decade.
I do think they could and should be more aggressive with security updates. Both by releasing/messaging those separately from other kinds of point releases (improving but not great), and by notifying sooner/more frequently. It definitely irks me when I find out about a critical security patch over a week after it was available, and that the security content is a secondary link with no immediate conveyance of its urgency. And they should also make it a lot more obvious how to go find out if an update is even available in the first place.
Even today(?)’s rapid response, I had to read about it on some site and then remember the incantation to go look to see if the update was available. Of course it was, so I tapped download and install. After waiting a while, I switched to another thing. When I came back, it was downloaded and ready and waiting for another affirmative to do the thing I already requested. I should not need to do any of this when I have automatic updates on.
> I do think they could and should be more aggressive with security updates. Both by releasing/messaging those separately from other kinds of point releases (improving but not great), and by notifying sooner/more frequently.
Normies usually have their updates set to automatic, so they get the updates a soon as they're out.
I count over 9 security updates for iOS 16 [1] as of July 10th, with the rest of the year to go. I feel like as soon as any type of update is released by Apple, I'm inundated with the news from many websites, RSS feeds and the PGP-signed email from Apple with the news [2] [3].
> Normies usually have their updates set to automatic, so they get the updates a soon as they're out.
I have my iPhone and iPad both set to automatic updates, as are some others in the family. I have noticed several times when my iPad will get an update and then a couple weeks later I'll be on another family member's iPad and notice it still hasn't done the update yet.
Have automatic updates on, and very frequently my iPhone will skip updating despite having left the phone plugged in and connected to the Internet overnight. I check it in the morning and it will say “failed to install update”. Then I’ll have to fight it for the next 5 minutes to get it to actually begin the download.
I think the promise of new emoji is often a compelling reason for people to update.
A few features I’ve found particularly impactful in recent updates, which do feel like they require a deeper change than just an app are:
- translate button on selected text (and the translation works sufficiently well)
- OCR + selection of text in images, automatic OCR and indexing of text in photos
- oftentimes if you select something in some units, you can select the text and see a conversion to other units (though it is a bit fussy about what it accepts, e.g. it doesn’t like 5’, 5’1, 5’2”, 5lb 3oz, but it is ok with 5lb, $1, 1$, or USD 1)
- Emoji are an app update away. Assuming your app is using the appcompat library in Android (it is almost certainly) you'll get all of the emoji the next time you auto update your dependencies. The latest version of this library works from Android 4.4 to Android 14.
- The translate button has been in Android for ages but it's using the standard context menu API. Not many apps use it and very few users care, but it's there. Very useful for sending a bit of text over KDE connect!
- OCR + text selection was brought to my phone by a Google Pixel Launcher update. I didn't even notice it until I accidentally selected text from the task switcher.
- I have no idea why OCR is not in Photos yet, I guess the Lens button is good enough for Google, which has worked for years now.
- I guess I don't have unit conversion built into my phone? I could probably install an app that does it from the context menu but I can't say I care. That's what Google Assistant is built into Android for.
None of these features require an operating system update on Android. They're often released around/after a new major Android release, but that's just Google's release schedule. Apple could probably apply these updates through the app store as well if they bothered, but they prefer collecting updates for a year and releasing the as new features all at once.
It really weird that given everything these days needs to be a subscription, why isn't someone building a relatively cheap phone, with a yearly subscription to keep software update coming.
Other than a smallish group if tech enthusiasts and people who consider phones fashion, I argue that most are perfectly happy with their 2020 iPhone or 2018 Android phone. They are clearly not replacing them as fast as the industry expects, so may a small fee for updates, so you avoid having to replace the phone would be acceptable.
And yet Android devices that are 7 years old get the latest & greatest APIs, whereas I won't be able to use the new OSLog functionality built into the iOS 17 SDK for 3 years
The Android compatibility libraries are a godsend. Sure, your users won't run the latest version of Android for a year or two at least, but you can use almost every new Android feature the moment it's presented and it'll work out of the box for the vast majority of your users.
Want to use a modern web engine but your customers are running a seven year old OS? No problem, the webview updates come AUTOMATICALLY. Want to integrate with Google's new nearby share mechanism? It's already present on the same devices. Google's cloud API changed as part of a recent Android update? No matter, every API feature has already been working on every outdated phone since before you even know there was going to be a problem.
You do end up with annoying clutter supporting all of these devices because of API/permission changes, but it's all quite easy to deal with if you just stuff the compat code away behind an abstraction.
Not having old phones on your platform is a failure, not a success. Old Android phones still work okay. Apple isn't giving away free new phones - there is no right to repair.
The way they got that old cross sign to keep working was quite interesting:
> The new cross-sign will be somewhat novel because it extends beyond the expiration of DST Root CA X3. This solution works because Android intentionally does not enforce the expiration dates of certificates used as trust anchors. [1]
Trust anchors work really differently than other certificates in practice, which can be surprising [2].
IIRC one of the bigger problems was that older versions of OpenSSL did check root anchor expiration. But that wasn't all - at my then-employer we had a brief outage on some of our systems because Ubuntu had to patch something (I don't recall what) to deal with this, and they only released the patch a few days before the expiration. We had to mass-rebuild all our Docker images to fix the issue.
This workaround was so wild and unprecedented that I assume the cost difference vs. getting cross-sig from an unexpired (and widely compatible) root was massive for them to use it. There must have been a huge amount of testing involved. The fact that it went as smoothly as it did (mostly, but not completely) was impressive.
I was a bit surprised that the Android way is not how it works everywhere. I had assumed that the time validation of a TLS certificate chain C0 -> C1 -> C2 ... -> Cn went something like this (in pseudocode):
1 time_check = now()
2 for cert in Cn to C0
3 if time_check < cert.valid_from || time_check > cert.valid_to
4 return EXPIRED
5 time_check = cert.issue_time
6 return NOT_EXPIRED
but a bit of Googling shows tells me that it works like that pseudocode with line #5 omitted so that all the time checks are against the current time. All certificates in the chain must be valid now.
With code signing certificates it does work the way I assumed TLS work. Timestamped code signed with an expired root certificate is still valid as long as the root certificate was valid at the time of the timestamp.
> the cross-signed certificate will expire. This should be a non-event for most people
Let's hope so. But the last DST cross-sign expiration wasn't a non-event. IIRC, GnuTLS failed to correctly path-build after the expiration (AFAICT, it would only build a path to the expired cert, see that it was expired, and then abort, ignoring all other possible paths); worse, GnuTLS is the TLS library used by apt (when using HTTPS, which isn't the default, but my security team wanted all packages vendored and served securely — which … sensible, but yeah. An outage was the cost). (This was fixed in Bullseye, I think? Which was literally like a mere week or so before, by sheer luck.) Azure also had multiple outages caused by or surrounding that expiration.
Wouldn't the operators of all apt mirrors be renewing their LE certificates with certbot every month or so? Then, after June 6th, 2024, they will get a new certificate signed by the new LE root, which isn't cross-signed and isn't expired.
Hmm. I do think you're correct, at least in theory, but somehow we had DST certs in the path that got built. I forget the exact details of the two — I think it is the — R3 certs at that time.
All I know is that apt (through GnuTLS) stopped being able to install, and it was a massive headache. We upgraded to Bullseye (where apt seemed to not have whatever bug ailed it) at that time, and that fixed things.
One would think the Authority Key ID info would be the only thing that could define a path up the tree. There's also an option in ACME to get "alternate" chains, and I forget which chain was the alternate at the time. (I feel like it might have been the non-DST one, b/c the DST one was being preferred to get compatibility w/ Android, who would not realize the cross had expired, or something. But I also didn't learn about alternate chains in ACME until the expiration forced me to out of necessity.)
(I'm not sure how rigorous path building is, but the general state of TLS tooling leads me to believe it's a giant ball of yarn. Even since then, I have seen a bizarre apparent path to the expired DST root get built, although the circumstance in which I saw it afterwards was contrived, and involved a vendor (Hashicorp) adding a leaf (i.e., non-CA) cert to the list of CA certs, and doing it in such a way that leaves OpenSSL's internal structures in that dir corrupt. OpenSSL, in that situation, somehow, found the DST cert once again. Removing the leaf cert form the store caused the validation to succeed, but … OpenSSL's docs are not really clear about how you can or cannot screw about with its on-disk data. I call such shenanigans UB, and you reap what you sow, but I couldn't convince them of that. We lived with the issues that bug caused until it was apparently fixed in a later version.)
Caching, people misunderstanding (and misusing) TTLs, bespoke service discovery on top of DNS without understanding the aforementioned, bespoke stringly-typed configuration languages in various DNS records, etc.
Yeah, but almost nobody uses it (it's got low single digits uptake in the US, and has actually decline in some years), so that's not the part of DNS that's making it brittle for deployments.
A DNS client from the 90s will have no trouble communicating with current DNS servers and BGP only matters to internet backbone routers. Neither of them cause any problems for old devices.
The issue isn't that TLS keeps changing. It needs to for security. The bad thing that leads to planned obsolescence is that devices stop receiving manufacturer updates so soon and can't be updated by third parties. My preferred solution would be a law that if a manufacturer needs or wants to stop producing security updates sooner than 10 years after sales ended, it'd either need to open-source everything or allow everyone who ever bought one to return it for a full refund.
It's an interesting idea, but it needs some refinement.
> either need to open-source everything
That'd be problematic, as in many cases the vendor doesn't even have the full source code (think: all of the embedded chips that run their own RTOS), let alone the legal right of relicensing it. Another thing is build reproducibility, the ability to actually flash/install the code, etc. It would be desirable to have all that, but it's far from simple.
> allow everyone who ever bought one to return it for a full refund.
Regardless of the actual physical condition of the item? I would say something like a trade-in program, where you get a % of the original value depending on overall condition. But then it gets tricky as it's difficult to write into law, what "good condition" does actually mean. What if the device has two screens, but only one is broken? What about components that tend to wear out or break during normal use (batteries, straps, hinges)?
But having that process in place could also actually help us recycle more stuff.
Also, consider the smaller companies, that don't have the resources to effectively give you a 10-year warranty on their product. That'd just get the bigger corps even more entrenched (while they figure out the "legitimate interest cookie" equivalent of still screwing you over).
> That'd be problematic, as in many cases the vendor doesn't even have the full source code (think: all of the embedded chips that run their own RTOS), let alone the legal right of relicensing it.
I consider making closed-source more legally difficult to be an additional benefit, not a downside.
> Regardless of the actual physical condition of the item?
Yes. The idea is that it'd be better for things to continue to be safely usable rather than to have to become e-waste, so if the manufacturer chooses the option that requires the latter, the deal should be as one-sided as possible against them.
> Also, consider the smaller companies, that don't have the resources to effectively give you a 10-year warranty on their product.
Software updates are a lot cheaper than full warranties, and if they make all of their stuff open-source then there'd be nothing else they have to do at all.
I do smile a bit when I see solutions yo problems described as "there shoild be a law".
Firstly, the obvious, laws are local not global. Your proposed law would need to be ratified by 200 odd governments. This seems unlikely (Not least in the US which perfers not to ratify international laws). Given that China is least likely to care, and given that most really cheap phones originate there, I'm not sure your proposed law will work there.
So, to summarise, suggesting global laws, while not necessarily wrong, is as fruitless as suggesting that we use magic pixie dust to solve the problem. Both have exactly the same liklihood of being adopted.
I'm not so sure. If either the EU or the USA pass such a law it would change the situation a lot on the entire world for the same reason car regulation and school textbooks follow the tune of the largest jurisdictions. If you have to expend the money to comply with the law in one country you might as well sell the same phone in other countries.
The 5% of problem Android devices on the Internet are not manfactured or imported in the US. So the US law sounds great, but isn't solving a problem.
Plus, given that the proposed law dictates -future- behaviour I'm not sure who, how or where an affected person (one who only has money for an ultra cheap phone they haven't updated in 7 years) would get relief from.
To fix the "future behavior" problem, maybe the law could work like this: make selling a device at all require escrowing the full source code, and if the manufacturer stops releasing security updates, the government releases the source code.
Not really. You’d have to make sure you either own the software you ship or that software is already available freely so you don’t get into the space cadet situation like Microsoft Windows.
> Space Cadet Pinball was not originally written by Microsoft, but was rather obtained via licensing from a company then-known as Cinematronics. This means that there are restrictions on what can be done with the program, as spelled out by the license agreement.
If you don't want others' preferred software licensing policies to be legally mandated and binding on you, are you in favor of abolishing copyright for software?
That is the fundamental difference between free software and open source.
Free software centers around the user.
Everything else is a means to that end.
Open source centers around the authors.
This is fundamentally misguided.
I couldn’t give two [deleted] about authors and what they want.
I'm all for it. Let me pay twice the price for my phone and keep it ten years. It's a better deal for everyone, and firstly for the planet - no need to dig up rare minerals and waste energy and water to churn new phones all the time.
It seems like most of what's bugging you about TLS is having to keep up with certificate reissuance. The reason you have to deal with that is that global-scale distributed revocation is a ludicrously hard problem. To mitigate the fact that some bindings of users-to-certificates are effectively irrevocable, you shorten the lifespan of certificates, so their blast radius is smaller.
This is cold comfort, of course (though: the post-ACME world of short-lived certs has better DX than the nightmare world of long-lived Verisign certs), but it's worth noting that any alternative to TLS would face similar problems.
Certificate revocation is a really interesting problem, because it's obviously vital but also pretty rare. Currently, to validate a certificate, every client has to walk through every certificate in the chain and ask for the CRL or make an OCSP query, just in case. It's incredibly wasteful and subject to all sorts of problems. It's really fun verifying file signatures on a machine with no direct internet access.
It would be nice to have a centralized push-based solution or something. I dunno, hard problem.
I think fundamentally, it is impossible to trust any entity forever. The best solution would be certificate updates outside of normal update paths. Its not like the format of x509 certs have changed in basically ever.
I suspect that protocol churn will settle down now. TLS 1.2 was introduced in 2008 and still considered ok, so its hardly that new now. Lots of people looking carefully hopefully means most of the issues have been flushed out.
It's true that TLS 1.2 is still considered OK, but cacert now only serves on TLS 1.3, Windows 7's integrated HTTP stack only supports TLS 1.2 and below, and Scoop relies on using PowerShell or similar to download cacert before it can install curl, meaning I can no longer install curl that way on Windows 7 (still an OS nearly as usable as Windows 10 and Linux, though apps are sadly starting to drop support for it).
IMO, you could argue what Let's Encrypt does is basically DANE so why not just support it, but there may be use cases where DANE isn't appropriate. I don't see why perfect has to be the enemy of good though, let folks use DANE if they want.
> Is there any proposed solution (other than just using unencrypted HTTP) that would make it so TLS is no longer the most brittle component of the web?
Unlike HTTPS/TLS, it doesn't provide protection against active attacks, but at least prevents passive ones. So it couldn't be used for https:// URLs, but would be a security improvement for http:// ones. And no certificates to manage
Not a whole lot of point if you dont care about active attacks. Active attacks aren't that hard. With the exception of mass survelience in the usa almost all attacks you actually care about can easily be active.
Historically there are lots of passive attackers (and we don't know or think about them because they're passive), while a lot of them have been reluctant to become active attackers (because we might notice them!).
E.g. you could try to randomly record both ends of a TCP connection and then compare them out-of-band to see if someone in between tampered with the contents. (Although my late former colleague was working on a tool to do that and it turns out that there's a lot of noise and complexity to contend with in trying to make it practical, e.g. because of packet loss, retransmission, fragmentation, and changes like NAT by middleboxes that consider themselves benign.)
Random example of a passive communications interception attacker:
I don't agree with this logic that "either you have perfect security or there's no point".
I think a lot of stuff on local LANs is still HTTP-only because trying to do TLS for local devices – even with LetsEncrypt – is a pain. Not impossible – you can't get a TLS certificate for 192.168.12.34, but you can create a public DNS entry pointing to that and then use a DNS-01 challenge to get a certificate for it. But that's enough work that heaps of people don't do it.
It also makes local LAN reliant connectivity reliant on public DNS – since you can't do https://192.168.12.34 you have to do https://device-12-34.example.com, if your Internet connection is down you might not be able to resolve device-12-34.example.com even though the device is up and accessible on your local network. Adding a local DNS server will fix that – but now that's another thing you need to make it all work.
Whereas if we had opportunistic encryption for http://, that would make local LAN passive attacks a lot harder. Yes it wouldn't stop against local LAN active attacks, but security against passive but not active attacks is still better than no security against either.
IPv6 actually resolves this. Not with Let's Encrypt (because they won't issue a cert for an IP address) or ZeroSSL (because they currently don't support issuing certs for IPv6 addresses), but it is definitely possible.
You wouldn't even have to expose the private network to the outside world. It could still be firewalled off.
Say if your prefix is 2a09:1337:8888:aa::/56 and your private prefix is 2a09:1337:8888:aaff::/64, just make sure that the router redirects all traffic from outside to the /64 to a box that listens for connections so a certificate can be issued. Of course you'd also need to be able to reach the said box from boxes within the private network (for .well_known cert requests), but it's trivial. No BGP required. Simple HTTP challenge.
Thanks for bringing up the local network scenario -- I've been skeptical of these kinds of opportunistic encryption schemes, but issuance for LAN devices is indeed a pain and seems like it would be well served by something like tcpcrypt.
At the same time: how do you foresee this interoperating securely with TLS? My first intuition is, without something even stronger than HSTS, that this would open up additional downgrade attacks against HTTPS: an attacker could do a normal HTTP downgrade and then present a TCP-ENO session that they control the key for. That's perhaps no worse than the downgrade itself, but I could see it being a source of user confusion if browsers choose to present this kind of scheme as "secure" in the UI.
> At the same time: how do you foresee this interoperating securely with TLS? My first intuition is, without something even stronger than HSTS, that this would open up additional downgrade attacks against HTTPS: an attacker could do a normal HTTP downgrade and then present a TCP-ENO session that they control the key for. That's perhaps no worse than the downgrade itself, but I could see it being a source of user confusion if browsers choose to present this kind of scheme as "secure" in the UI.
The obvious solution to that problem is - don’t show it in the UI by default.
For sophisticated users, have a config setting they can turn on which will show some kind of icon (not the padlock, a different one). For unsophisticated users, make it invisible.
Invisible protection against passive attacks is still better than no protection against passive attacks. But passive-vs-active is beyond the understanding of non-technical users, so for them keep it invisible.
What scenarios do you imagine where someone is willing to do a passive attack but not an active attack on the local lan? Local lan seems like the easiest place to do active attacks.
I agree that perfect can be the enemy of good, but i also think its important to do things that stop actual attacks. Things that make attacks just mildly more difficult are pointless since the attacks are going to be scripted anyways.
I'd think that a cache of known keys (trust on first use), synchronized across devices using browser sync, would be quite effective at protecting against MITM attacks as long as your first access to a LAN server (on any computer you have) is safe. Additionally there are orders of magnitude less attackers to a computer on a LAN than an Internet-facing machine. In fact, unless I have untrusted boxes on my network or targeted attacks, I actually feel safe hosting HTTP services (and I'm doing so right now, more or less safely), and if someone is performing targeted attacks on my network they could just break in and clone my hard drives without having to bother MITMing my connections (I value the ability to access my data across dual-boots more than I value disk encryption through Bitlocker or Linux-specific methods).
> I'd think that a cache of known keys (trust on first use), synchronized across devices using browser sync, would be quite effective at protecting against MITM attacks
How do you distinguish between a host you have seen before that has a mismatched key vs a totally new host which you have never seen before.
I guess it depends on how you are discovering these resources in the first place, but traditional answers like IP address are much less workable on the local network.
If I buy a new computer, I’m expecting an untrusted key message the first time I SSH to it. Whereas, if suddenly I got that message with an existing box, I’d start investigating. How would trust-on-first-use for HTTP on local network be any different from SSH on local network?
Based on their 2021 (most recent year available) Form 990 (nonprofit public tax filing) [0] they paid Identrust $434,000 for "Internet Services." Not sure if they are getting more than just the cross-sign from Identrust - but it seems likely that may just be what they are paying for the cross-sign.
In that same year, their total expenses were $5.1M - so that expense would make up almost 10% of their budget.
As the person who negotiated the agreements between Let's Encrypt and Identrust I can tell you that they have provided valuable services, including but not limited to cross-signs. I would not describe it as rent seeking.
We are sincerely glad to have them as partners, and grateful for their contributions to helping get Let's Encrypt going. We could not have done what we did without them. Running a publicly trusted CA is not easy, and cross-signing others involves work and liability, particularly if the entity asking for a cross-sign is an upstart with a strange plan and little to no experience running a CA.
Cross-signing a CA is many orders of magnitude more work than signing a single domain leaf cert. Sure, on a technical level the result is similar - a signed X.509 cert, just with the "CA" flag set to true, but it's a very different proposition.
Imagine if a CA cross-signed some new, upstart CA to get them browser compatibility (like IdenTrust did for LE), and then the new upstart went rogue and started issuing phony certs for google.com, wikipedia.org, etc. on behalf of [insert totalitarian nation here] state security. Those certs would chain up to the cross-signer's root, and they're responsible for it. They could face removal from root programs if they were reckless about cross-signatures.
So if a root CA wants to cross-sign a new CA, they need to make sure that the new CA follows the same policies and gets the same audits as a root CA, because their ability to break things will be basically equivalent to a root CA.
Honestly, <$500k for all the admin work on this sounds reasonable to me. It probably took a huge portion of several people's time throughout the year.
They are also paying more for bandwidth for the cross-sign certs. I'm not sure exactly how much it is but it's not 0. Serving and computing and sending extra bytes costs money too!
Let's Encrypt killed the business model of selling domain-validated certificates for $10 a year. (Much more if you wanted a wildcard!)
A company like RapidSSL or GoDaddy would never have cross-signed Let's Encrypt, unless they offered "buy our whole CA business" money.
But selling DV certs wasn't IdenTrust's business model, so they were happy to provide a cross-signature for (according to some speculation elsewhere in this thread) less than six figures. And because of how TLS root certs work, a cross-sig from IdenTrust was just as useful to LE as a cross-sig from one of the ultra-profitable CA's.
If I were a cert company whose target market were large enterprises unlikely to use LetsEncrypt, I would do it in order to undermine my competitors who might depend more on small businesses and other types of projects that find LetsEncrypt appealing.
Those numbers are misleading. IdenTrust has always been a small CA in terms of volume. The large percentage you see for them there is actually Let's Encrypt volume counted as IdenTrust because of the cross-sign. The Let's Encrypt percentage there is from sites not using the cross-sign. Add them together and that is basically Let's Encrypt's total volume, as IdenTrust itself is likely < 1%.
> Doesn’t letsencrypt completely kill their business model?
Not at all. Major cert authorities are all selling to businesses, and that will continue to be the case. Letsencrypt's users are almost all in the personal/hobbyist space.
That's an illussion big CAs want to sell. It's not true. Plenty of businesses use Let's Encrypt certificates.
From a technical point of view there is no reason a business cannot use Let's Encrypt. The certificates provide exactly the same security. There is really no difference in the encryption you need for a "personal/hobbyist" site or a business site.
Yeah, CAs still successfully convince some businesses to pay a premium, because they don't understand how TLS works. That mostly works because in "business terms" the price is still low.
> Letsencrypt's users are almost all in the personal/hobbyist space
That may have been true in the early days of Let's encrypt. But today, if you're using any of a number of newer hosting options (Netlify, Vercel, Fly.io, etc.) you're probably using a let's encrypt certificate.
Older/more staid companies will mostly still be using certs from Digisign et al., but there's little reason for new companies to pay for that.
For the default URLs generated when you deploy an app, sure, but companies using them commercially are all bringing their own domains (with their own certs).
Nope - having built out the SSL termination stack for a similar company - they are serving millions of commercial sites on their own custom domains with let's encrypt issued certs.
Additionally, in the early days of letsencrypt there was more reason to buy some form of extended-validation EV/OV cert (which lets encrypt does not provide) than there is now, with browsers no longer providing UX distinguishing such.
There's this perception that businesses like to throw money away that they don't have to.
When LE came out they already had multi-year certificates, so they just used those. At the time many were convinced to switch from DV to EV [1] certificates. Since then the (alleged) benefits of EV certificates have vanished. [2]
Thus the argument to spend budget money on thing-we-can-get-for-free is very thin. Sure, there are some die-hards, but since they are literally wasting money they become fewer either each passing day.
[1] DV = Domain Verified which is what LE issues. EV is Extended Verification and costs several hundred $.
[2] Off the top of your head name 3 domins you visit that use an EV certificate. You can't because you can't tell if they do or not. And since no-one cared when you -could- tell, no-one complained when bring able to tell went away.
[3] LAN certificates was the last "hurdle" and that's been automated away as well. So now those spending money on CAs are just using up their budget, and not getting something for it.
Our company uses Let's Encrypt for HTTPS traffic on our own internal networks. It is free, convenient, and cert-manager handles it all "auto-magically" for us.
I worked with a large CDN provider (not that one, the other one) who would rubbish LetsEncrypt in meetings -- then note that they use LetsEncrypt themselves for domain validated certificates. So we should pay them extra for OV certificates, the logic of which only makes sense to their salespeople.
My employer isn't a heavy user of LetsEncrypt, as AWS's certificate issuance is more straightforward to use when we're already using AWS for pretty much everything. But we still have a few hundred LE certificates that are in active use.
> Come late 2021, our cross-signed intermediates and DST Root CA X3 itself were expiring. And while all up-to-date browsers at that time trusted our root, over a third of Android devices were still running old versions of the OS which would suddenly stop trusting websites using our certificates
I only noticed this a few weeks ago, apparently ubiquiti users were also affected.
FWIW I recently had to switch to ZeroSSL from Letsencrypt which I normally use, while porting a backend from AWS (that used their certs) to a local server, as the IoT gear from 2016 we're supporting didn't have the root certs that validating LE certs required (this was related to the 2021 expiration of the R3 root cert I think it was that LE used).
It was kind of an eye-opener that you could potentially brick a whole fleet of sold products by a cert expiring. In this case it was no real problem as other providers had certs with valid root certs.
When SHA-1 was being phased out, there was a lot of whining on mozilla.dev.security.policy from CAs who had issued SHA-1 certs installed into medical and point-of-sale systems with no real update options, then continued to issue them well after the dates that the CA/Browser forum voted on. I thought everybody realized at that time that using the Web PKI and having no way to push updates are mutually exclusive, but guess not.
I've been stripping off the cross signed certificate on my desktop-targeted sites shortly after it was introduced. I found it caused compatibility issues when there were none before as some certificate validators were tripping up on the expired root certificate. I was unfortunately never able find out the root cause as the affected users weren't very technical.
TL:DR: If your webste clientes use Android 7.0 or earlier (released 2016), you may need to take action to ensure you can still access websites secured by Let’s Encrypt certificates. By Thursday, June 6th, 2024.
There's also the possibility that Chrome decides to bundle this CA like Firefox mobile does, which would mean the majority of users won't have a problem. From 5.0 the builtin webview is updatable too - I think it uses Chrome's engine.
That leaves other browser's such as Samsung's one which probably has the most usage, no idea if they bundle root CAs or not.
3 billion seems like decent number to use for how many Android users there are [1]. 4.5% of 3 billion is 135 million or about 13x more than Google Domains [2] so I guess not major indeed.
I wonder how skewed to poorer countries that is? Also I imagine some skew towards smart tvs (since they outlive older phones, you could easily have a 2013 smart tv still working, I had a 2009 dumb TV until recently and sold it on).
> In addition, dropping the cross-sign will reduce the number of certificate bytes sent in a TLS handshake by over 40%. Finally, it will significantly reduce our operating costs, allowing us to focus our funding on continuing to improve your privacy and security.
So this was one of the trap aspects of the free cert. lol. This is how you shape the landscape, by offering something for free, then when you have a big user base, just start making your own rules. No wonder LE was supported by so many waterheaded IT companies.
"If you see a sudden drop in visits from Android, it is likely because you have a significant population of users on Android 7.0 or earlier. We encourage you to provide the same advice to them as we provided above."
"I want the free service to work for my edge case"
If you want to continue serving your clients, you can still pay for a certificate from an authority trusted by your outdated clients. If you want to continue serving the old clients for free, ask them to use another free browser that will allow them to do so.
This isn't just making up rules on the spot. Certificate expiration are always known in advance, and the cross-signing was never a guarantee -- especially when that cross-sign extends the lifespan of the root.
#/media/File:Orion_MENTOR4_(USA-202).jpg){kind=link}
I really want to shout out the LE team for how they handled this. Back in 2019 I was one of the loud people urging to you to reconsider. You massively overshot my wildest hopes on this issue - I never expected you to delay this switch for 4 1/2 years. That's incredible. Thank you for showing this level of care for the TLS ecosystem.