aboringusername

Is there anyone who actually cares about any of this?

Look at flightradar. Look at Marinetracker. Look how many cars are used every day and the billions of barrels of oil we're consuming.

We are not going to consume less oil, unless there's some manufactured event that stops us (like COVID), or we physically run out.

People are addicted to moving about, making things, entire economies rely on it.

And nobody here would sacrifice opportunity for a future that may not even happen. Even if you're the most conscious consumer, the world's going to heat up anyway. You not driving a gas car, or not eating meat, won't make any difference because somebody else will be there to consume what you leave behind.

And I plan to use as much oil as possible, take as many planes and cruises as I can, eat as much meat, because I frankly care less and I'm not going to miss out if I have the choice. I know I am not alone in this thinking and many, many others also no longer care, not that they ever did.

But you're more than welcome to leave the resources to others who will gladly use them.

From what I see [1] if you search for 'undue delay', it's only:

> an early warning notification of an actively exploited vulnerability, without undue delay and in any event within 24 hours of the manufacturer becoming aware of it

> without undue delay and in any event within 72 hours of the manufacturer becoming aware of the actively

> without undue delay and in any event within 24 hours of the manufacturer becoming aware of it

> without undue delay and in any event within 72 hours of the manufacturer becoming aware of the incident

"Sorry your honour, we only became 'aware of it' 2 years later, pinky promise ;)".

So any competant authority would have to prove when they 'became aware of it', whatever the test to pass that threshold means.

[1]: https://eur-lex.europa.eu/eli/reg/2024/2847/oj/eng

I posted about this 11 months ago [1]. The law you are referring to [2] absolutely makes distinctions between open/closed source. This is 100% why Google closed their source and now does security releases privately.

[1]: https://news.ycombinator.com/item?id=45911673

[2]: https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=OJ%3AJOL...

> Clause 1.2:

> (6) Operating system updates:

> (a)

> from the date of end of placement on the market to at least 5 years after that date, manufacturers, importers or authorised representatives shall, if they provide security updates, corrective updates or functionality updates to an operating system, make such updates available at no cost for all units of a product model with the same operating system;

> (b)

> the requirement referred to in point (a) shall apply both to operating system updates offered voluntarily by manufacturers, importers or authorised representatives and to operating system updates provided to comply with Union law;

> (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;

> (e) an operating system update may combine security, corrective and functionality updates.

Pixels running GrapheneOS sure, but stock Pixels lag months behind patches that exist but not yet shipped. Check any bulletin and it links to git commits to months ago.

It's concerning to hear about the disarray within the internal workings of Android, they've spoken quite a lot about this recently such as getting access to the code and having to make manual requests.

I'm curious if there's any back up plan to an operating system used by billions. One would think, and hope, the EU would have an alternative ready to go at a moment's notice. Android is literally too big to fail, but I doubt the EU would be ready even though you could consider the failing of Android a national security emergency.

I would like to know more about what's going on at Google that are causing these issues.

This is the biggest disappointment, imagine running a full blown "Ubuntu Touch" that gives you the freedom of Linux with full root access. This is the biggest failure of legislation in the 21st century so far that has enabled a strict Android/iOS duopoly.

I sincerely hope one day we can free these hardware devices from the shakles of their software and run anything that's possible.

Until such a time iOS devices are strictly off limits until at least a grapheneOS can run iOS at a minimum.

For future readers: This is NOT a direct comparison. The Motorola linked is sold/shipped by a third party (KICKmobiles® London (Worldwide FedEx/DHL Shipping)). The Pixel, whilst a higher cost (£879 vs £795 for the motorola) is sold and shipped by Amazon directly.

And this distinction matters. You are able to hold Amazon to account for when/if things go wrong (CRA2015,S75,courts,etc). With the Signature, it's an import, consumers have vastly fewer rights, and there are no reviews of the product either (can you guess why?)

As Amazon is not directly selling the product (Amazon only facilitates the transaction but isn't the actual buyer or seller), enforcing any rights is going to be extremely difficult, if not impossible.

It's sad to see that point not acknowledged as it makes the Pixel vastly more attractive.

There is a more direct comparison on their own website which is £1,199.99 which is £320 more expensive than the Pixel. Your comparison is disingenuous and should be retracted in full as blatantly misleading.

[1]:https://www.motorola.com/gb/en/p/phones/motorola-signature/s...

One detail that remains to be seen is whether you'll cater to the EU market, and how the impact of the memory crisis will impact the possible consumer-base. It's a weak market and sales are likely to be only the 'hardcore' users who demand/require security. I sincerely hope there are no numbers you need to hit to keep the partnership going. Sales are not likely to be at first significant, people are extremely price sensitive and I'm not sure GrapheneOS support will draw people in enough to justify the obviously now inflated costs to cover component price increases (and tariffs).

Pixels offer affordable options which is why unless you can cater to that market, a Motorola-only GrapheneOS future will only gain traction if you're able to get a cheaper low/mid-range option out there, akin to the Pixel A-series.

It's obvious they see open access to users data as a threat to their business model. No, they haven't suddenly decided to care about your privacy, they want to deny other actors access so you need to get data directly via them. They will obviously still collect it themselves via their numerous methods (play services, chrome, ad networks etc).

It's funny how much Google lies about Android being 'secure' [1] and how much GrapheneOS, for free, improves the security of everyone with their work. Google should be, immediately, merging all patches/changes GrapheneOS makes and releasing a new build of Android to AOSP. Instead, users are subject to weak efforts to protect their security and privacy while Google parade about how good and amazing they are. They mention [1] 'This unencrypted data can be used to build user profiles or, in the hands of malicious actors'...And can't see the irony. They ARE the malicious actor and they absolutely build profiles about everyone. Whatever happened to the 'privacy sandbox' initiative again?

Anyone who values Graphene's work will purchase one of their Motorola devices, whatever the cost, otherwise it seems your choices are going to be giving up more data and control to Google, because they are clearly, obviously and systematically trying to remove GOS from Pixels (lack of source code, removing hardware features, making it purposely difficult to support pixels).

I predict by 2030 GrapheneOS will not support any new pixels entirely. The existing pixels will eventually die off and that will be that.

[1]: https://blog.google/security/new-android-network-security-pr...

Well, it depends on the application and context. I don't think a homeless person at the library is going to be booking a $1000-a-night room in downtown Los Angeles.

However, services that homeless people will be using should factor in their target audience (such as the homeless not having a phone at all, or maybe not one that's up to date even).

However, like it or not, having a modern up to date device is becoming essential for even rudimentary basic access to society. Whether that's right or wrong it's where we are.

Go fuck yourself?

I mean, that seems to be the general societal attitude.

And you'll need to buy new ones because many things are app only, or are migrating that way (including being able to travel to certain countries)

I suppose it's now become a default assumption every customer is going to own a smart phone that complies with this requirement?

It seems on iOS you'll even need to download an application, which is quite a bit of friction.

In the current economic times, adding minutes onto the user journey is not going to result in increased sales, I suspect the data will prove the opposite.

Using a mobile device is bad enough as it is: TOTP, email, SMS codes, 3DS etc, while you can say this is part of the "flow", it's too much. I can see many abandoned journeys from this.

I don't actually see this as a problem, and instead it's a PSA everyone needs to internalize:

If you put data onto a networked device it may be sent to some place else.

If you don't want your data being shared:

Use a device that does not have any networking capability (both hardware and software wise)

Use a pen and paper, you can shred and destroy as you see fit.

If you're using an application on a mobile device with mobile data/wifi, the chances are, your data is being uploaded.

The reauthenticate means using device pin/biometrics if you have them enabled.

You will not need a Google account.

It's not like the Google Play store hasn't been known to host malicious apps, yet you are not required to wait 24 hours before you install apps from their store.

I suspect they are hoping users just give up and go to the play store instead. Google touts about "Play Protect" which scans all apps on the device, even those from unknown sources so these measures can barely be justified.

Imagine if Microsoft said you need to wait 24 hours before installing a program not from their store, which is against the entire premise of windows.

Computing, I once believed was based on an open idea that people made software and you could install it freely, yes there are bad actors, but that's why we had antivirus and other protection methods, now we're inch by inch losing those freedoms. iOS wants you to enter your date of birth now.

The future feels very uncertain, but we need to protect the little freedoms we have left, once they're gone, they're gone for good.

Unfortunately that's a rather vanishingly small list now.

I would not be surprised if, in a few years, these options are gone from all android devices.

People mention GrapheneOS but that relies entirely on Google.

Yes they are working with an OEM (leaked as Motorola) and we'll see how that goes, it may be the last hope.

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?

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.

Can see why people have moved on.

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.

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.

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.

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.

You're not reading the interpretation correctly:

> 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.

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.

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.

This EU law has made security far worse.

[1]: https://news.ycombinator.com/item?id=45914692

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.

[1]: https://grapheneos.org/releases#2025110800

From the EU law:

> (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;

> (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.

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!

[1]: https://news.ycombinator.com/item?id=45912698

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.

[1]: https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=OJ%3AJOL...