I can't prove it, but I still think this is (partly) due to a recent EU regulation majorly backfiring.
I can't remember which one it was, but one of the recent regulations mandates that devices get updates for a certain period. Within that period a manufacturer must provide each update for all their devices in a short timeframe. The intention was to prevent flagships getting updates immediately and lower end devices having to wait months.
However, due to some (also well intentioned) wording about open source, the release of the source code is counted as the first release of an update and starts the timer.
I'm pretty sure Google is delaying public AOSP updates to give their partners (mainly Samsung I suppose) more time to finish building their updates on top of AOSP.
I wouldn't be surprised if large corporations like Apple and Google intentionally use these tactics to pressure regulators through their European users. Siri AI is a prime example. While it's a complicated issue, I certainly wouldn't put such maneuvers past them.
It's funny that they keep trying, it has never once worked. I think US companies are projecting their dislike for regulation and keep being surprised that EU citizens don't agree. We do not love the EU government, but it sometimes does a good thing and we do like these, especially versus the anti-consumer crap that US companies like to pull.
we do not love the EU government because there are billions being poured into promoting the discourse that the EU is a bad thing by both private and state actors.
My problem is the lack of democracy through the too-indirect way that the commission is elected. Von der Leyen was an extremely unpopular and horribly incompetent (at least in charge of defense) minister in Germany, then somehow she became president of the EU commission. Her skill seems to be politicking with other politicians. That would not have gotten her elected in an election by the people.
Right now, "EU washing" unpopular policies is a thing. National (usually corporate) interests can make EU laws happen, and when they have, national politicians say "Sorry, our hands are tied - EU law!". So I'm not at all optimistic that the EU political organization, of all things, will reduce corruption just by getting more power. But I do think that more direct elections to powerful EU positions will improve things.
Sometimes its a good thing that people do not elect directly. They participate indirectly though. And there are general rules to follow. So its more stable framework than full public control each election cycle, because the populism happens and if you want to be elected you cant take unpopular decisions which sometimes are needed.
There are unpopular decisions that are actually good, and those that are simply bad for the population but good for people closer to power. I think the latter are more common in basically any system with too little public oversight.
Indirect democracy is not really a lack of democracy. But I dislike the way it works now as well and would like for EU elections to be more direct. I'd also like to be able to vote for candidates from other member states.
However changes like these are deeply unpopular as they get interpreted as moving more powers to "Brussels" by right wing media.
Because the European Union has come up with shitty laws and regulations.
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?
Blame the shitty tech companies, the DMA and similar attempts in the USA and many other countries stem from them stacking everything in their favour at the cost of everyone else's money, privacy, security and safety.
It's not like regulators were just bored and felt like fucking shit up, there is a nearly-global consensus these companies are exploiting consumers and markets.
Except that DMA didn't do anything for more fundamental problems like the email problem.
No, they just want to have something to brag about or think they know better (Soviet/communist style). Like, we're lazy and tired of having to carry our proprietary iPhone chargers, we know you're too, let's make USB mandatory.
Don't believe the chargers are a good example. There definitely must be some good ones. But Apple is being anti non-apple consumers (and often anti apple consumers, vide ridiculously expensive monitor stand) for a long time, doing everything to make sure nothing non apple can work well with apple products and vice versa.
I can (actually can't, but for the sake of argument let's pretend) imagine why my wife's Air Pods Pro 3 can't supply heart rate data to my phone for exercising. But why can't they report battery level? ffs
Even if Lightning is better in some aspects (USB-C tongues break sometimes), forcing people to have special cables just for apple devices, when every single thing runs on USB-C, feels like done out of spite. And then? Apple devices don't support any fast charging standard. Spite again.
It's hard to see it differently, but there might be better reasons and arguments that I can't or choose not to see. Probably because I don't love the company that forced poor parents to buy their kids expensive phones just so the kids wouldn't get ostracized for not having green or blue bubble in text messages.
If I don't like the product because of its charging mechanism, not reporting battery level etc, I don't buy it.
> USB-C tongues break sometimes
Unlike barrel chargers which are also simpler. No need for fancy electronics and protocols. Let's not forget non-compliant USB chargers. I remember reading about a Chinese mini-PC manufacturer that sold a computer with a charger which provided 19V or so from the start without any negotiation. Hopefully no one tried to use it with another device.
>Let's not forget non-compliant USB chargers. I remember reading about a Chinese mini-PC manufacturer that sold a computer with a charger which provided 19V or so from the start without any negotiation. Hopefully no one tried to use it with another device.
I actually (or somebody close, friend or family, can't recall) did exactly that. It was a few years ago and I don't remember what got fried. Some small electronics. It was a barrel charger and it fit. Too bad that fitting didn't mean the power levels were ok too.
> I don't like the product because of its charging mechanism, not reporting battery level etc, I don't buy it.
Why shouldn't my wife get headphones because a company is a dick and makes them not work with her husband's phone properly? Looks like a dismissive argument trying to excuse malicious business practices. (I'm not in or from US, maybe that's normal and OK there, so sorry for ranting about it, as it might be fine or even good for you if you're invested in Apple). Anyway, why not buy them, headphones work very well for my wife. Other than price not being adjusted to product performance and quality, AirPods Pro 3 are a very good product. HR reporting is a cool feature. And I don't have bud-type earphones, so I borrow hers for exercising.
Back to "don't buy it if you don't like it" argument: it doesn't argument against apple being dicks for making the product purposefully not work with an Android phone. And if it does, please explain it more clearly, I believe I'm not the only one holding the point of view that it just doesn't exonerate them.
As I see it, it's malicious compliance, as there's no laws YET forbidding what they're doing. (Somebody recently RE'd AirPods BT protocol/calls IIRC and found them reporting battery on non standard ?variable name?. He then got Android phone to show battery level after a small modification.
For comparison, I would bet a beer (I see betting more as gambling) that if Samsung created headphones with HR monitor, I would still be able to see battery level and HR in my Oura app on my OnePlus. And vice versa for 1+ headphones on Samsung. Do you see my point?
And for the record, apple has recently released many phones, both low and high end, that weren't overpriced. And I vehemently oppose anyone whom I'll have to tech support later, getting any phone different than apple - for a non technical user these phones are perfect. Good default's. Non customizable - perfect from point of view of tech support. Just works. Just to show that I'm anti anti consumer conduct, not anti apple.
I bet most people have not read any laws in past year. hell, some have not read any laws in their lives. And no i don't agree that i want fewer laws. By the way, how many laws is enough for you?
Most people don't read any law their entire lifetime and hope for the best.
But are you willing to risk it, if you're trying to do something? It does not even have to be complicated, it can be something as simple as having a website.
Suddenly you have to deal with GDPR and it's not an easy task, otherwise we wouldn't have so many discussions and consultants, not to mention the fact that some websites prefer to just block European users.
The PDF for GDPR has 88 pages [1]. And it's just one thing. The AI act has another 144 pages [2]. Who's gonna read them?
We have civil code for everyday life, do you think people read that? I bet no, but anyway it describes rules by which people live. And when there is disagreement we open a book and see whos right. Do you think we should not have such rule book?
> fining X/Elon Musk and Meta because we hate them.
They were fined because they broke the law. Many consider these fines, a slap on the wrist. Personally I support much harsher and detrimental punishments in such cases.
You misunderstood me. I wasn't saying they didn't break the law, I honestly have no idea if they did. I was only saying that some people like the law because it makes people/companies which they hate (possibly for valid reasons) suffer. In other words they like only the sentence.
I don't think this is any corporate conspiracy. The truth is probably more mundane: regulation is treated as obstacle to navigate around with minimal amount of effort, and not a reason to give up on practices that makes money.
A system that leads to bad outcomes is a bad system.
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's funny that they keep trying, it has never once worked.
Sure it has. Consider cookie banners: widespread malicious faux-compliance from the start, and approximately nothing was done about it for most of a decade, while people were tricked into believing they were GDPR’s fault. Even now when a little has been done about it, the significant majority of cookie banners are very obviously not compliant with GDPR or ePD requirements, and no consequences occur.
Giving their partners the time they need to finalise their releases legally seems like a... completely normal and correct thing to do? Why does everything have to be a big conspiracy?
No, not in an open-source project. Nor is it correct to build the project under the guise of open source and then pull the rug from underneath. Or any of the other anti-competitive, anti-consumer, anti-security crap they've been doing lately.
Correct? I suppose that depends on your definition. From a corporate perspective, perhaps. But from a consumer's perspective it's most certainly not the desired outcome.
They don’t have agreements with graphene so what do they care? Google owes graphene absolutely nothing.
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.
They're skirting the law and they're likely to be breaking it too - if not on cybersecurity grounds then almost certainly on anti-competitive grounds.
Even if we set legality of their behavior aside, they deserve scorn for how they've been managing Android for the past couple of years - every Android user is worse off because of them. They broke off productive relationships with grapheneos and other projects which contributed patches and reported vulnerabilities upstream, they're engaging in anti-competitive conduct and imposing limits on OEMs, giving Pixel devices preferential access to new APIs.
They're simultaneously putting their own customers (Pixel owners) at risk of known, exploitable security vulnerabilities. They do this to help other OEMs legally skirt (maybe) the 4 month timeframe for patches which is very lax to begin with. Thereby opening a whopping 8 month window where Android users can get hacked by known vulnerabilities.
How cynical do you have to be to defend their stewardship of AOSP?
> 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
Read the second link I posted above, this is patently false.
There should be a rule that any assertion of conspiracy must at least have some evidence.
I worked at MS and was involved in several decisions to not ship in the EU because it just wasn’t worth the internal and external regulatory headache. There was no secret agenda, Satya never told me to stick it to the EU by withholding a feature in the hopes the masses would clamor for it and demand regulatory changes, which would eventually allow us to… ship the feature in a decade or so.
I’m super sympathetic to the EU’s intent, but their execution is so obviously self-defeating that it doesn’t take elaborate conspiracies to explain corporate response.
> but their execution is so obviously self-defeating
Well no. It’s not self defeating. It’s being defeated because these are US tech companies, protected by US monopoly power, and the fact that US lawmakers are captured by lobbyists and are incapable of passing similar laws to protect their constituents. Big difference.
> There should be a rule that any assertion of conspiracy must at least have some evidence.
Broadly, I agree, and good grief do I wish people would follow this more often. But Google specifically has acted incredibly anti-competitively for several years now [0], especially regarding Android. This has gone on for such a long time that they have, in my mind, lost the benefit of any doubt.
As they continue to lock down Android [1], things that would have once been met with a "Wait and see" approach are instead met with suspicion and a default assumption that it's primarily (though not typically exclusively) done to serve their own interests.
So generally, yes! That which is asserted without evidence can be dismissed without evidence. However, Google's history is all the evidence I need to assume their actions are not done in good faith.
Whether it's "right" depends on the goal of course, but in this case I'm not understanding your point because nobody is prosecuting those companies for doing this.
In any case, these kinds of blanket statements are not very useful, because each case tends to be judged on its own merits. For example, yes, enough people believe that monopolistic tactics are not "right" and laws reflect that.
But the goals are clear in this case, no? The regulator said "do X the way we tell you to" and the regulated decided to do Y instead in order not to break the regulation requiring them to do X in a certain way.
Sure, but what precisely is your concern? That people aren't pleased about being caught in the crossfire and are complaining about it, and you want them to stop doing that?
I’m not sure why you’d lump that together here? Motivations and context and the actual facts of a particular situation matter. Nobody has said “no group can ever use their power” which is what you’re hearing. People have said “certain uses of power are morally wrong” which is why the specifics matter.
It's an interesting theory. However, Samsung has already started to roll out One UI 9, which is built on top of Android 17 a month ago, so their clock has already started ticking.
I'm not familiar with the concrete wording of the regulation, but I would wager that the all the customization layers (like "One UI") that OEMs put on top of AOSP is the component for which the update clock should tick, and they should be unaffected of an underlying open source component (AOSP) being released.
A problem with legislation in general is that it is often very open to interpretation. Especially legislation around fast-moving technology fields. It’s very difficult to write both broadly applicable legislation that requires minimal interpretation. And in fact leaving the regulation open to interpretation can be a feature from the point of view of authority.
The only interpretation that matters is that of the Authority of enforcement and judgement. The implementer’s interpretation doesn’t hold much weight.
We can say what we earnestly believe the regulations mean, and how they can be met, but if the authorities say “not good enough” that’s all that matters.
Android 17 is old news, and OneUI 9 was what delayed the OS version bump for months, because Samsung planned to launch it with on new flagships first, during summer Unboxed event.
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.
> 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.
(c) and (d) treat binary releases as equivalent to source code releases, so that's rather the opposite of making a distinction between open and closed source. It would serve as an explanation if Google had started to release source code and binaries simultaneously, but it doesn't explain why the source code release is delayed even beyond that.
EDIT: I see that was already brought up multiple times when you posted about it 11 months ago.
As far as I understand, most OEMs are not allowed to release QPR1 or QPR3 either (not that OEMs outside maybe Samsung would be able to). So part of it also reeks of giving Pixel benefits over phones of other manufacturers.
Since they are working with two OEMs (one for GrapheneOS support and one for getting embargoed security patches), I think they know what they are taking about.
Nothing of that has to do with OEMs being forbidden from shipping QPRs though.
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.
Nothing of that has to do with OEMs being forbidden from shipping QPRs though.
Are reading the same post?
“ The new APIs are currently exclusive to the Pixel OS and aren't available to other Android OEMs. […] Non-Google Android OEMs and AOSP-based projects can ship yearly and QPR2 releases.”
the person running it has a penchant for overexaggeration and selective truth telling when they feel aggrieved.
if that is the case then it should be brought to the respective overseen regulatory body, weather it is for them to clarify that this is not a valid interpretation of the law (it's at least clearly in conflict with the spirit of the law) and intentionally delaying public releases this way is a no-go or weather it is to amend the law to make it more explicitly illegal
either way if that is true it looks like a very intentional abuse/misinterpretation of existing regulations
It's not a CRA obligation, but a rule from ecodesign requirements for smartphones (Reg. 2023/1670)
> 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;
Ecodesign is so nice! The vacuum energy reduction requirements that also introduced mandatory of suction power, aside from starting a market trend towards better suction, saved:
- 45 kWh per household per year
- 11.7 TWh of electricity in 2020 EU-wide
Literally just from better designed consumer vacuum cleaners.
How does that prevent them from releasing 17 QPR1 now given that 17 QPR1 is already released "by the operating system provider or on any other product of the same brand"?
The second part explicitly addresses this, Pixels getting QPR1 starts the timer.
My understanding is as follows: They're delaying source code releases for security updates, but they're privately sharing source and binary security updates with partners. Source releases are embargoed, binary releases aren't (I assume it's to avoid triggering the ecodesign clock)
When patches go out to partners in October, they are immediately released by GrapheneOS for users who opt-in for "security preview" releases. Stock Pixel users might get them in December (triggering the ecodesign clock), and other brands could get them as late as April (per ecodesign requirements).
So the timeline could look like:
June: Vulnerability discovered
September: Vulnerability patched
October: Source and binary patch sent to partners. Patch can now be reverse engineered and actively exploited.
October, shortly after: GrapheneOS releases an update with the binary patch
December: Vulnerability is officially part of the December bulletin, Pixel officially gets the update
Not completely. Android Security Bulletins only have fixes for vulnerabilities marked high/critical in resent years. To get all other security fixes, you need QPRs and major releases.
I didn't dispute that they're delaying source code releases for security patches, I only pointed out that these regulations can't explain why they choose not to publish QPR1/QPR3 while publishing QPR0/QPR2.
It's Cyber Resilience Act (Regulation (EU) 2024/2847) - if there's a security patch that shows up in public, then the manufacturers are fined if they don't immediately roll it out as an update ("without undue delay").
I think that's the one that made a lot of OEMs pull back on opensource publishing, because their legal departments want to batch the CVE monitoring and reporting obligations into smaller batches.
Aren’t most OEMs in violation anyway because Linux (as in the kernel) gets regular security patches and most OEMs are on ancient kernel versions?
Also, major Android releases and QPR2s have many security fixes (anything not marked high/critical), yet OEMs are not rolling them out (QPR2) or very late (major releases).
Just to say that OEMs were probably violating the act already before Google started withholding source code.
I also think it’s an attempt of Google closing up AOSP more, otherwise they wouldn’t make it so darn hard to get updated Pixel kernel trees.
I think it's mostly the "you need to monitor CVEs and write report within 24/72 hours" that causes OEMs pain and they prefer to have less work than more.
Also - the reality of what you think is ok and what a corporate legal department think its ok is... rarely the same -_-
This. CRA only means that you need to assess with 24/72h that you are affected or not by a published CVE.
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.
This reminds me of the OpenAI hack against Hugging Face.
Regulators present an impossible goal to the companies to implement, instead of implementing the goal, the companies try to reward hack their way around it.
The end result is that they basically try to make it impossible to know about vulnerabilities because that would start the clock.
But doing timely security updates is not impossible. Apple does it, GrapheneOS does it, Google does it with Pixel, Samsung is nearly doing it on flagships.
But many Android OEMs are probably terrible at software engineering and have their attention spread across multiple SoCs, etc. It’s their own fault.
> But doing timely security updates is not impossible. Apple does it, GrapheneOS does it, Google does it with Pixel, Samsung is nearly doing it on flagships.
What does "timely" here mean? A lot of security patches for all these companies take ~weeks+ to actually make it to customers due to things like QA testing, carrier testing and release processes.
The time between disclosure and release can be rather long, months even for all of them. (I'm counting private disclosure here.)
What does "timely" here mean? A lot of security patches for all these companies take ~weeks+ to actually make it to customers
Google has an embargo period of up to 6 months on AOSP patches. This is why GrapheneOS already has April 2027 AOSP security patches now. Even though some patches are already known for 6 months, they still manage to ship it 1-3 months late. 7-9 months after they got the patches already from Google.
due to things like QA testing, carrier testing and release processes.
Carrier testing is mostly a US thing. If you cannot roll out security patches within a few days, your QA and release processes are just totally broken. GrapheneOS can do it and they generally have far fewer regressions than Android OEMs.
Major releases and QPR2 take some time for testing, but they already have the access to sources months before they are released. Heck, Samsung releases major release betas and QPR2 betas quite a while before Google releases it as stable.
The problem is that the OEMs made a mess. First they just dropped phones on the market without doing any updates at all. Mid 2010s it was very normal for an OEM to do maybe one or two updates. Then Google had to push them to do better, among other reasons because Apple does much better and there were really big fails like Stagefright. Plus users wanted new Android releases. Then they did only 2-3 updates with very irregular software updates. Now they are under pressure from EU regulations and they actually have to support devices for a long time and do regular updates, but they just don't have good release processes. Plus they made their own 'skins' on top of it that they have to rebase, etc.
Companies that have their ducks in a row better, abuse the release process to push sales of new devices. E.g. Samsung withholds major/QPR releases for a while so that only their latest device have it, e.g. recently Fold 8/Flip 8.
People should stop beingapologists for multi-billion dollar companies.
I'm not sure what you're trying to say here - I've mostly said that for the corporations you highlighted, "timely" can still mean months for a given security patch to be deployed as things stand.
That's the reality - yes, even for Apple.
If you think they could and should be better - I guess I agree, but it doesn't change the reality.
Ha ha ha, that'll take spyware to a whole new level. "You're running an old vulnerable version of Android, upgrade today to Android-45.123-robustdonut to get the latest security. Now with 100% genuine AI."
withholding security updates seems to avoid a law which requires rolling out security updates seems very much like something which needs to be fixed one way or another
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.
That’s not true; the only way to be found guilty following a CRA is to conceal the active exploitation of a vulnerability, fail to alert the national coordinator, fail to propose a mitigation within a reasonable timeframe, or be openly negligent in the management of the cybersecurity of one’s products.
“Please stop using this version of my product or this particular feature; it is vulnerable” is an acceptable mitigation measure.
A CVE isn't an active exploitation and don't trigger anything.
nit: "without undue delay" does not mean "immediately" under any legal interpretation, only that the timeline should not be longer than necessary. This leaves a lot of wiggle-room in favor of the manufacturer, and mainly rules out that they go "eh, we'll look at all these in half a year maybe".
As long as they start the process and it is not absurd from an industry standards perspective, they should be good. They can have slow processes, including being a good bit slower than their peers, without running afoul of "without undue delay".
They have literal 24 hour and 72 hour deadlines. Obviously, they might put a blind eye to it if you are reliable but delayed the reporting by a day, but the 24 hour and 72 hour deadlines are a fact. You have to initiate the reporting immediately.
You are mixing unrelated requirements together here.
> 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.
You are confusing two different articles. The 24-hour deadline relates to notifying the national Computer Security Incident Response Team in the event of the detection of a confirmed exploited vulnerability of one of the manufacturer’s products (Article 14). Submitting a bug report and opening a ticket does not constitute a confirmed exploitation in the wild. Nor does the publication of an exploit or a PoC constitute a confirmed exploitation of the vuln in the wild.
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.
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.
> nit: "without undue delay" does not mean "immediately" under any legal interpretation, only that the timeline should not be longer than necessary. This leaves a lot of wiggle-room in favor of the manufacturer, and mainly rules out that they go "eh, we'll look at all these in half a year maybe".
Well, the corporate lawyers think otherwise at those corporations, so I'm not sure how much your interpretation counts :)
I do not believe that any corporate lawyer would think that. It does not read like that in neither plain english nor legalese.
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.
Google hasn't delayed pushing releases to AOSP but rather stopped pushing Pixel exclusive releases to AOSP. Android 17 QPR1 and Android 17 QPR3 are Pixel exclusive releases which won't be pushed to AOSP under the current policy. For 2/4 quarters per year, Pixels are on a major release of Android exclusive to Pixels and not released to AOSP. Non-Pixel devices don't get QPR1 or QPR3 releases. This is part of Google dropping support for Pixel devices from AOSP and giving them an artificial advantage over other Android devices.
If this is the case, I wonder why isn't Google publicly saying this. Because right now, it looks like they've stopped publishing the sources just because they felt like it, which has understandably generated a lot of backlash, but I feel like all the backlash would go away if they pointed at the EU regulations.
Interesting theory. Is there a distinction between phone release and os release there? I would imagine the time starts when the model goes in sale, not when the os releases.
Otherwise I would expect Google would also wait with pixel updates
This vicious European Union, which stifles innovation and works against the public interest – for example (checks his notes) by mandating USB-C charging and replaceable batteries!
I'm not disagreeing with you, and I don't understand the market.
But surely, unless the regulation is written in an especially thoughtless way, the clock would start at either the time the device manufacturer has access to the upstream fix, or the time that the manufacturer provides an update to any of their devices (which implies access to an upstream fix).
So public source release would only impose additional burden on device manufacturers if it is the first time that they are seeing the upstream fix.
No, it's not. (source: used to work on Android at Google, and its as simple as it seems, more and more MBA-style management meant more and more didn't care, which meant it was more and more poorly resourced, until it was discovered by revealed preferences that no one cared, at least, no one cared enough to speak up)
> due to a recent EU regulation majorly backfiring
And why should a regulation in EU affect rest of the world. Or for that matter, any US regulation. The arrogance of these nations and the ignorance of tech companies is ruining the entire Internet.
Because making things everywhere compliant is cheaper than having both a non-EU and EU versions of software. See also: Brussels effect[0].
It's simple economics. The companies are also allowed to either do special versions to comply with local laws or even to pull out of the market. They just choose not to for reasons.
Sure, American courts ask for age verification, the entire world needs to comply now. Then people wonder why so much surveillance. You can’t see past Brussels effects, because ignorance.
Oh, it’s 100% absolutely Claude. There are more tells than this.
At any rate, “developers are disassembling it to find bugs” sounds extreme, but this is something Claude will do almost spontaneously, in my experience. I ran into an issue last week where a library wasn’t doing what I expected, and asked Claude to sort out why; I came back a few minutes later to find Claude tearing apart the library’s disassembly to reveal a mismatch in struct sizes between the library’s expectations and my headers. And it did solve the bug!
Not just Claude. In my experience, almost any LLM running in Pi would rather go down rabbit holes than ask for clarification. I think the solution is to restrict what the LLM can do: If it keeps running into "permission denied" when trying to run disassemblers or read files in /lib64, then it's probably not doing what the user intended it to do.
But you're right, that report is definitely written by an LLM. Humans don't typically put parenthetical postmodifiers in headings ("Mechanism (from the shipped libc.so)"), but LLMs just love them too much.
LLMs can't help but leak details about your project into the bug too. When it started rambling about effects on Virtual Pinball or whatever it was, that was the ultimate giveaway. Completely unrelated to the bug, the fixer never needed to know, but to the LLM it's crucial data somehow.
We are already there and it is called Play Integrity (meets STRONG integrity) and Google is trying to get apps to use it to shut out competitors. They are succeeding to some extend (see the Volkswagen and IKEA Smart Home apps as recent successes for Google).
Google should not be allowed to abuse its duopoly position in this way. I recommend EU citizens to report every case they are (potentially) affected by to the EU DMA team.
> see the Volkswagen and IKEA Smart Home apps as recent successes for Google
Someone should make a complaint about ePD violation in relation to those. I doubt it's "strictly necessary" for those applications to read that information (if they even fulfill the "at distance" requirement).
I think that the EU shall render this practice (and the equivalent from Apple) illegal, stating that every citizen has a right to modify their own device without consequences, and that consequences shall include also having apps not working.
But to me big tech succeeded also lobbying the EU like they already did in the US, in fact they violate multiple EU rules (GDPR, etc.) without facing any consequence, and when they try to announce they would do something at the other side of the ocean they treat us that they will double or triple tariffs so...
> stating that every citizen has a right to modify their own device without consequences, and that consequences shall include also having apps not working.
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.
A distinction without a difference - the purpose is to verify that the device on which the app runs hasn't been tampered with (for Play Integrity or AppCheck) from OEM state.
That's not true. Jailbroken devices have been tampered with, but the Secure Enclave is still fully functional. Device Check is designed to catch non-genuine hardware or non-genuine app binaries, NOT tampered software.
Hmm, you're right. It looks like some older devices were able to be jailbroken into a state where the Secure Enclave was in an untrusted state, so you couldn't use authentication, but the encrypted flash was still accessible as long as you didn't have a passcode set. I thought even that wouldn't work in an untrusted state, but it appears I was incorrect.
(I was reading recently about the SEP's behavior after a memory authentication failure -- it completely stops accepting requests until the processor is reset -- so I thought that applied to trusted boot violations as well. Seems not.)
I suppose that also explains why every time I open Settings, the Apple Pay section is missing for a moment before it shows up; the OS is apparently able to function without it. Interesting bit of trivia.
Trusted computing is fine and even good only if the owner (the person/company that bought the device) is in control, but it's not the world we live in.
> owner (the person/company that bought the device)
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.
Is your theory really that closed source software will just stop being developed? I can't find another way to read that, but you can't think Google is just going to give up and shut down, right?
> But why invest time and money when your features get copied as soon as you publish it?
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.
Look at spaces where ripoffs/copying are already rampant like mobile games. The result is a slop avalanche, rending the whole space commercially unviable for anything other than the most bottom-of-the-barrel dark-pattern shitware laden with scam ads and spyware because users don't care and won't pay.
That may well be the future for most commercial software (and software engineers) as margins collapse and AI tokenomics moves more power from labor to capital.
You think open source never develops new features?
The only thing that made commercial software more innovative is most developers never had time to build and maintain a big open source project without support from their job. Now we have agents and it takes a lot less time to implement your ideas. That means slop filling up GitHub, but also that people who came up with good new features can make them real in their free time.
ReSkate is a good example, it's a project 90% coded by AI but the people working on it are passionate and most of them are experienced game modders. They know what made the old Skate games special and wanted to bring it back to the new one. Now it's better than vanilla Skate 4 and has tons of new features never seen in the OG trilogy. That project would never be possible without Claude taking care of the hard and boring RE work.
> Who beside the open source community develops new features if they can be easily copied?
But I guess they will also think twice if big companies can rip off the software with clean room AI implementation to circumvent the open source licenses
Only the "copyleft/copyright extremists" who want to exert their own form of control over others are going to worry, while everyone else just gets to work asking AI to do what they want, and possibly even getting paid to do so.
AI's pretty good at copying features even when it's closed, or online.
Not perfect, of course. All that hype about the vibe-cloned Adobe suite is, today, hype. Next year it might not be, though that depends on questions like "will investment bubble pop?" etc.
But we are at a level where, if you can describe a feature or process well enough to test it, an LLM can develop and optimise for that feature/process. That creates opportunities for businesses to have custom just-for-them business software, which nobody copies because nobody outside the business even bothers to learn exist.
Google is doing better here than Apple. Most google devices have an unlockable bootloader.
I have old Chromebooks and Nexus Tablets that are EoL, but I can install linux on them and give them a second life.
The source code for my old EoL pixel phones is out there, it's just a matter of effort to port Ubuntu or PureOS or one of the other Linux phone distros to them.
It's Apple that is being as evil as possible when it comes to stomping down alternatives, they don't release iOS source code, they bricked most of my old devices when they EoL'd them by not letting me unlock the bootloader and install my own OS, they don't release drivers.
I'm deeply unhappy with Google's current direction, but they're still lightyears from the level of evil Apple inflicts upon us.
Tbf, Apple does in fact keep their ‘Apple OSS Distributions’ GitHub current.
This is the TiVo situation. Does open-source require allowing third parties to install their own software / OS and have unlimited control over the device? (GPL v3)
Or does it regard to access to the source code but not access to the device? (GPL v2)
TV’s, routers, IoT, etc vendors aren’t even allowed to ship devices with user-alterable software!
Yeah, while I am loathe to trust Google again, will never be buying another Apple hardware again too - I used an alternative map app on an old iDevice and wrote them a 5-star review for their good features, for being better than Apple and Google maps (in some aspects) and especially for still supporting older devices. A new update for the app was released and suddenly I couldn't install it because App Store reported that my ios was outdated and not compatible with the new release. So I revised the review for the app to 2-stars pointing out they had suddenly dropped support for older iDevices which was one of their main attractive features. The developers of the app contacted me asking me to reconsider the review. According to them, they had released the latest update for the app for the "outdated" ios version / older iDEvices too, but Apple deliberately sat on it without approving it for the App store. According to them, Apple hasn't clarified the issue. If the developers are being truthful (and I do believe them), this is a deliberate and malicious act by Apple to push planned obsolescence of older iDevices.
> but iPhone 6 came out in 2014, twelve years ago. That seems reasonable ...
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.
They exist. But they don't support Android apps that are unfortunately necessary. For example, any phone without WhatsApp or banking apps support is dead on arrival in Europe.
Which is why /e/ OS and Graphene OS adoption is higher than projects such as PostmarketOS (now Nura) or Ubuntu Touch, even if they are already quite mature. I daily drove Ubuntu Touch for two years in 2019 and 2020, and it's the need of Signal which made me switch to /e/.
The problem doesn't lie with e/OS/, nor any other alternative. Google locks down capabilities with "Play Integrity", effectively attestation for official Google approved operating systems only. If you aren't on the list you fail the checks, and apps (like banking apps) will fail to run.
But it’s banking apps that opt into that. It’s not like Google is saying you must use Play Integrity. It’s a feature that banking apps are more likely to use. The EU could require banks to make apps for other operating systems.
It's still Linux, though, the same way Ubuntu is still Linux despite carrying custom patches and security frameworks.
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.
Ubuntu is GNU/Linux, you don't run Afterstep on Android via NDK, unless you rewrite X Windows or Wayland to run on top of OpenGL ES or Vulkan surface that is then hosted inside a AndroidView or JetpackCompose display surface.
Which is what Termux has to do, just like they have to call into specific Android services via JNI, as the NDK only exposes official NDK APIs, alongside the C and C++ standard libraries.
Yes, let's throw away a fully mature smartphone OS (AOSP) and replace it by something that does not even have proper app sandboxing. /s
The alternative are other AOSP-based OSes like GrapheneOS and Lineage. Once they are used widely enough and funded enough, they could fork AOSP when needed. In some sense they have already soft-forked in that they use major and QPR2 releases, but put a lot of patches on top to fix issues, improve security, etc.
GrapheneOS has an estimated 500,000 active installs now, apparently LineageOS has 1.4M active installs. Probably around two orders of magnitude more than traditional Linux desktop-based phones, which have been trying since, checking notes, Maemo in 2005?
Btw /e/ OS people have already shared that they were getting ready for a hard fork of AOSP looking at how Google is acting.
But to be fair the challenge is more around the hardware support than the OS itself, so in the end it will be the chip makers which will decide which OS can run or not. If they go the AMD way then great, if they go the old nvidia way where even basic reclocking is impossible then we are screwed.
I would be surprised if they have the expertise and manpower to do that.
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.
I agree, nevertheless, Murena has 50 employees and is profitable as a company. Idk how much money lineage and Graphene have, hopefully the partnership with Motorola is going to provide them some funding.
There is a mass market Android/iOS alternative, it's called HarmonyOS on 50 million devices. I expect that's not quite what you were hoping for though.
> We need an Android alternative, something that respects users' freedom.
The more successful Android alternative - iOS - that people love so much doesn't do any of that and it's apparently even more secure and earns even more money.
It's the result of going public. Once a company even dips their toe in that water, it's over for any priority but one.
Isn't one of the main limitations to more open mobile platforms due to opaque drivers? The very recent trends in reverse engineering might provide some solutions to that.
Google hasn't delayed pushing releases to AOSP. There are 2 major releases of Android available for non-Pixel devices every year and those are pushed to AOSP on launch day. Android 17 and Android 17 QPR2 are the relevant releases for 2026.
Google removed Pixel support from AOSP with the release of Android 16. They did so by no longer pushing the device trees, kernel drivers, userspace drivers/HALs and Pixel exclusive releases. That means there are no longer device branches pushed to AOSP for the OS releases used by recently released devices or variations from the standard releases. The monthly and QPR1/QPR3 are now considered fully Pixel exclusive and no longer pushed to AOSP either. That's why this code isn't pushed to AOSP. The remaining non-Pixel-exclusive releases of Android are still pushed to AOSP at launch.
Google is abusing their control over Android to give Pixels inherent advantages over other Android devices. However, in doing so they've also harmed the value prospect of Pixels by taking away official AOSP support which has made it much harder to support Pixels for other operating systems and even for app developers.
Pixels are now on Pixel exclusive QPR1 and QPR3 branches for half the year without sources available. For the other half of the year, they're on the same major yearly and QPR2 branches as other devices. Android 17 QPR1 is the latest major release for Pixels but Android 17 is still the latest for non-Pixel devices. Android 17 QPR2 will be the latest for both in December 2026.
They're not pushing the monthly, QPR1 and QPR3 releases to AOSP with a delay but rather not at all since those are only for Pixels and AOSP doesn't support Pixels anymore.
We need a third option. Be it SalfishOS, Ubuntu Touch, Nura, or whatever picks up with a sizable community. We just need to start developing and investing in that one. It won't be perfect, but it will offer an alternative and control to the users.
There are plenty of alternative OS options. None are accepted by phone companies and shipped in orders of 100m devices worldwide.
Android has ~4b cumulative users, iOS 2.5b. Combined 1-2b phones are shipped annually, so phones are replaced over 3-6 years or so. Total production numbers of Sony PS2/Nintendo Switch are ~160m each, and there haven't been enough of those to be a viable alternative consumer platforms. China moves couple hundred million units per year of de-Googled phones internally(Google services are default banned in China except through Hong Kong VPN and such), and that doesn't seem to be changing situations much. Windows Phone was like few hundreds total.
The third option has to ship like 1000m - 1b units total and/or annually to be viable. Code quality... isn't going to matter, but it'll have to be literally 10-100x more popular than Nintendo. That is going to be the bar.
Wouldn't it be better to start focusing energy onto projects like PostmarketOS (now Nura)? Sure the Linux phone space on the hardware side is a bit barren, but there are options and you don't really need top of the line specs to get something working; you could even use an SBC with a cellular modem peripheral to have a cellphone replacement.
Bit of a hyperbolistic title. The core of the bug report doesn't require disassembly of the library. The bug author just went the extra step to do a root cause investigation, which of course requires light reversing work.
Given the current trajectory of all things, I think that the drawbacks will outweigh the benefits for a project like AOSP due to the changing economics. The reduction of SBOM (and therefore the attack surface) will be far more beneficial than the saving of work from hundreds of imported dependencies. The trend of vertical integration will likely happen in software sooner or later.
Good look with NDK issues, having the source code available would not help much anyway.
NDK seems to be handled like a 20% project in terms of allocated resources, I bet it has not more that like 2 FTEs, given its progress since Android 2.1.
Forking Android is not an option. Android is way too complex for any company or band of open-source developers to take up. The fork would quickly fall behind Google's implementation and become effectively useless.
What maintained forks of Linux are there that actually do their own general improvements and maintenance besides just following along upstream with a custom driver or two? I'm even going easy and only referring to the kernel, even though "Android" is a lot more than that.
8 out of the top 10 manufacturers are Chinese. Google has to be careful here, otherwise Android will end up as a Chinese consortium and their own version will just be available on Pixels.
But Western consumers at large won't buy Chinese devices if they don't carry the Play Store. And many Western app developers won't want to deal with Google Play Services and it's APIs missing, which is what made porting to Amazon's Android fork annoying as fuck.
That's the huge, huge carrot that Google carries in front of everyone thinking to fork Android.
They don't want to deal with Google Play Services missing because it's pretty rare to have a mainstream phone without it, as soon as the Chinese manufacturers pump out millions of devices without it in the western market all at once, the developers will have to follow.
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.
Yes that's also a real possibility. The sanctions on Huawei were a terrible idea, it became a laboratory of what could be rolled out on the whole country if needed. Now this work has been done.
Yes, but my point is even stock Android is superior than iOS for usability, obviously custom ROMs such as Graphene or even proper GNU/Linux phones would be superior to Stock Android for customizability.
You might as well say that the average smartphone is not unlockable because iPhones aren't. People who want the advantages of user control don't buy the average device. They buy the devices they can control.
You're reading their comment in a way that most people wouldn't and that the author clearly didn't intend. Android can be and is installed on lots of appliances that aren't meant to give users control, like refrigerators and many Samsung phones. It is also installed on devices that give users control (and can be installed on lther devices that give users control and don't install Android by default). That is the difference between it and iOS.
I would argue though that even Samsung phones give more user control than iOS phones (not that I would buy either one). Even though you can't install your own remix of Android, you can disable or remove most of what you don't like and install anything that targets the Android APIs.
You can install third party stores and apps on iOS without a waiting period (in places with decent consumer rights); confirming three popups is all you need to install third party iOS apps.
Unlike on Android, there aren't that many third party iOS apps, though.
Plus, even with Google delaying shipping source code, at least they ship the source code. The traces of source you get with the open Darwin code are nowhere near comparable.
It doesn't do app store reviews as far as I am aware. They do charge an installation fee (I'm baffled they haven't been sued over that yet), but there are free apps out there thanks to Epic covering that fee to spite Apple.
Seems that this €0,50 flat fee per installation has been replaced by a 5% commission on digital transaction made through sideloaded apps as of last August.
It's fully your right to want non-webkit for your browser, but just curious. Why? Why does it matter? I've never once wished for firefox to use firefox's engine instead. The UI/sync/extension stuff is all built on top anyway.
I can't prove it, but I still think this is (partly) due to a recent EU regulation majorly backfiring. I can't remember which one it was, but one of the recent regulations mandates that devices get updates for a certain period. Within that period a manufacturer must provide each update for all their devices in a short timeframe. The intention was to prevent flagships getting updates immediately and lower end devices having to wait months. However, due to some (also well intentioned) wording about open source, the release of the source code is counted as the first release of an update and starts the timer. I'm pretty sure Google is delaying public AOSP updates to give their partners (mainly Samsung I suppose) more time to finish building their updates on top of AOSP.
> EU regulation majorly backfiring
I wouldn't be surprised if large corporations like Apple and Google intentionally use these tactics to pressure regulators through their European users. Siri AI is a prime example. While it's a complicated issue, I certainly wouldn't put such maneuvers past them.
It's funny that they keep trying, it has never once worked. I think US companies are projecting their dislike for regulation and keep being surprised that EU citizens don't agree. We do not love the EU government, but it sometimes does a good thing and we do like these, especially versus the anti-consumer crap that US companies like to pull.
we do not love the EU government because there are billions being poured into promoting the discourse that the EU is a bad thing by both private and state actors.
My problem is the lack of democracy through the too-indirect way that the commission is elected. Von der Leyen was an extremely unpopular and horribly incompetent (at least in charge of defense) minister in Germany, then somehow she became president of the EU commission. Her skill seems to be politicking with other politicians. That would not have gotten her elected in an election by the people.
And it is the nation states that fight tooth and nails against more direct elections.
Nation states in the EU follow the direction their politicians get pointed at by the money that gets them elected.
A more powerful EU would mean less power for big corporations and wealthy individuals.
Right now, "EU washing" unpopular policies is a thing. National (usually corporate) interests can make EU laws happen, and when they have, national politicians say "Sorry, our hands are tied - EU law!". So I'm not at all optimistic that the EU political organization, of all things, will reduce corruption just by getting more power. But I do think that more direct elections to powerful EU positions will improve things.
Sometimes its a good thing that people do not elect directly. They participate indirectly though. And there are general rules to follow. So its more stable framework than full public control each election cycle, because the populism happens and if you want to be elected you cant take unpopular decisions which sometimes are needed.
There are unpopular decisions that are actually good, and those that are simply bad for the population but good for people closer to power. I think the latter are more common in basically any system with too little public oversight.
If you are talking about judges, prosecutors or sheriffs I could understand your opinion, but we're talking about a political function here.
Indirect democracy is not really a lack of democracy. But I dislike the way it works now as well and would like for EU elections to be more direct. I'd also like to be able to vote for candidates from other member states.
However changes like these are deeply unpopular as they get interpreted as moving more powers to "Brussels" by right wing media.
Right wing media is usually owned by specific billionaires.
Their agenda isn't that of "ordinary people". Those rather get used for the interests of those "strategic investors".
Less power for Brussels means more power for rich people.
This was really lame cope ten years ago and it's really lame cope now.
Because the European Union has come up with shitty laws and regulations.
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?
Blame the shitty tech companies, the DMA and similar attempts in the USA and many other countries stem from them stacking everything in their favour at the cost of everyone else's money, privacy, security and safety.
It's not like regulators were just bored and felt like fucking shit up, there is a nearly-global consensus these companies are exploiting consumers and markets.
Except that DMA didn't do anything for more fundamental problems like the email problem.
No, they just want to have something to brag about or think they know better (Soviet/communist style). Like, we're lazy and tired of having to carry our proprietary iPhone chargers, we know you're too, let's make USB mandatory.
Don't believe the chargers are a good example. There definitely must be some good ones. But Apple is being anti non-apple consumers (and often anti apple consumers, vide ridiculously expensive monitor stand) for a long time, doing everything to make sure nothing non apple can work well with apple products and vice versa.
I can (actually can't, but for the sake of argument let's pretend) imagine why my wife's Air Pods Pro 3 can't supply heart rate data to my phone for exercising. But why can't they report battery level? ffs
Even if Lightning is better in some aspects (USB-C tongues break sometimes), forcing people to have special cables just for apple devices, when every single thing runs on USB-C, feels like done out of spite. And then? Apple devices don't support any fast charging standard. Spite again.
It's hard to see it differently, but there might be better reasons and arguments that I can't or choose not to see. Probably because I don't love the company that forced poor parents to buy their kids expensive phones just so the kids wouldn't get ostracized for not having green or blue bubble in text messages.
If I don't like the product because of its charging mechanism, not reporting battery level etc, I don't buy it.
> USB-C tongues break sometimes
Unlike barrel chargers which are also simpler. No need for fancy electronics and protocols. Let's not forget non-compliant USB chargers. I remember reading about a Chinese mini-PC manufacturer that sold a computer with a charger which provided 19V or so from the start without any negotiation. Hopefully no one tried to use it with another device.
>Let's not forget non-compliant USB chargers. I remember reading about a Chinese mini-PC manufacturer that sold a computer with a charger which provided 19V or so from the start without any negotiation. Hopefully no one tried to use it with another device.
I actually (or somebody close, friend or family, can't recall) did exactly that. It was a few years ago and I don't remember what got fried. Some small electronics. It was a barrel charger and it fit. Too bad that fitting didn't mean the power levels were ok too.
> I don't like the product because of its charging mechanism, not reporting battery level etc, I don't buy it.
Why shouldn't my wife get headphones because a company is a dick and makes them not work with her husband's phone properly? Looks like a dismissive argument trying to excuse malicious business practices. (I'm not in or from US, maybe that's normal and OK there, so sorry for ranting about it, as it might be fine or even good for you if you're invested in Apple). Anyway, why not buy them, headphones work very well for my wife. Other than price not being adjusted to product performance and quality, AirPods Pro 3 are a very good product. HR reporting is a cool feature. And I don't have bud-type earphones, so I borrow hers for exercising.
Back to "don't buy it if you don't like it" argument: it doesn't argument against apple being dicks for making the product purposefully not work with an Android phone. And if it does, please explain it more clearly, I believe I'm not the only one holding the point of view that it just doesn't exonerate them.
As I see it, it's malicious compliance, as there's no laws YET forbidding what they're doing. (Somebody recently RE'd AirPods BT protocol/calls IIRC and found them reporting battery on non standard ?variable name?. He then got Android phone to show battery level after a small modification.
For comparison, I would bet a beer (I see betting more as gambling) that if Samsung created headphones with HR monitor, I would still be able to see battery level and HR in my Oura app on my OnePlus. And vice versa for 1+ headphones on Samsung. Do you see my point?
And for the record, apple has recently released many phones, both low and high end, that weren't overpriced. And I vehemently oppose anyone whom I'll have to tech support later, getting any phone different than apple - for a non technical user these phones are perfect. Good default's. Non customizable - perfect from point of view of tech support. Just works. Just to show that I'm anti anti consumer conduct, not anti apple.
> It mandated USB for charging everywhere, but didn't do a thing about driving on the right side of the road.
You forget that the worst offender took its toys and went away not too long ago.
It takes time. And there will always be something to complain. But don't you agree that things are moving in positive direction?
Not quite. There's more and more you have to deal with instead of less. I don't want more laws to read and comply with, I want less.
I bet most people have not read any laws in past year. hell, some have not read any laws in their lives. And no i don't agree that i want fewer laws. By the way, how many laws is enough for you?
Most people don't read any law their entire lifetime and hope for the best. But are you willing to risk it, if you're trying to do something? It does not even have to be complicated, it can be something as simple as having a website. Suddenly you have to deal with GDPR and it's not an easy task, otherwise we wouldn't have so many discussions and consultants, not to mention the fact that some websites prefer to just block European users.
The PDF for GDPR has 88 pages [1]. And it's just one thing. The AI act has another 144 pages [2]. Who's gonna read them?
[1]: https://eur-lex.europa.eu/legal-content/EN/TXT/PDF/?uri=CELE...
[2]: https://eur-lex.europa.eu/legal-content/EN/TXT/PDF/?uri=OJ:L...
Well DMCA is 60 pages, do you read it when you are creating a web page?
https://www.congress.gov/105/plaws/publ304/PLAW-105publ304.p...
We have civil code for everyday life, do you think people read that? I bet no, but anyway it describes rules by which people live. And when there is disagreement we open a book and see whos right. Do you think we should not have such rule book?
> fining X/Elon Musk and Meta because we hate them.
They were fined because they broke the law. Many consider these fines, a slap on the wrist. Personally I support much harsher and detrimental punishments in such cases.
You misunderstood me. I wasn't saying they didn't break the law, I honestly have no idea if they did. I was only saying that some people like the law because it makes people/companies which they hate (possibly for valid reasons) suffer. In other words they like only the sentence.
I don't think this is any corporate conspiracy. The truth is probably more mundane: regulation is treated as obstacle to navigate around with minimal amount of effort, and not a reason to give up on practices that makes money.
A system that leads to bad outcomes is a bad system.
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's funny that they keep trying, it has never once worked.
Sure it has. Consider cookie banners: widespread malicious faux-compliance from the start, and approximately nothing was done about it for most of a decade, while people were tricked into believing they were GDPR’s fault. Even now when a little has been done about it, the significant majority of cookie banners are very obviously not compliant with GDPR or ePD requirements, and no consequences occur.
Yes Us Companies Are doing this ofc
They absolutely do this.
Giving their partners the time they need to finalise their releases legally seems like a... completely normal and correct thing to do? Why does everything have to be a big conspiracy?
Why would that be a normal and correct thing to do? They're delaying releases for everyone else.
https://grapheneos.social/@GrapheneOS/115164133992525834
https://news.ycombinator.com/item?id=49946698
So it is not normal/correct to have an agreement with a partner that excludes others?
No, not in an open-source project. Nor is it correct to build the project under the guise of open source and then pull the rug from underneath. Or any of the other anti-competitive, anti-consumer, anti-security crap they've been doing lately.
Normal? Sadly yes.
Correct? I suppose that depends on your definition. From a corporate perspective, perhaps. But from a consumer's perspective it's most certainly not the desired outcome.
Sometimes it is, sometimes it's not.
They don’t have agreements with graphene so what do they care? Google owes graphene absolutely nothing.
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.
They're skirting the law and they're likely to be breaking it too - if not on cybersecurity grounds then almost certainly on anti-competitive grounds.
Even if we set legality of their behavior aside, they deserve scorn for how they've been managing Android for the past couple of years - every Android user is worse off because of them. They broke off productive relationships with grapheneos and other projects which contributed patches and reported vulnerabilities upstream, they're engaging in anti-competitive conduct and imposing limits on OEMs, giving Pixel devices preferential access to new APIs.
They're simultaneously putting their own customers (Pixel owners) at risk of known, exploitable security vulnerabilities. They do this to help other OEMs legally skirt (maybe) the 4 month timeframe for patches which is very lax to begin with. Thereby opening a whopping 8 month window where Android users can get hacked by known vulnerabilities.
Their Android 17 QPR1 release was so buggy, it made many Pixel devices almost unusable and then they went radio silent. https://grapheneos.social/@GrapheneOS/117372129125340408
How cynical do you have to be to defend their stewardship of AOSP?
> 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
Read the second link I posted above, this is patently false.
[dead]
There should be a rule that any assertion of conspiracy must at least have some evidence.
I worked at MS and was involved in several decisions to not ship in the EU because it just wasn’t worth the internal and external regulatory headache. There was no secret agenda, Satya never told me to stick it to the EU by withholding a feature in the hopes the masses would clamor for it and demand regulatory changes, which would eventually allow us to… ship the feature in a decade or so.
I’m super sympathetic to the EU’s intent, but their execution is so obviously self-defeating that it doesn’t take elaborate conspiracies to explain corporate response.
> but their execution is so obviously self-defeating
Well no. It’s not self defeating. It’s being defeated because these are US tech companies, protected by US monopoly power, and the fact that US lawmakers are captured by lobbyists and are incapable of passing similar laws to protect their constituents. Big difference.
Ah, so non-US companies are shipping every feature in the EU then?
> There should be a rule that any assertion of conspiracy must at least have some evidence.
Broadly, I agree, and good grief do I wish people would follow this more often. But Google specifically has acted incredibly anti-competitively for several years now [0], especially regarding Android. This has gone on for such a long time that they have, in my mind, lost the benefit of any doubt.
As they continue to lock down Android [1], things that would have once been met with a "Wait and see" approach are instead met with suspicion and a default assumption that it's primarily (though not typically exclusively) done to serve their own interests.
So generally, yes! That which is asserted without evidence can be dismissed without evidence. However, Google's history is all the evidence I need to assume their actions are not done in good faith.
[0] https://arstechnica.com/gadgets/2018/07/googles-iron-grip-on...
[1] https://manualdousuario.net/en/blocking-unverified-apps-andr...
[flagged]
Whether it's "right" depends on the goal of course, but in this case I'm not understanding your point because nobody is prosecuting those companies for doing this.
In any case, these kinds of blanket statements are not very useful, because each case tends to be judged on its own merits. For example, yes, enough people believe that monopolistic tactics are not "right" and laws reflect that.
But the goals are clear in this case, no? The regulator said "do X the way we tell you to" and the regulated decided to do Y instead in order not to break the regulation requiring them to do X in a certain way.
Sure, but what precisely is your concern? That people aren't pleased about being caught in the crossfire and are complaining about it, and you want them to stop doing that?
yes, because that second "group" is actually an international corporation leeching on society to increase its value for small group of investors
Is it okay for Russia to influence elections in the EU or the US by spreading misinformation?
This is also an instance of a group using its power.
I’m not sure why you’d lump that together here? Motivations and context and the actual facts of a particular situation matter. Nobody has said “no group can ever use their power” which is what you’re hearing. People have said “certain uses of power are morally wrong” which is why the specifics matter.
It can't ever just be the fault of the regulation, of course.
It's an interesting theory. However, Samsung has already started to roll out One UI 9, which is built on top of Android 17 a month ago, so their clock has already started ticking.
I'm not familiar with the concrete wording of the regulation, but I would wager that the all the customization layers (like "One UI") that OEMs put on top of AOSP is the component for which the update clock should tick, and they should be unaffected of an underlying open source component (AOSP) being released.
A problem with legislation in general is that it is often very open to interpretation. Especially legislation around fast-moving technology fields. It’s very difficult to write both broadly applicable legislation that requires minimal interpretation. And in fact leaving the regulation open to interpretation can be a feature from the point of view of authority.
The only interpretation that matters is that of the Authority of enforcement and judgement. The implementer’s interpretation doesn’t hold much weight.
We can say what we earnestly believe the regulations mean, and how they can be met, but if the authorities say “not good enough” that’s all that matters.
Android 17 is old news, and OneUI 9 was what delayed the OS version bump for months, because Samsung planned to launch it with on new flagships first, during summer Unboxed event.
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.
(c) and (d) treat binary releases as equivalent to source code releases, so that's rather the opposite of making a distinction between open and closed source. It would serve as an explanation if Google had started to release source code and binaries simultaneously, but it doesn't explain why the source code release is delayed even beyond that.
EDIT: I see that was already brought up multiple times when you posted about it 11 months ago.
As far as I understand, most OEMs are not allowed to release QPR1 or QPR3 either (not that OEMs outside maybe Samsung would be able to). So part of it also reeks of giving Pixel benefits over phones of other manufacturers.
the more I learn about how Google handles releases the more this looks like there being a need for anti trust actions
> As far as I understand, most OEMs are not allowed to release QPR1 or QPR3 either (not that OEMs outside maybe Samsung would be able to).
This is not true at all though. OEMs can release anything whenever they want.
I have read in multiple sources that OEMs cannot roll out QPR1/3. E.g. see this thread:
https://grapheneos.social/@GrapheneOS/117282080803799576
Since they are working with two OEMs (one for GrapheneOS support and one for getting embargoed security patches), I think they know what they are taking about.
Nothing of that has to do with OEMs being forbidden from shipping QPRs though.
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.
Nothing of that has to do with OEMs being forbidden from shipping QPRs though.
Are reading the same post?
“ The new APIs are currently exclusive to the Pixel OS and aren't available to other Android OEMs. […] Non-Google Android OEMs and AOSP-based projects can ship yearly and QPR2 releases.”
the person running it has a penchant for overexaggeration and selective truth telling when they feel aggrieved.
Here we go again…
Well, Graphene's statement isn't true so not sure what do you want me to tell you ¯\_(ツ)_/¯
Maybe their own source at OEMs lied to them? The QPRs are in the same repo they're getting their security patches from.
The QPRs are in the same repo they're getting their security patches from.
That doesn't mean that they are actually allowed to release them. Big difference.
Let's chill with conspiracy theories. Code is still Apache licensed.
Except for phones preinstalled with GrapheneOS (unless you are Samsung)
if that is the case then it should be brought to the respective overseen regulatory body, weather it is for them to clarify that this is not a valid interpretation of the law (it's at least clearly in conflict with the spirit of the law) and intentionally delaying public releases this way is a no-go or weather it is to amend the law to make it more explicitly illegal
either way if that is true it looks like a very intentional abuse/misinterpretation of existing regulations
What makes you think it’s misinterpretation?
FAQ https://ec.europa.eu/newsroom/dae/redirection/document/12233... [PDF]
https://digital-strategy.ec.europa.eu/en/policies/cra-manufa...
It's not a CRA obligation, but a rule from ecodesign requirements for smartphones (Reg. 2023/1670)
> 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.
Ecodesign is so nice! The vacuum energy reduction requirements that also introduced mandatory of suction power, aside from starting a market trend towards better suction, saved:
- 45 kWh per household per year
- 11.7 TWh of electricity in 2020 EU-wide
Literally just from better designed consumer vacuum cleaners.
https://energy-efficient-products.ec.europa.eu/product-list/...
How does that prevent them from releasing 17 QPR1 now given that 17 QPR1 is already released "by the operating system provider or on any other product of the same brand"?
The second part explicitly addresses this, Pixels getting QPR1 starts the timer.
QPR and security updates are different things.
My understanding is as follows: They're delaying source code releases for security updates, but they're privately sharing source and binary security updates with partners. Source releases are embargoed, binary releases aren't (I assume it's to avoid triggering the ecodesign clock)
When patches go out to partners in October, they are immediately released by GrapheneOS for users who opt-in for "security preview" releases. Stock Pixel users might get them in December (triggering the ecodesign clock), and other brands could get them as late as April (per ecodesign requirements).
So the timeline could look like:
June: Vulnerability discovered
September: Vulnerability patched
October: Source and binary patch sent to partners. Patch can now be reverse engineered and actively exploited.
October, shortly after: GrapheneOS releases an update with the binary patch
December: Vulnerability is officially part of the December bulletin, Pixel officially gets the update
January: Samsung releases the update
April: Everyone else (legal worst case)
QPR and security updates are different things.
Not completely. Android Security Bulletins only have fixes for vulnerabilities marked high/critical in resent years. To get all other security fixes, you need QPRs and major releases.
I didn't dispute that they're delaying source code releases for security patches, I only pointed out that these regulations can't explain why they choose not to publish QPR1/QPR3 while publishing QPR0/QPR2.
It's Cyber Resilience Act (Regulation (EU) 2024/2847) - if there's a security patch that shows up in public, then the manufacturers are fined if they don't immediately roll it out as an update ("without undue delay").
I think that's the one that made a lot of OEMs pull back on opensource publishing, because their legal departments want to batch the CVE monitoring and reporting obligations into smaller batches.
Aren’t most OEMs in violation anyway because Linux (as in the kernel) gets regular security patches and most OEMs are on ancient kernel versions?
Also, major Android releases and QPR2s have many security fixes (anything not marked high/critical), yet OEMs are not rolling them out (QPR2) or very late (major releases).
Just to say that OEMs were probably violating the act already before Google started withholding source code.
I also think it’s an attempt of Google closing up AOSP more, otherwise they wouldn’t make it so darn hard to get updated Pixel kernel trees.
I think it's mostly the "you need to monitor CVEs and write report within 24/72 hours" that causes OEMs pain and they prefer to have less work than more.
Also - the reality of what you think is ok and what a corporate legal department think its ok is... rarely the same -_-
This. CRA only means that you need to assess with 24/72h that you are affected or not by a published CVE.
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.
Law: please do the minimum to protect users. Corps: screaming
This reminds me of the OpenAI hack against Hugging Face.
Regulators present an impossible goal to the companies to implement, instead of implementing the goal, the companies try to reward hack their way around it.
The end result is that they basically try to make it impossible to know about vulnerabilities because that would start the clock.
But doing timely security updates is not impossible. Apple does it, GrapheneOS does it, Google does it with Pixel, Samsung is nearly doing it on flagships.
But many Android OEMs are probably terrible at software engineering and have their attention spread across multiple SoCs, etc. It’s their own fault.
> But doing timely security updates is not impossible. Apple does it, GrapheneOS does it, Google does it with Pixel, Samsung is nearly doing it on flagships.
What does "timely" here mean? A lot of security patches for all these companies take ~weeks+ to actually make it to customers due to things like QA testing, carrier testing and release processes.
The time between disclosure and release can be rather long, months even for all of them. (I'm counting private disclosure here.)
What does "timely" here mean? A lot of security patches for all these companies take ~weeks+ to actually make it to customers
Google has an embargo period of up to 6 months on AOSP patches. This is why GrapheneOS already has April 2027 AOSP security patches now. Even though some patches are already known for 6 months, they still manage to ship it 1-3 months late. 7-9 months after they got the patches already from Google.
due to things like QA testing, carrier testing and release processes.
Carrier testing is mostly a US thing. If you cannot roll out security patches within a few days, your QA and release processes are just totally broken. GrapheneOS can do it and they generally have far fewer regressions than Android OEMs.
Major releases and QPR2 take some time for testing, but they already have the access to sources months before they are released. Heck, Samsung releases major release betas and QPR2 betas quite a while before Google releases it as stable.
The problem is that the OEMs made a mess. First they just dropped phones on the market without doing any updates at all. Mid 2010s it was very normal for an OEM to do maybe one or two updates. Then Google had to push them to do better, among other reasons because Apple does much better and there were really big fails like Stagefright. Plus users wanted new Android releases. Then they did only 2-3 updates with very irregular software updates. Now they are under pressure from EU regulations and they actually have to support devices for a long time and do regular updates, but they just don't have good release processes. Plus they made their own 'skins' on top of it that they have to rebase, etc.
Companies that have their ducks in a row better, abuse the release process to push sales of new devices. E.g. Samsung withholds major/QPR releases for a while so that only their latest device have it, e.g. recently Fold 8/Flip 8.
People should stop beingapologists for multi-billion dollar companies.
I'm not sure what you're trying to say here - I've mostly said that for the corporations you highlighted, "timely" can still mean months for a given security patch to be deployed as things stand.
That's the reality - yes, even for Apple.
If you think they could and should be better - I guess I agree, but it doesn't change the reality.
Then they should leave it to others. Release specs and sources and let whoever wants, maintain the firmwares.
Ha ha ha, that'll take spyware to a whole new level. "You're running an old vulnerable version of Android, upgrade today to Android-45.123-robustdonut to get the latest security. Now with 100% genuine AI."
probably yes
withholding security updates seems to avoid a law which requires rolling out security updates seems very much like something which needs to be fixed one way or another
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
That’s not true; the only way to be found guilty following a CRA is to conceal the active exploitation of a vulnerability, fail to alert the national coordinator, fail to propose a mitigation within a reasonable timeframe, or be openly negligent in the management of the cybersecurity of one’s products.
“Please stop using this version of my product or this particular feature; it is vulnerable” is an acceptable mitigation measure.
A CVE isn't an active exploitation and don't trigger anything.
nit: "without undue delay" does not mean "immediately" under any legal interpretation, only that the timeline should not be longer than necessary. This leaves a lot of wiggle-room in favor of the manufacturer, and mainly rules out that they go "eh, we'll look at all these in half a year maybe".
As long as they start the process and it is not absurd from an industry standards perspective, they should be good. They can have slow processes, including being a good bit slower than their peers, without running afoul of "without undue delay".
They have literal 24 hour and 72 hour deadlines. Obviously, they might put a blind eye to it if you are reliable but delayed the reporting by a day, but the 24 hour and 72 hour deadlines are a fact. You have to initiate the reporting immediately.
You are mixing unrelated requirements together here.
> 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.
You are confusing two different articles. The 24-hour deadline relates to notifying the national Computer Security Incident Response Team in the event of the detection of a confirmed exploited vulnerability of one of the manufacturer’s products (Article 14). Submitting a bug report and opening a ticket does not constitute a confirmed exploitation in the wild. Nor does the publication of an exploit or a PoC constitute a confirmed exploitation of the vuln in the wild.
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.
This is impossible to happen.
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.
> nit: "without undue delay" does not mean "immediately" under any legal interpretation, only that the timeline should not be longer than necessary. This leaves a lot of wiggle-room in favor of the manufacturer, and mainly rules out that they go "eh, we'll look at all these in half a year maybe".
Well, the corporate lawyers think otherwise at those corporations, so I'm not sure how much your interpretation counts :)
I do not believe that any corporate lawyer would think that. It does not read like that in neither plain english nor legalese.
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.
These CRA provisions will be in effect from December 2027 onwards.
Google hasn't delayed pushing releases to AOSP but rather stopped pushing Pixel exclusive releases to AOSP. Android 17 QPR1 and Android 17 QPR3 are Pixel exclusive releases which won't be pushed to AOSP under the current policy. For 2/4 quarters per year, Pixels are on a major release of Android exclusive to Pixels and not released to AOSP. Non-Pixel devices don't get QPR1 or QPR3 releases. This is part of Google dropping support for Pixel devices from AOSP and giving them an artificial advantage over other Android devices.
See https://news.ycombinator.com/item?id=50112059 for a more detailed explanation.
If this is the case, I wonder why isn't Google publicly saying this. Because right now, it looks like they've stopped publishing the sources just because they felt like it, which has understandably generated a lot of backlash, but I feel like all the backlash would go away if they pointed at the EU regulations.
Why will they care what HN says about them? The people here don't like them anyway. They care what customers think, not developers.
Interesting theory. Is there a distinction between phone release and os release there? I would imagine the time starts when the model goes in sale, not when the os releases.
Otherwise I would expect Google would also wait with pixel updates
So it's the regulator's fault that a trillion dollar company is acting against the public interest? That's some unproven theory indeed.
This vicious European Union, which stifles innovation and works against the public interest – for example (checks his notes) by mandating USB-C charging and replaceable batteries!
I'm not disagreeing with you, and I don't understand the market.
But surely, unless the regulation is written in an especially thoughtless way, the clock would start at either the time the device manufacturer has access to the upstream fix, or the time that the manufacturer provides an update to any of their devices (which implies access to an upstream fix).
So public source release would only impose additional burden on device manufacturers if it is the first time that they are seeing the upstream fix.
Right?
This is such a bad excuse, if they've released the update on a single phone then the timer would have already started - why delay AOSP after that?
No, it's not. (source: used to work on Android at Google, and its as simple as it seems, more and more MBA-style management meant more and more didn't care, which meant it was more and more poorly resourced, until it was discovered by revealed preferences that no one cared, at least, no one cared enough to speak up)
> due to a recent EU regulation majorly backfiring
And why should a regulation in EU affect rest of the world. Or for that matter, any US regulation. The arrogance of these nations and the ignorance of tech companies is ruining the entire Internet.
Because making things everywhere compliant is cheaper than having both a non-EU and EU versions of software. See also: Brussels effect[0].
It's simple economics. The companies are also allowed to either do special versions to comply with local laws or even to pull out of the market. They just choose not to for reasons.
[0]: <https://en.wikipedia.org/wiki/Brussels_effect>
Sure, American courts ask for age verification, the entire world needs to comply now. Then people wonder why so much surveillance. You can’t see past Brussels effects, because ignorance.
One character: a plain compare loop. Correct.
Not surprisingly, I get slight hints of Claudism in the text.
AI "opening" the source of software is one of the best things I've seen going for it so far.
Oh, it’s 100% absolutely Claude. There are more tells than this.
At any rate, “developers are disassembling it to find bugs” sounds extreme, but this is something Claude will do almost spontaneously, in my experience. I ran into an issue last week where a library wasn’t doing what I expected, and asked Claude to sort out why; I came back a few minutes later to find Claude tearing apart the library’s disassembly to reveal a mismatch in struct sizes between the library’s expectations and my headers. And it did solve the bug!
Not just Claude. In my experience, almost any LLM running in Pi would rather go down rabbit holes than ask for clarification. I think the solution is to restrict what the LLM can do: If it keeps running into "permission denied" when trying to run disassemblers or read files in /lib64, then it's probably not doing what the user intended it to do.
But you're right, that report is definitely written by an LLM. Humans don't typically put parenthetical postmodifiers in headings ("Mechanism (from the shipped libc.so)"), but LLMs just love them too much.
LLMs can't help but leak details about your project into the bug too. When it started rambling about effects on Virtual Pinball or whatever it was, that was the ultimate giveaway. Completely unrelated to the bug, the fixer never needed to know, but to the LLM it's crucial data somehow.
Given they don't have the code, I think it's fair enough here. Sounds like with it, it would have been much easier to find.
Trusted Platform Computing in 3... 2... 1...
We are already there and it is called Play Integrity (meets STRONG integrity) and Google is trying to get apps to use it to shut out competitors. They are succeeding to some extend (see the Volkswagen and IKEA Smart Home apps as recent successes for Google).
Google should not be allowed to abuse its duopoly position in this way. I recommend EU citizens to report every case they are (potentially) affected by to the EU DMA team.
> see the Volkswagen and IKEA Smart Home apps as recent successes for Google
Someone should make a complaint about ePD violation in relation to those. I doubt it's "strictly necessary" for those applications to read that information (if they even fulfill the "at distance" requirement).
I think that the EU shall render this practice (and the equivalent from Apple) illegal, stating that every citizen has a right to modify their own device without consequences, and that consequences shall include also having apps not working.
But to me big tech succeeded also lobbying the EU like they already did in the US, in fact they violate multiple EU rules (GDPR, etc.) without facing any consequence, and when they try to announce they would do something at the other side of the ocean they treat us that they will double or triple tariffs so...
> stating that every citizen has a right to modify their own device without consequences, and that consequences shall include also having apps not working.
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.
iOS has its own Play Integrity equivalent with DeviceCheck (https://developer.apple.com/documentation/devicecheck) and banking apps on iOS use it widely just like on Android as well.
DeviceCheck is not about detecting if the device is jailbroken, it's about detecting if the app is being emulated or tampered with.
A distinction without a difference - the purpose is to verify that the device on which the app runs hasn't been tampered with (for Play Integrity or AppCheck) from OEM state.
That's not true. Jailbroken devices have been tampered with, but the Secure Enclave is still fully functional. Device Check is designed to catch non-genuine hardware or non-genuine app binaries, NOT tampered software.
Depends on the type of jailbreak
Hmm, you're right. It looks like some older devices were able to be jailbroken into a state where the Secure Enclave was in an untrusted state, so you couldn't use authentication, but the encrypted flash was still accessible as long as you didn't have a passcode set. I thought even that wouldn't work in an untrusted state, but it appears I was incorrect.
(I was reading recently about the SEP's behavior after a memory authentication failure -- it completely stops accepting requests until the processor is reset -- so I thought that applied to trusted boot violations as well. Seems not.)
I suppose that also explains why every time I open Settings, the Apple Pay section is missing for a moment before it shows up; the OS is apparently able to function without it. Interesting bit of trivia.
If AI is good enough to find RCE in google code, maybe it can crack TPM
This thinking never leads to anything good. We got to stand for our right before it's too late and everything requires hacking
Maybe the TPM developer should be checking this using AI?
This ideea haunts me in my nightmares.
Trusted computing is fine and even good only if the owner (the person/company that bought the device) is in control, but it's not the world we live in.
> owner (the person/company that bought the device)
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.
It could slow down progress.
Who beside the open source community develops new features if they can be easily copied?
Is your theory really that closed source software will just stop being developed? I can't find another way to read that, but you can't think Google is just going to give up and shut down, right?
"AI is going to lead to much less software being written" said no-one ever :)
Closed software publicly available. Internal closed software, sure.
But why invest time and money when your features get copied as soon as you publish it?
> But why invest time and money when your features get copied as soon as you publish it?
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.
Look at spaces where ripoffs/copying are already rampant like mobile games. The result is a slop avalanche, rending the whole space commercially unviable for anything other than the most bottom-of-the-barrel dark-pattern shitware laden with scam ads and spyware because users don't care and won't pay.
That may well be the future for most commercial software (and software engineers) as margins collapse and AI tokenomics moves more power from labor to capital.
You think open source never develops new features?
The only thing that made commercial software more innovative is most developers never had time to build and maintain a big open source project without support from their job. Now we have agents and it takes a lot less time to implement your ideas. That means slop filling up GitHub, but also that people who came up with good new features can make them real in their free time.
ReSkate is a good example, it's a project 90% coded by AI but the people working on it are passionate and most of them are experienced game modders. They know what made the old Skate games special and wanted to bring it back to the new one. Now it's better than vanilla Skate 4 and has tons of new features never seen in the OG trilogy. That project would never be possible without Claude taking care of the hard and boring RE work.
> Who beside the open source community develops new features if they can be easily copied?
But I guess they will also think twice if big companies can rip off the software with clean room AI implementation to circumvent the open source licenses
Only the "copyleft/copyright extremists" who want to exert their own form of control over others are going to worry, while everyone else just gets to work asking AI to do what they want, and possibly even getting paid to do so.
IMHO it's the best outcome.
AI's pretty good at copying features even when it's closed, or online.
Not perfect, of course. All that hype about the vibe-cloned Adobe suite is, today, hype. Next year it might not be, though that depends on questions like "will investment bubble pop?" etc.
But we are at a level where, if you can describe a feature or process well enough to test it, an LLM can develop and optimise for that feature/process. That creates opportunities for businesses to have custom just-for-them business software, which nobody copies because nobody outside the business even bothers to learn exist.
Why use proprietary software when there is opensource one ?
Some flavor of support/lifespan real or imagined.
The new Google motto seems to be "be as evil as you can".
We need an Android alternative, something that respects users' freedom.
Google is doing better here than Apple. Most google devices have an unlockable bootloader.
I have old Chromebooks and Nexus Tablets that are EoL, but I can install linux on them and give them a second life.
The source code for my old EoL pixel phones is out there, it's just a matter of effort to port Ubuntu or PureOS or one of the other Linux phone distros to them.
It's Apple that is being as evil as possible when it comes to stomping down alternatives, they don't release iOS source code, they bricked most of my old devices when they EoL'd them by not letting me unlock the bootloader and install my own OS, they don't release drivers.
I'm deeply unhappy with Google's current direction, but they're still lightyears from the level of evil Apple inflicts upon us.
> I'm deeply unhappy with Google's current direction, but they're still lightyears from the level of evil Apple inflicts upon us.
s/lightyears/5 years/
Tbf, Apple does in fact keep their ‘Apple OSS Distributions’ GitHub current.
This is the TiVo situation. Does open-source require allowing third parties to install their own software / OS and have unlimited control over the device? (GPL v3)
Or does it regard to access to the source code but not access to the device? (GPL v2)
TV’s, routers, IoT, etc vendors aren’t even allowed to ship devices with user-alterable software!
> Most google devices have an unlockable bootloader.
But that's not the case for other manufacturers, including ones way more popular than Google. Especially Samsung.
On average, a new Android device is almost as locked as iPhone is.
Yeah, while I am loathe to trust Google again, will never be buying another Apple hardware again too - I used an alternative map app on an old iDevice and wrote them a 5-star review for their good features, for being better than Apple and Google maps (in some aspects) and especially for still supporting older devices. A new update for the app was released and suddenly I couldn't install it because App Store reported that my ios was outdated and not compatible with the new release. So I revised the review for the app to 2-stars pointing out they had suddenly dropped support for older iDevices which was one of their main attractive features. The developers of the app contacted me asking me to reconsider the review. According to them, they had released the latest update for the app for the "outdated" ios version / older iDEvices too, but Apple deliberately sat on it without approving it for the App store. According to them, Apple hasn't clarified the issue. If the developers are being truthful (and I do believe them), this is a deliberate and malicious act by Apple to push planned obsolescence of older iDevices.
It’s 100% correct, but iPhone 6 came out in 2014, twelve years ago! That seems reasonable. Also, would an Android of similar vintage fare better?
As per september 2026: https://developer.apple.com/news/upcoming-requirements/
> but iPhone 6 came out in 2014, twelve years ago. That seems reasonable ...
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.
Typing this from a e/os/ phone.
Alternatives exist. They just need signifiant adoption.
They exist. But they don't support Android apps that are unfortunately necessary. For example, any phone without WhatsApp or banking apps support is dead on arrival in Europe.
WhatsApp and my banking apps work fine on GrapheneOS (and /e/OS).
Which is why /e/ OS and Graphene OS adoption is higher than projects such as PostmarketOS (now Nura) or Ubuntu Touch, even if they are already quite mature. I daily drove Ubuntu Touch for two years in 2019 and 2020, and it's the need of Signal which made me switch to /e/.
No WhatsApp would be a feature
I wish we would all live in such a beautiful world; unluckily, the real world is not as nice.
Sailfish OS devices have good support for running Android apps.
Once upon a time WhatsApp had a j2me client…
Though I see signal usage creeping upwards. Maybe just my circle
Couldn’t the EU pass a law to require e/os/ to support WhatsApp or vice verse?
The problem doesn't lie with e/OS/, nor any other alternative. Google locks down capabilities with "Play Integrity", effectively attestation for official Google approved operating systems only. If you aren't on the list you fail the checks, and apps (like banking apps) will fail to run.
But it’s banking apps that opt into that. It’s not like Google is saying you must use Play Integrity. It’s a feature that banking apps are more likely to use. The EU could require banks to make apps for other operating systems.
IIRC EU was the issue?
"EU Age Verification Project Mandates Hardware-Bound Attestation"[1]
[1]: https://www.reddit.com/r/Android/comments/1vds3jm/eu_age_ver...
Someone should get the EU to ban the EU from requiring age verification.
[dead]
How are /e/OS, GrapheneOS, or LineageOS alternatives?
Google can kill them in an instant, they need the AOSP source to survive.
Well the sources are open, Google cannot remove them. Google can stop to publish the new changes, but the current sources will stay open.
[dead]
There's already an alternative, it's called Linux.
Though, as the narcs are quick to point out, Android 'is' Linux.
So really, the alternative is proper GNU/Linux (or as I've recently taken to calling it...)
Android uses Linux but it has no consequences for users or developers. So this is practically irrelevant.
See also:
https://news.ycombinator.com/item?id=50057296
https://news.ycombinator.com/item?id=50060611
https://news.ycombinator.com/item?id=50060215
You've moved the goalposts from "Android isn't Linux" to "Android uses Linux but it has no consequences for users or developers."
I look forward to "Linux users and/or developers benefit from Android but..."
It really isn't, it more like Inferno would have replaced its kernel with the Linux kernel.
It is as close to GNU/Linux as Inferno was to UNIX System V.
Which is why Termux has to work around what is actually available as public APIs on the NDK.
It's still Linux, though, the same way Ubuntu is still Linux despite carrying custom patches and security frameworks.
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.
Ubuntu is GNU/Linux, you don't run Afterstep on Android via NDK, unless you rewrite X Windows or Wayland to run on top of OpenGL ES or Vulkan surface that is then hosted inside a AndroidView or JetpackCompose display surface.
Which is what Termux has to do, just like they have to call into specific Android services via JNI, as the NDK only exposes official NDK APIs, alongside the C and C++ standard libraries.
Related recent discussion: https://news.ycombinator.com/item?id=50051530
Yes, let's throw away a fully mature smartphone OS (AOSP) and replace it by something that does not even have proper app sandboxing. /s
The alternative are other AOSP-based OSes like GrapheneOS and Lineage. Once they are used widely enough and funded enough, they could fork AOSP when needed. In some sense they have already soft-forked in that they use major and QPR2 releases, but put a lot of patches on top to fix issues, improve security, etc.
GrapheneOS has an estimated 500,000 active installs now, apparently LineageOS has 1.4M active installs. Probably around two orders of magnitude more than traditional Linux desktop-based phones, which have been trying since, checking notes, Maemo in 2005?
Btw /e/ OS people have already shared that they were getting ready for a hard fork of AOSP looking at how Google is acting. But to be fair the challenge is more around the hardware support than the OS itself, so in the end it will be the chip makers which will decide which OS can run or not. If they go the AMD way then great, if they go the old nvidia way where even basic reclocking is impossible then we are screwed.
I would be surprised if they have the expertise and manpower to do that.
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.
I agree, nevertheless, Murena has 50 employees and is profitable as a company. Idk how much money lineage and Graphene have, hopefully the partnership with Motorola is going to provide them some funding.
> We need an Android alternative, something that respects users' freedom.
You can support independent Android development (for example, GrapheneOS)
It might become independent if they manage to fork it.
There is a mass market Android/iOS alternative, it's called HarmonyOS on 50 million devices. I expect that's not quite what you were hoping for though.
Harmony is just another closed-down ecosystem controlled by a single company. It's already worse than Android with its late source releases.
> We need an Android alternative, something that respects users' freedom.
The more successful Android alternative - iOS - that people love so much doesn't do any of that and it's apparently even more secure and earns even more money.
See post downbelow: https://news.ycombinator.com/item?id=50083579
So why? :)
It's the result of going public. Once a company even dips their toe in that water, it's over for any priority but one.
Isn't one of the main limitations to more open mobile platforms due to opaque drivers? The very recent trends in reverse engineering might provide some solutions to that.
sure if there are another corpo that want to funding it
Google hasn't delayed pushing releases to AOSP. There are 2 major releases of Android available for non-Pixel devices every year and those are pushed to AOSP on launch day. Android 17 and Android 17 QPR2 are the relevant releases for 2026.
Google removed Pixel support from AOSP with the release of Android 16. They did so by no longer pushing the device trees, kernel drivers, userspace drivers/HALs and Pixel exclusive releases. That means there are no longer device branches pushed to AOSP for the OS releases used by recently released devices or variations from the standard releases. The monthly and QPR1/QPR3 are now considered fully Pixel exclusive and no longer pushed to AOSP either. That's why this code isn't pushed to AOSP. The remaining non-Pixel-exclusive releases of Android are still pushed to AOSP at launch.
Google is abusing their control over Android to give Pixels inherent advantages over other Android devices. However, in doing so they've also harmed the value prospect of Pixels by taking away official AOSP support which has made it much harder to support Pixels for other operating systems and even for app developers.
Pixels are now on Pixel exclusive QPR1 and QPR3 branches for half the year without sources available. For the other half of the year, they're on the same major yearly and QPR2 branches as other devices. Android 17 QPR1 is the latest major release for Pixels but Android 17 is still the latest for non-Pixel devices. Android 17 QPR2 will be the latest for both in December 2026.
They're not pushing the monthly, QPR1 and QPR3 releases to AOSP with a delay but rather not at all since those are only for Pixels and AOSP doesn't support Pixels anymore.
We need a third option. Be it SalfishOS, Ubuntu Touch, Nura, or whatever picks up with a sizable community. We just need to start developing and investing in that one. It won't be perfect, but it will offer an alternative and control to the users.
There are plenty of alternative OS options. None are accepted by phone companies and shipped in orders of 100m devices worldwide.
Android has ~4b cumulative users, iOS 2.5b. Combined 1-2b phones are shipped annually, so phones are replaced over 3-6 years or so. Total production numbers of Sony PS2/Nintendo Switch are ~160m each, and there haven't been enough of those to be a viable alternative consumer platforms. China moves couple hundred million units per year of de-Googled phones internally(Google services are default banned in China except through Hong Kong VPN and such), and that doesn't seem to be changing situations much. Windows Phone was like few hundreds total.
The third option has to ship like 1000m - 1b units total and/or annually to be viable. Code quality... isn't going to matter, but it'll have to be literally 10-100x more popular than Nintendo. That is going to be the bar.
> That is going to be the bar.
The bar for what? The parent talks about the start. I already daily drive Librem 5 without waiting for "the bar".
It'd be mildly amusing if this led to someone doing an AI-powered decompilation of AOSP.
Given that previous versions of AOSP have source, it wouldn’t even be that difficult.
Yeah, you could get 95% of the way there with binary diffing
Just like with chimpanzees and us: it's an important 5%! No shade on chimps by the way.
Wouldn't it be better to start focusing energy onto projects like PostmarketOS (now Nura)? Sure the Linux phone space on the hardware side is a bit barren, but there are options and you don't really need top of the line specs to get something working; you could even use an SBC with a cellular modem peripheral to have a cellphone replacement.
Google not releasing won’t help now in the ai age….
Bit of a hyperbolistic title. The core of the bug report doesn't require disassembly of the library. The bug author just went the extra step to do a root cause investigation, which of course requires light reversing work.
If by "bug author" you mean Claude.
Given the current trajectory of all things, I think that the drawbacks will outweigh the benefits for a project like AOSP due to the changing economics. The reduction of SBOM (and therefore the attack surface) will be far more beneficial than the saving of work from hundreds of imported dependencies. The trend of vertical integration will likely happen in software sooner or later.
I wonder if they use already / what their experience is with "REA Reverse – Engineer Anything" (https://news.ycombinator.com/item?id=50028275).
Good look with NDK issues, having the source code available would not help much anyway.
NDK seems to be handled like a 20% project in terms of allocated resources, I bet it has not more that like 2 FTEs, given its progress since Android 2.1.
It's time to fork it
I wouldn't be surprised if Samsung or Xiaomi eventually forked to make their own "developed in the open" Android.
Though given how little those companies have respected their users so far, I feel like this is a bit of a monkey's paw.
What makes you think Samsung or Xiaomi care about a “developed in the open” Android? Do they even open source any of their flavors?
What about OpenHarmony?
OpenHarmony is hardly an Android fork (anymore).
In a way, it's similar to Samsung's Tizen, except Huawei's OS sees actual use, though not so much in the ecosystem of the USA of course.
An operating system from a convicted and blacklisted Chinese company? Thanks, but no thanks.
It's only blacklisted in US, afaik
Forking Android is not an option. Android is way too complex for any company or band of open-source developers to take up. The fork would quickly fall behind Google's implementation and become effectively useless.
It is not that complex, and now that AI has gotten good it's gotten even easier.
This is so wrong. First off Linux. Secondly even among Android competitors, HarmonyOS.
What maintained forks of Linux are there that actually do their own general improvements and maintenance besides just following along upstream with a custom driver or two? I'm even going easy and only referring to the kernel, even though "Android" is a lot more than that.
Harmony is no longer Android, and it's closed source
Even the big guns like Amazon can't afford keeping up with Google's speed.
8 out of the top 10 manufacturers are Chinese. Google has to be careful here, otherwise Android will end up as a Chinese consortium and their own version will just be available on Pixels.
But Western consumers at large won't buy Chinese devices if they don't carry the Play Store. And many Western app developers won't want to deal with Google Play Services and it's APIs missing, which is what made porting to Amazon's Android fork annoying as fuck.
That's the huge, huge carrot that Google carries in front of everyone thinking to fork Android.
They don't want to deal with Google Play Services missing because it's pretty rare to have a mainstream phone without it, as soon as the Chinese manufacturers pump out millions of devices without it in the western market all at once, the developers will have to follow.
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.
> as soon as the Chinese manufacturers pump out millions of devices without it in the western market all at once, the developers will have to follow.
I highly doubt that. People have far too much money already invested in Play Store purchases, that's a lot to give up for a marginally cheaper phone.
There's plenty of users who never spend anything at all on the Play Store, the various estimations I see online are about 15% of paying users.
Also, I don't necessarily think the phones will be marginally cheaper, just that the market will adapt.
Right, so the userbase is the true moat. Same stories as anything social.
Or China will migrate to Harmony and drop Android altogether.
Yes that's also a real possibility. The sanctions on Huawei were a terrible idea, it became a laboratory of what could be rolled out on the whole country if needed. Now this work has been done.
Sundar Pichai will need to take a class from Dario in open source fearmongering.
Remember when everyone was thinking of Google as a trustworthy partner in free and open-source software?
Man, the early '10s were wild, man.
AI is starting to successfully decompile binaries, unless the binary isn't purposefully obfuscated, I guess it's almost "open source".
Soon it will all be reverse engineered including all the proprietary binary blobs, and Google will not be able to do a thing about it.
corporate incentives turned into a laughing stock :p
See, that's the problem with proprietary firmware. HarmonyOS would have been better. They also do have tests for such cases.
Is it just me or Google has a lot of those silly bugs, where it seems nobody is thinking for 2 seconds on what they're actually doing?
just fork the android already, ffs
[flagged]
[flagged]
[flagged]
Fork them!
every generation of control freak eventually gets tired of Android as the features that actually have market traction get merged into iOS
just hang up the hat and never look back
At least for now, you can still install arbitrary APKs (after a 24-hour wait period). This alone still puts android leagues and bounds above iOS.
Even better, you can install your own AOSP-based OS that does not track you, will not have a 24 hour waiting period, etc.
That's device specific however. Pixels, yes, but say a Samsung device? Not any more - they nixed bootloader unlocking.
There are enough unpatched Linux exploits (known and unknown) running in the wild to make most phones rootable/flashable for years to come.
Same argument could be made for iOS though
Yes, but my point is even stock Android is superior than iOS for usability, obviously custom ROMs such as Graphene or even proper GNU/Linux phones would be superior to Stock Android for customizability.
On average, a new Android device is no longer unlockable.
You might as well say that the average smartphone is not unlockable because iPhones aren't. People who want the advantages of user control don't buy the average device. They buy the devices they can control.
You might, but the whole point in this thread was that Android is unlockable while iPhone isn't.
Both aren't.
You're reading their comment in a way that most people wouldn't and that the author clearly didn't intend. Android can be and is installed on lots of appliances that aren't meant to give users control, like refrigerators and many Samsung phones. It is also installed on devices that give users control (and can be installed on lther devices that give users control and don't install Android by default). That is the difference between it and iOS.
I would argue though that even Samsung phones give more user control than iOS phones (not that I would buy either one). Even though you can't install your own remix of Android, you can disable or remove most of what you don't like and install anything that targets the Android APIs.
You can install third party stores and apps on iOS without a waiting period (in places with decent consumer rights); confirming three popups is all you need to install third party iOS apps.
Unlike on Android, there aren't that many third party iOS apps, though.
Plus, even with Google delaying shipping source code, at least they ship the source code. The traces of source you get with the open Darwin code are nowhere near comparable.
> You can install third party stores and apps on iOS without a waiting period (in places with decent consumer rights)
Doesn't apple still "verify" (and can decide not to allow) those supposedly 3rd party applications?
It doesn't do app store reviews as far as I am aware. They do charge an installation fee (I'm baffled they haven't been sued over that yet), but there are free apps out there thanks to Epic covering that fee to spite Apple.
Seems that this €0,50 flat fee per installation has been replaced by a 5% commission on digital transaction made through sideloaded apps as of last August.
https://developer.apple.com/support/apps-in-the-eu/
You can also do that on iOS? You just need to sign the iOS app with e.g. your Apple account.
EU users can also add alternative app stores to their iOS device, e.g. Epic Games Store, AltStore, or some corn app.
Until iOS lets me run a web browser that isn't WebKit, without geographic restrictions, I'm not interested. It's an absurd restriction.
Being able to have a fully functional version of KDE Connect would also be a requirement.
iOS ain’t preventing that.
Check out Blink Chrome on iOS on Agelia developer Gyuyoung’s Weblog: https://blogs.igalia.com/gyuyoung/2024/08/08/chrome-ios-brow...
The Google has documented how to compile your own build. Note the ‘building blink for iOS’ section.
It’s as easy as adding ‘use_blink = true’ to ‘ [gn_args]’ in your ‘.setup-gn’: https://chromium.googlesource.com/chromium/src/+/main/docs/i...
It's fully your right to want non-webkit for your browser, but just curious. Why? Why does it matter? I've never once wished for firefox to use firefox's engine instead. The UI/sync/extension stuff is all built on top anyway.