YHK - yet another hacker news clone

Google does have a card to play here, I don't disagree but they shouldn't overstate their hand either. The Google bits of Android are good enough to keep open-source ROMs and small manufacturers away but they aren't a silver bullet and won't save them if China stops playing the game.

Termux has to work around security restrictions in a way not dissimilar to how you would need to work around an extremely securely configured SELinux setup on RHEL.

I look forward to "Linux users and/or developers benefit from Android but..."

They are mostly relying on LineageOS now and putting their own cloud, microG, and App Store app and branding on top of Lineage. Even now they are not able to roll out Android releases and WebView updates timely. Them maintaining an AOSP fork would probably end up in an outdated, broken mess.

My money is on GrapheneOS and maybe LineageOS to do it when needed.

Why does that matter? Even if it was released 20 years ago, why the hell should Apple (or any company for that matter) dictate if a developer can make an app for an old device or that a user wishes to use that app!? With Android, the developer doesn't need to depend on the "App Store", or even care about it, to distribute their app - any Android user can directly download and install the app through other means on their old or "outdated" device.

Because you still get money?

Nothing about getting copied means you don't still get money. It probably just means your legal team has some people to annoy into going away if you're a big company.

IMHO it's the best outcome.

At this point I'm willing to argue that the owner of a device is whoever is legally allowed to log in as root. When I pay for server colocation, I'm the owner - and not whoever runs the building - because I decide what runs on the box, and if they tamper with it they can go to jail.

With phones it's the same, except that you pay Google for the privilege for keeping their device safe, charged, connected to the Internet, and walking it around every day with you, so they can collect better data. The only thing they can't do is snatch it from your hands, but why would they - you're doing so much useful work for them.

And of course if you try to root it, you're breaking a digital lock, which is punishable by up to 10 years in prison and $1,000,000, so the colocation analogy holds there too.

iOS being so difficult to jailbreak means that most apps don't have any verification at all. Even most DRM doesn't even try to verify that the device isn't jailbroken in order to access the highest resolutions or whatever. But if we ever add a first-party option for the device to be modified, then we start running into the Android situation where every app has some invasive root/tamper detection thing. Some apps already have anti-debugging things, but the situation on iOS could be far, far worse.

Maybe the misunderstanding stems from the related common misuse of "as soon as possible" as "immediately"?

A corporate lawyer would, however, always suggest to minimize/reduce/delay any legal obligations so as to minimize risk of liability, regardless of whether said obligation is easy to comply with or not.

Security flaws are discovered almost every day (now that they are automating it with AI there are a ton of reports), pretending the manufacturer releases an update in 1 day is nonsense.

Just building the code alone it would take a lot of time, and of course you have to test it at least a bit before giving it out to the end users, you can't pretend to rollout on a global scale a nightly build without first at least some level of QA risking bricking user devices.

And you have to consider that phone manufacturer doesn't work h24 and 7/7 of course to give out patches.

I think that we are fortunate if the whole process takes less than a month, not a day.

> The CRA requires manufacturers to notify actively exploited vulnerabilities and severe incidents having an impact on the security of their product with digital elements. They need to submit an early warning within 24 hours of becoming aware, and a full notification within 72 hours.

These deadlines are entirely unrelated to the availability of security fixes and delays in deliverying them.

The part that’s probably bothering Google is this:

> 6. Manufacturers shall, upon identifying a vulnerability in a component, including in an open source-component, which is integrated in the product with digital elements report the vulnerability to the person or entity manufacturing or maintaining the component, and address and remediate the vulnerability in accordance with the vulnerability handling requirements set out in Part II of Annex I. Where manufacturers have developed a software or hardware modification to address the vulnerability in that component, they shall share the relevant code or documentation with the person or entity manufacturing or maintaining the component, where appropriate in a machine-readable format.

To put it very simply, the CRA calls on all stakeholders to cooperate in reporting incidents and vulnerabilities, establishes a national coordination mechanism, and aims to address vulnerabilities swiftly in order to maintain essential services within the European Union.

Then there is no time limit to provide a mitigation. It should just be worked out without unnecessary delays. Once a mitigation is published, a report should be submitted with 14 days.

But many Android OEMs are probably terrible at software engineering and have their attention spread across multiple SoCs, etc. It’s their own fault.

Graphene isn't OEM so they don't get access to Android repository before AOSP drops. OEMs - like Motorola for example - do have access to partner repository and can ship QPRs if they wish to do so. Most often OEMs do not want to push updates (and it took years to make them push regular major Android updates).

> I think they know what they are taking about.

Err, if you look at that account you'll find that the person running it has a penchant for overexaggeration and selective truth telling when they feel aggrieved.

When your system favors people into power that abuse that position instead of furthering the public interest, that provides a feedback signal leading to ever worse people and outcomes.

There is no need for a "conspiracy" to get to a point where it looks like one.

It mandated USB for charging everywhere, but didn't do a thing about driving on the right side of the road.

We have the digital markets act, yet when someone tries to send emails to some big American email providers, they have to register first, otherwise they don't even make it to the spam folder. But hey, let's have a big round of applause for fining X/Elon Musk and Meta because we hate them. Who cares about decades old protocols and ways of doing things?

They care about their partners and about following the law. Google is not being spiteful here like some commenters are saying; instead, they have changed the way they work to make it compatible with a new law that applies to them.

It’s tiresome to see the same kind of snarky comments in every thread because they are not interesting at all. They are just lazy, and begging for votes.

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

https://eur-lex.europa.eu/eli/reg/2023/1670/oj/eng#anx_II

So by delaying AOSP releases by 4 months, Google is allowing OEMs to leave their users exposed to known vulnerabilities for up to 8 months.