Comments
234 total · 191 loaded
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.
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.
However changes like these are deeply unpopular as they get interpreted as moving more powers to "Brussels" by right wing media.
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?
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.
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 forget that the worst offender took its toys and went away not too long ago.
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.
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.
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.
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.
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...
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.
This is also an instance of a group using its power.
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.
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.
This is not true at all though. OEMs can release anything whenever they want.
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.
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.
either way if that is true it looks like a very intentional abuse/misinterpretation of existing regulations
https://digital-strategy.ec.europa.eu/en/policies/cra-manufa...
> 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.
Otherwise I would expect Google would also wait with pixel updates
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?
[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.
EDIT: I see that was already brought up multiple times when you posted about it 11 months ago.
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.
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.
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
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 many Android OEMs are probably terrible at software engineering and have their attention spread across multiple SoCs, etc. It’s their own fault.
Also - the reality of what you think is ok and what a corporate legal department think its ok is... rarely the same -_-
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.
“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.
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".
> The CRA requires manufacturers to notify actively exploited vulnerabilities and severe incidents having an impact on the security of their product with digital elements. They need to submit an early warning within 24 hours of becoming aware, and a full notification within 72 hours.
These deadlines are entirely unrelated to the availability of security fixes and delays in deliverying them.
The part that’s probably bothering Google is this:
> 6. Manufacturers shall, upon identifying a vulnerability in a component, including in an open source-component, which is integrated in the product with digital elements report the vulnerability to the person or entity manufacturing or maintaining the component, and address and remediate the vulnerability in accordance with the vulnerability handling requirements set out in Part II of Annex I. Where manufacturers have developed a software or hardware modification to address the vulnerability in that component, they shall share the relevant code or documentation with the person or entity manufacturing or maintaining the component, where appropriate in a machine-readable format.
To put it very simply, the CRA calls on all stakeholders to cooperate in reporting incidents and vulnerabilities, establishes a national coordination mechanism, and aims to address vulnerabilities swiftly in order to maintain essential services within the European Union.
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.
Well, the corporate lawyers think otherwise at those corporations, so I'm not sure how much your interpretation counts :)
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.
> 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.
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.
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.
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.
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!
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.
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.
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).
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...
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.
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.
Who beside the open source community develops new features if they can be easily copied?
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.
But why invest time and money when your features get copied as soon as you publish it?
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.
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
IMHO it's the best outcome.
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.
We need an Android alternative, something that respects users' freedom.
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.
s/lightyears/5 years/
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.
Alternatives exist. They just need signifiant adoption.
Though I see signal usage creeping upwards. Maybe just my circle
Google can kill them in an instant, they need the AOSP source to survive.
So really, the alternative is proper GNU/Linux (or as I've recently taken to calling it...)
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.
See also:
https://news.ycombinator.com/item?id=50057296
I look forward to "Linux users and/or developers benefit from Android but..."
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?
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.
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.
You can support independent Android development (for example, GrapheneOS)
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? :)
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.
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.
Though given how little those companies have respected their users so far, I feel like this is a bit of a monkey's paw.
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.
That's the huge, huge carrot that Google carries in front of everyone thinking to fork Android.
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.
Man, the early '10s were wild, man.
just hang up the hat and never look back
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.
Doesn't apple still "verify" (and can decide not to allow) those supposedly 3rd party applications?
Being able to have a fully functional version of KDE Connect would also be a requirement.