I'm not sure why there's a need to update anything every 2-3 years. In fact, the pace of change becomes exhausting in itself. In my day-to-day life, things are mostly well designed systems and processes; there's a stable code of practice when driving cars, going to the shops, picking up the shopping, paying for the items and then storing them.
What part of that process needs to change every 2-3 years? Because some 'angel investor' says we need growth which means pushing updates to make it appear like you're doing something?
old.reddit has worked the same for the last 10 years now, new.reddit is absolutely awful. That's what 2-3 years of 'change' gets you.
In fact, this website itself remains largely the same. Why change for the sake of it?
Not that you’ll agree, but cleaning the house sounds more like running rm -rf /tmp and docker system prune than upgrading from idk, bullseye to bookworm. Let’s call that a bathroom remodel? So sometimes you live in a historic house and the bathroom cannot be remodeled or changed because it’ll fall through the floor or King Louis the XV used it once. In software, the historic house could be the PLLc firmware controlling the valves in your nuclear reactor cooling loop.
And then the new car no longer has the camera where you need it, the panel buttons changed, the cup-holder is in another place. Even worse, the upgraded firmware & OS of the car no longer comes with an app you needed; or it does, but removed a feature that was essential for your daily use. All because some SWE takes "computer security" as more important than having an useful system.
It's the kind of rhetoric that enables shoving down user-hostile features during a simple update. And breaking many use cases. Quite common in the FOSS/Linux mentality, not so much on the rest of the world.
OTOH I never lived 5 years in the same place and I think it is not that bad of an idea when I look at the sheer amount of unused or barely used shit people hoard over the years in their house.
Then one day people's health or econoly dwindle, they need to move to a place without stairs or to a city center clother to amenities such as groceries, pharmacy and healthcare without relying on a car they cannot drive safely anymore, and moveming becomes a huge task. Or they die and their survivors have to take on the burden of emptying/donating/selling all that shit accumulated over the years.
Every move I assessed what I really needed and what I didn't and I think my life is better thanks to that.
I understand this is a YMMV thing. I am not saying everyone should move every couple of years. But to many people that isn't that big of a deal and it can be also considered in a very positive way.
Backward incompatible change means there is cost associated. It is like changing your furniture every 6 months. New furniture is fun, but unless your needs have changed (like marriage, children), it won't add you any benefit other than a new look...
Agreed. Food now is made to order, rather than being ready and waiting (likely to reduce stock waste). Last time I went there was hardly a queue, wasn't rush-hour (was quite dead actually, few staff, fewer customers).
Food still took 15 minutes, fries were cold, the main meal was nice but was overall disappointing for the eye-watering cost compared to days gone by.
And a few guys collecting for delivery which has split their focus from in-resturant customers.
This is a trend that's probably going to continue and widen the rich-poor divide. Take airlines, there's only so many seats they can offer day to day, and with planes retiring from service and new planes slow to be delivered the inequality will only increase, and the market will shift to more affluential customers.
The likes of McDonald's will need to understand who their new customer base is quite carefully and market around that if they are to stay relevant. Sadly their products to me are garbage now; slow service, cold fries, awful oil. Obviously they've had to adapt but it's just expensive slop.
And in the UK they have had scandals around sexual harassment, which hasn't helped their image/branding.
Who cares? I mean, obviously this author, but pointing out "GDPR this" and "GDPR that" isn't going to make a difference or move the needle. Many companies have given up on GDPR - I've made requests and had blanket refusals to provide data.
Report them, you say? Many DPC's such as the Irish DPC are very friendly in terms of their lax approach to the regulation, just ask Max Schrems, he's been at this for years. I think the EU and the regulators do not have resources to enforce the law, so whilst there are requirements to protect customer data, nothing bad happens if you don't. Just check the top of HN as I write this [1] "Checkout.com hacked, refuses ransom payment, donates to security labs". Will anyone be arrested, charged, fined, or otherwise penalized? Nope, not a chance. I 100% guarantee absolutely nothing will happen as a result of this article. GPT makes it so easy to capture user data these days and people will just willingly hand it over.
The truth is, you should be very careful what data you hand out, always. Use an alias, use privacy tools, always be weary and check if they have a privacy policy, check to see if it works (make a dummy account, do GDPR request, if no reply, be weary).
If they are not serious about privacy, stop, think and act accordingly. While it is a disgrace what these individuals have done, individuals need to take personal responsibility just as in a real world, would you trust a random stranger giving you pills? Hopefully not!
If you're wondering for a possible reason and whether google is just being "lazy", see [1].
Tl;Dr: google has certain commitments they need to make depending on when the source code is released. Expect more delays moving forward thanks to this law.
And what does 'released' mean in this context? GrapheneOS has very publicly stated that security patches are under embargo, and they already have patches for the March 2026 release. See [1]:
> 2025110800: All of the Android 16 security patches from the current December 2025, January 2026, February 2026 and March 2026 Android Security Bulletins are included in the 2025110801 security preview release. List of additional fixed CVEs:
So, have they been released? No. So the clock hasn't started ticking yet. This EU law made security worse for everyone as patches that are done today are not released for 4+ months.
Note: These are CLOSED source blobs GrapheneOS is shipping. If they were open source, the 4 months clock would trigger immediately but they are not allowed to do this themselves as they get the patches from an OEM partner. GrapheneOS shipping these CLOSED source blobs, that Google has NOT released does not trigger the timer.
I do accept that QPR1 was 'released' by Google on Pixel months ago, and therefore the timer started, however, Google will likely pick and chose what is best for OS updates/security patches. It explains why AOSP is now private/closed source and embargos are being used to get around the laws requirements.
> (c) security updates or corrective updates mentioned under point (a) need to be available to the user at the latest 4 months after the public release of the source code of an update of the underlying operating system or, if the source code is not publicly released, after an update of the same operating system is released by the operating system provider or on any other product of the same brand;
> (d) functionality updates mentioned under point (a) need to be available to the user at the latest 6 months after the public release of the source code of an update of the underlying operating system or, if the source code is not publicly released, after an update of the same operating system is released by the operating system provider or on any other product of the same brand;
Doesn't the embargo concern the source code of the patches (and detailed information about the CVEs), not the release of the patched binaries?
Either way, I don't understand what point you're trying to make. Even after reading your other comments here in this subtree, I don't see anything in the regulation you linked that would have delayed the source code release of Android 16 QPR1, given that the QPR1 binaries had already been released.
It's a rather intriguing concept, because it can be the case that the binaries Google released in QPR1 and their source code are different in some way. OEMs must ship QPR1 as Google released publicly within 6 months.
If this open-source release was to contain new patches, they must now ship these changes within 6 months. The Pixel OS release counts as the first 6 month timer. The source code release, by definition, now counts as the 2nd timer.
I expect the closed source binaries and public source code to be the same, but that may not always be the case. So OEMs are expected to at least in 6 months ship an update with the open-source code.
I would argue QPR updates are functionality and subject to the 6 month test.
I would also argue a closed source release in August 2025 would start the first 6 month timer (February 2026) and the source code release to trigger another timer (if they differed in any way between the closed source release).
A lot of this law is abstract and only if the EU challenges Google's approach would it be decided how it's meant to be applied in reality.
I believe QPR includes security fixes as well, which should trigger the 4 month timer
Your comment seemed to imply that a source release would trigger a different timer than a binary release, which is explicitly covered as the same thing in the law - for both the 4 and 6 month timers.
It reads to me like the opposite. Another case of manufacturers being unable to release updates in a prompt manner. Google delaying the release gives them more time to update.
What? Please explain what commitments exactly are causing Google to not release source code at the same time as the update. Until you do that, your statement is as valuable as writing 'Thanks, Obama!'
> (c) security updates or corrective updates mentioned under point (a) need to be available to the user at the latest 4 months after the public release of the source code of an update of the underlying operating system or, if the source code is not publicly released, after an update of the same operating system is released by the operating system provider or on any other product of the same brand;
> (d) functionality updates mentioned under point (a) need to be available to the user at the latest 6 months after the public release of the source code of an update of the underlying operating system or, if the source code is not publicly released, after an update of the same operating system is released by the operating system provider or on any other product of the same brand;
So if Google releases an update for Pixel, the 'clock' starts ticking from that date, otherwise, it goes by when the source code is released. Google can pick and choose what works best for them and their partners according to these rules.
Hence why delaying the source code may be preferable. This is why security patches are being delayed as per GrapheneOS (under embargo)
For example: Google releases Android 20, under embargo to all OEMS, this is not released on Pixel, is entirely closed source (hence why AOSP is now private) and therefore doesn't trigger the law. Android 20 could be ready for months, but until it's released on Pixel or open source, those clauses are not triggered. This is already happening to security patches, see my comment above.
So EU mandates that security updates in either source OR binary form must hit all users in at most 4 months after they are first published, therefore Google started delaying releasing source code and will start delaying it even more?
A more correct expectation would be that now Google will start delaying all security updates (both binary and source) until all their important downstream vendors are able to release in time.
Even that is doubtful, as Google would have to take the reputational damage for an ongoing exploitation of a security issue.
The functional updates though might get slowed down.
See my comment [1]. This is already happening with security patches and GrapheneOS has already commented on their socials about the situation.
It's quite bad as security patches used to take around a month, now it's around 4 months and the patches are being leaked to threat actors who can exploit the bugs until the patches are released.
Example: A patch is fixed on September 1st, released under embargo/closed source to all OEMs. Pixel issues the patch in December 1st publicly (either source code/software update), they now have until April 1st (4 months) to release it according to the law. So the patch is 7 months old before it has to be released according to the law.
All the march 2026 updates are done, now, today, and ready/waiting, but they are not released by Pixel/open source. Once that happens the timer will begin.
Stop blaming the EU. They didn't make security worse. It's Google and the other manufacturers who decided to respond to this law by using a loophole that made security far worse.
Before the EU law, Android would release monthly bulletins, and patches would take about a month before being released on Pixel devices, once known as 'best in class' security. GrapheneOS have themselves admitted this has changed from 1 month to 4. This has been done to comply with this new EU law.
Now, we have patches already for March 2026 in November 2025. Once the March 2025 patches are shipped by Google, OEMs have 4 months for all OEMs to ship it (deadline being July 2026).
Consider this scenario:
Patch for bug lands January 2026. Google decides to either release a Pixel OS update or release the source code in 8 months time containing this patch for whatever reason. Then a 4 month timer starts for all OEMs to ship that patch. Meaning a patch that has existed from January 2026 can now be shipped by January 2027 under this system and fully comply with the law. This patch may be under active exploit as OEMs have leaked it which again, GrapheneOS have admitted is happening.
Previously, patches would be landing within the month. All google must do is ensure this patch is not included in any pixel OS update or public source code release.
Yes, Google is responsible, but when the EU touts laws as fining 4% of global turnover (in the case of GDPR), then they are going to be taken seriously, which means OEMs demanding Google not release the update for Pixel/source code until they are ready and use this loophole as they are doing.
The loser is ultimately the end user who has a weaker more exploitable device for months.
I don't get it. Why not release it now and start the timer now? Shitty OEMs would get in trouble (not Google) and that would be a fantastic outcome. Am I missing something?
Because shitty OEMs pay Google a lot of money to put Google Mobile Services on their shitty phones and it’s bad to piss off your customers (note: you are not a Google customer if you use Android).
it has an integrated touch screen display with a viewable diagonal size of 10,16 centimetres (or 4,0 inches) or more, but less than 17,78 centimetres (or 7,0 inches);
I wonder if 3.99 inch and 7.01 inch smartphones will start appearing again.
> where the device has a foldable display or has more than one display, at least one of the displays falls into the size range in either opened or closed mode.
also this: does this mean that foldable phones with three 3.99" screens are excluded
This has absolutely nothing to do with that law, and even Google doesn't dare use it as an excuse for its behavior (as they did with GDPR by deliberately creating user friction that the European regulation did not require, and even partially forbids).
In reality, it's a purely political decision to curb the development of third-party ROMs, because the AOSP source code exists with all the merges and is distributed to vendors (like Samsung). However, it's not necessarily just to target GrapheneOS and LineageOS; it might also be to target the Chinese market, particularly Huawei, which uses this source code for HarmonyOS.
It absolutely has everything to do with this new law. For the first time, depending on when Google releases source code, or releases a Pixel update, the timer (4 months for security, 6 months functionality) starts. This has never existed before in Android OS' history that updates are timed (in law) according to Pixel updates/software updates or open source releases. This law also applies to Apple but they will have no problems as they are compliant anyway as they control software/hardware entirely and it's closed source.
This is the entire reason AOSP went private/closed source, and why Google is delaying security patches as per GrapheneOS. The March 2026 patches are already released by GrapheneOS as closed source blobs. They are not allowed to release them as open source by embargo (essentially NDA). Why do you think Pixel hasn't shipped security patches earmarked for March 2026? There are some critical bugs those patches fix, why not release them today, right now or next month? Because if Pixel releases just a single patch, via a Pixel update or posts it on AOSP, the 4 month timer begins for every single OEM with a phone in the EU. By making the patches under embargo, Google gets to control exactly when the timer starts to coordinate with their OEMs. So the slowest OEM gets to control the entirety of Androids security model.
Ask yourself, why doesn't GrapheneOS just release their patches publicly/open source? Why have different 'security releases' with closed source blobs?
Because if they did:
1: They lose their partner OEM access to these patches
2: Every OEM would be required to release those same patches 4 months to the day GrapheneOS releases them.
> 2: Every OEM would be required to release those same patches 4 months to the day GrapheneOS releases them.
I don't think that's true since the regulation you linked says:
> (c) security updates or corrective updates mentioned under point (a) need to be available to the user at the latest 4 months after the public release of the source code of an update of the underlying operating system or, if the source code is not publicly released, after an update of the same operating system is released by the operating system provider or on any other product of the same brand;
(emphasis mine)
GrapheneOS is not the OS provider in this context, Google is.
> at the latest 4 months after the public release of the source code of an update of the underlying operating system
So if somebody reverse engineers the patch, or releases the patch under embargo (which the OEMs would have the source code) that would count as a 'public release'. So GrapheneOS can ship closed source patches as you are right, they are not the provider. If GrapheneOS released the source code they are getting from their OEM then it would count as a 'public release of the source code'.
A patch in itself can be considered an 'update of the underlying operating system' and therefore the moment it becomes public it needs to be patched by all OEMs within 4 months.
GrapheneOS have themselves said that if somebody did reverse engineer the closed source blobs and posted them publicly they could then ship the patches openly at that point but not until.
It must be stated a lot of the wording of this clause and interperetation of what is/is not considered 'publicly releasing source code' is up for debate/courts to settle.
> Because if Pixel releases just a single patch, via a Pixel update or posts it on AOSP, the 4 month timer begins for every single OEM with a phone in the EU.
And that's exactly what the law was about, this timer is a good thing. Now they should close the "artificial delay" loophole.
We really need to banish the term "sideloading". Installing apps on a terminal is just that, and for as long as I remember on windows, Linux it has always been just that.
Google mentions about being on a call, and being tricked into handing over codes. So why not use signals and huristics to decide?
If user is on a call, block any ability to install a shady app. Implement a cool down before that functionality is restored (say 24 hours). It can also detect where the user is based to add additional protection (such as mandating the use of play protect to scan the app before it's activated and add another cool down regardless).
There's lots of ways to help protect the user but it's wrong to ultimately control them. The real world is full of scary dangers that technology is trying to solve but is actively making things worse (such as computerized safety systems in cars).
Ultimately, the user is responsible and whilst it's palpable Google would want to reduce harm in this specific way, we know authoritarian governments would also love to be able to dictate what software people can run. The harm to democracy is simply too great in favor of saving a few people's money.
Games publishers/developers are going to have to wind in their necks a little. Whilst memory is abundant it's also still quite expensive. We should still be aiming for efficiency and the chances are 16gb+ are in the minority here. Fact is, the more VRAM and compute you demand the smaller your customer-base becomes.
I've played many games with 8GB VRAM* and will do so for the forseeable. If that's not enough, I am not a customer. Simple as.
The truth is, there is going to be a massive motivation with the likes of Steam Deck/Machine to actually make titles that are optimised and perform well within their hardware parameters. It's money you won't want to ignore.
*One example was Silent Hill remake on PC, which used the unreal engine. It was optimised beautifully and ran without visual glitches and stutters even with the highest graphic demands on a 8GB RTX
I think it does also help that a big chunk of Steams userbase are playing smaller indie titles that don't need obscene amounts of vram. The steam deck audience for example has a lot of people playing both a mix of AAA and smaller games. Given this is advertised as 6x as powerful as the deck I'm sure they'll be fine. It's not meant to be a top of the line console thats for sure, and if it was people would be moaning that its too expensive.
oh 100% I've completed CP, RD2, Fallout 4, and god knows how many other games, it handles it all like a champ. Valves clearly following their own hardware survey results on their hardware plans as the modest specs are better than what most people active on steam are using right now so I think it'll be fine
Memory is also not that abundant anymore. Over the last month PC memory costs have more than doubled due to AI datacenter builds buying out all the manufacturing capacity.
This. Absolutely this.
It is complete bonkers to suggest that game devs dictate consumer hardware, insane to run the asylum.
All game development should follow Nintendo model: there’s a fixed hardware and game devs should go out of their way to optimize to the spec, not consumer shelling out thousands every years because someone can’t be bothered to optimize their cashgrab.
A great example of this is the 'networking' permission. Being able to control which app can speak to the WAN/LAN is a very important security consideration. Instead, every Android app can send any data it wants without the user being able to have a say in the matter. A lot of apps work just fine without being able to 'phone home'.
Thankfully there's the likes of GrapheneOS, however, with Google's recent changes, unless their OEM partner pulls through, their days are likely numbered.
Interestingly, on Xiaomi HyperOS they have added the ability to individually control each app's access to mobile data 1/2/WiFi. I didn't know this wasn't a general Android feature.
I guess if it was, people would be turning off the network permission of all the "apps that perform a trivial function, but with ads", like I always do.
The only reason Google has decided to lock-down Android is because of apps like ICEblock and the ability for anonymous individuals to mass distribute information that governments do not like. Now, they'll be able to hunt you down by requesting Google hand over every ID document that they process. This sets a chilling precedent for free speech. It enables governments to go after those who dare 'speak out' by using platforms to their advantage. You can no longer 'hide in the shadows' and will need to put your entire identity on the line for your morals and convictions.
Of course, if they could do this with Windows, Linux et al they absolutely would. And general purpose computing will, eventually, be closed and locked down, much like what we are seeing with the internet and ID laws. People would have, and did, think such ideas would be unthinkable 10-15 years ago. Yet little-by-little the screws are being ever tightened. The government wishes to tightly control the information flow and decide what is 'best for you' to see. Preferably their chosen propaganda.
Work-arounds that exist today will likely be closed and forbidden in the future. VPNs to bypass age laws, ADB to bypass install-blocks will all be obsolete. You will be required to identify yourself at all times. I half-expect Google to deprecate and remove the concept of VPN's/ADB on Android entirely and laws will be passed to that affect (restricting the apps themselves, or access to the APIs to verified Android devices/Google accounts). If you don't believe me, you only need to see [1] for the direction of travel.
There is little interest from the regulators to stop this. Perhaps the useless CMA will 'investigate' in 5 years time, decide Google perhaps abused its monopoly and then do absolutely nothing because they have no real re-course over an American company. It's likely governments support this position and will not do anything to influence a change of direction.
Eventually, Linux itself will go the same way, people are just waiting for Torvalds to retire from the project to make their moves, but make no mistake, open general-purpose computing is under threat and there is going to be little we can do to reverse the current trends towards closely monitored and controlled computing.
This will most likely be expanded in the future to limit access to certain 'dangerous' APIs like ADB/VPN's etc. This can also be used 'in app' and across the entire OS to shape your experience of what you can see and do. I wouldn't be surprised if 'unlocking bootloader' required an 18+ verified device.
> The only reason Google has decided to lock-down Android is because of apps like ICEblock and the ability for anonymous individuals to mass distribute information that governments do not like.
Nah. The only reason Google has decided to lock-down Android is because they think they can get away with it. They would have done it from the first minute except that not doing it gave them a competitive advantage in the market over Apple - back when pretending to be into FOSS and to "not be evil" was a major part of their marketing. They're ready to make the move. If it fails, they'll try to make the move again a few years from now. They don't give a shit about ICE or whatever.
> The only reason Google has decided to lock-down Android is because of apps like ICEblock and the ability for anonymous individuals to mass distribute information that governments do not like.
That's why the solution CAN'T be more regulation ...
Again, I don’t really see Google as a ‘moral’ or ‘pro-user’ company since they just pushed out Manifest V3. But unlike ad blockers, they’re not losing millions from sideloaded apps, so the only reason for their sudden policy shift is probably government pressure. With all the ongoing antitrust lawsuits, they’re just trying to stay on the good side of whatever the current or next administration wants.
> Eventually, Linux itself will go the same way, people are just waiting for Torvalds to retire from the project to make their moves, but make no mistake, open general-purpose computing is under threat and there is going to be little we can do to reverse the current trends towards closely monitored and controlled computing.
Thankfully, we can take the last GPL commit of Linux and fork it.
seems well coordinated with the recent escalation of aggression around google accounts without a cell phone number attached “to help make sure you don’t lose access to your account.” complete horseshit, but they can get away with it.
Just reading the first correspondence from Ofcom and this section in particular:
> What should I do if there is confidential information in my
response?
> You must provide all the information requested, even if you consider that the information, or any
part of it, is confidential (for example, because of its commercial sensitivity).
> If you consider that any of the information you are required to provide is confidential, you should
clearly identify the relevant information and explain in writing your reasons for considering it
confidential (for example, the reasons why you consider disclosure of the information will seriously
and prejudicially affect the interests of your business, a third party or the private affairs of an
individual. You may find it helpful to do this in a separate document marked ‘confidential
information’
> Ofcom will take into account any claims that information should be considered confidential.
However, it is for Ofcom to decide what is or is not confidential, taking into account any relevant
common law and statutory definitions. We do not accept unjustified or unsubstantiated claims of
confidentiality. Blanket claims of confidentiality covering entire documents or types of information
are also unhelpful and will rarely be accepted. For example, we would expect stakeholders to consider whether the fact of the document’s existence or particular elements of the document (e.g. its title or metadata such as to/from/date/subject or other specific content) are not confidential. You should therefore identify specific words, numbers, phrases or pieces of information you consider to be confidential. You may also find it helpful to categorise your explanations as Category A, Category B etc
> Any confidential information provided to Ofcom is subject to restrictions on its further disclosure
under the common law of confidence. In many cases, information provided to Ofcom is also subject
to statutory restrictions relating to the disclosure of that information (regardless of whether that
information is confidential information). For this reason, we do not generally consider it necessary to
sign non-disclosure agreements. Our general approach to the disclosure of information is set out
below.
> For the avoidance of doubt, you are not required to provide information that is legally privileged and
you can redact specific parts of documents that are legally privileged. However, where you withhold
information on the basis that it is privileged you should provide Ofcom with a summary of the nature
of the information and an explanation of why you consider it to be privileged. Please note that just
because an email is sent to or from a legal adviser does not mean it is necessarily a legally privileged
communication. Further information is available in paragraph 3.18 of our Online Safety Information
Powers Guidance.
So ofcom's position is:
We want your data, you will give us your data, the GDPR does not apply to you, and if it does, we will decide whether it does. You must explain yourself to us. You must not redact anything. Even if you think you can redact anything (you know, because GDPR) you cannot redact anything. The GDPR and data protection laws do not apply because we have said so. You are required to break confidentiality agreements. We will not sign an NDA because we do not need to and we will not justify ourselves to you in any way shape or form.
We are the UK, and therefore, because we asked you to, you will comply with our every demand, whim and whimper. Otherwise we will continue to send strongly worded emails.
And fine you. And block you. Because that's the only thing we can do. And you best not advertise VPN's or we'll...Send another sternly worded email!
Good job UK!
(I cannot see how that paragraph is in any way legal, it must break the EU/UK's data protection laws in trying to compel disclosure of third party data. I cannot see any court in the UK ever upholding that paragraph if legally challenged as it's way above Ofcom's remit to be demanding confidential data. In any case, they should absolutely be required to sign NDA's)
What part of that process needs to change every 2-3 years? Because some 'angel investor' says we need growth which means pushing updates to make it appear like you're doing something?
old.reddit has worked the same for the last 10 years now, new.reddit is absolutely awful. That's what 2-3 years of 'change' gets you.
In fact, this website itself remains largely the same. Why change for the sake of it?