But Apple's position here is actually really wild: Apple claims to protect user privacy all the time. But they can't offer a product in a major jurisdiction that has actually meaningful privacy laws? Didn't they consider that while designing the product?
This is quite the contradiction.
Complying with complex privacy laws is surprisingly orthogonal to making a product with good privacy.
In another regulatory area (not privacy, but something more historically regulated) we ran into strange situations where complying with the letter of the law would require us to walk back things that we had done in a better way. The laws are not simple and they're not written by engineers or even people who understand what future product needs look like.
Tax laws are also quite easy, tax lawyers are only needed if you want to NOT pay what the country you're operating in is owed.
Privacy isn’t complex, compliance is.
> Tax laws are also quite easy
Yet audits are still a pain.
> tax lawyers are only needed if you want to NOT pay
This is nonsense. Tax lawyers are sometimes used to skirt the law. They’re much more often there to help prove you followed it.
There's entire industries of experts who work on these tasks, and they don't just work for people trying to skirt the rules. I've hired people for both tasks and the reason was specifically to comply.
NIST, MS, and the security community all recommend against forcing people to change their passwords on fixed intervals. They should only be changed when there is an indication they have been compromised.
PCI requirements demand mandatory 30 day rotation intervals on user passwords for users with administrative privileges, IORC. Something like that.
They haven’t kept up. So until they change the rules you can either be PCI compliant or implement the current best practice. Not both.
The best practice was to rotate your passwords, but we discovered that this led users to picking less secure and easier to remember passwords and patterns.
Once technology offered up solutions to problems like password managers and breach notifications, that recommendation changed.
PCI used to mandate password changes for in-scope accounts (meaning they have access to credit card flows). Now that MFA is widely deployed that requirement only remains for accounts that do not have a second factor for authentication.
If you were ahead of the curve and implemented strong password policies that did not conform the the PCI baseline, all you had to do was explain to the auditor why. Assuming what you were doing genuinely increased your security posture it would be approved.
> They haven’t kept up.
Other standards all used to recommend password rotation. Most have amended it to deprecate or even prohibit password rotation.
> Once technology offered up solutions to problems like password managers and breach notifications, that recommendation changed
It wasn’t just that.
The original recommendation for password expiration failed to take into account the human practices that resulted.
Everyone has worked in an office with passwords on post-it notes, or seen passwords numbered with sequentially incremented integers at the end. Password rotation isn’t merely a baseline level of assurance, it has a negative impact on security because of the effect it has on password hygiene. In practice, passwords that expire can be easily guessed by appending something to the end of the prior password. And they are more likely to be written down in plaintext.
Permanent, non-expiring passwords without MFA are stronger in practice than expiring passwords.
Someone has to understand the codes and how they might be applied to a specific project, and direct a project such that the outcome will comply.
Codes dont provide a blueprint for a house or a bridge. They stipulate features and properties that it must have. Design resides with the firm.
Maybe it's more because the privacy is largely marketing and helps with continuously shutting out competitors under the guise of privacy?
If they really cared about privacy, they would end-to-end encrypt iCloud backups [1] by default and not just when ADP is enabled, which only a small subset of users do. In fact, many technical people I know don't even realize that iCloud backups are not end-to-end encrypted. At any rate, this large hole opens a lot of data (including iMesssage) open to Apple, law enforcement, etc.
https://support.apple.com/en-us/102651
[1] And iCloud Drive, and photos, and notes, and voice memos, and wallet passes, and contacts, and reminders, and...
Ironically the gaps you point to are things they have had to do to appease the European Union.
They didn't pioneered it, they just brought it to the masses. Tor was here before the Private Relay, and most open source backup applications offer E2EE out-of-the-box.
If regulators suck at understanding tech, they are making poorly thought out laws for corporations just as much as they are for you.
Here's their argument in their own words: https://www.apple.com/newsroom/2026/06/due-to-dma-siri-ai-de...
Besides that, the law is the law and the DMA/DSA has been around for years. Why should they get an exception is one part of a duopoly?
Legally, maybe not, practically it becomes their problem.
The smartphone is probably the most sensitive device most people own. It knows your location always. It has your banking apps. Your password manager. Your instant messages, and social media chats, it knows whether you’re walking, or driving, or talking on the phone, and to whom.
Once Apple allows any other vendor to vacuum all of that intensively private information out of an iPhone, Apple becomes indirectly responsible for potentially massive privacy breaches.
That doesn't necessarily mean it's a bad idea from a competition point of view, but good ideas can be discussed w/ an honest view of the quite real downsides.
Apple was not the problem for rcs; the carriers are and were.
EU wants Apple to open 'Siri AI', with access to a personal context, open to other model/AI providers.
Apple says "We can't do this in a privacy preserving way".
You can definitely question what their true motivations are, but it seems pretty plausible that there is a moral case for this system to not be opened up to other providers who may do a worse job at privacy than Apple (especially when you are Apple and you trust yourself).
I think there is a place in these sorts of ecosystems for privileged players. If you buy an iPhone you implicitly must trust Apple to some degree.
Not sure this is the case. My understanding is what the EU wants is that users can use Siri AI or a third party AI service from, say, Anthropic or OpenAI, at the same level of capabilities, just as you can switch default browsers. It's not about the underlying LLM (that would be the huge privacy concern), it's about the product built on top. Of course how a third party AI gets its data from the device would need to be approved by the user and that third party AI provider would have to justify what it's doing with that personal data to the EU watchdogs, just as Apple would need to do.
The DMA isn't a privacy law. In this case, the DMA would appear to require Apple to open up all user data to any AI agent. That removes the ability to provide privacy protections.
You can argue Apple should do that, but you can't in the same breathe argue for privacy.
Lemma 2: you are obliged by other regulation to offer equal access to user data to third parties, so others can build equivalent functionality (DMA).
Lemma 3: malicious third parties will absolutely try to abuse the access and trick the user into sharing their data by all means possible. You will be held responsible in court of public opinion at minimum and legally at maximum if/when a malicious third party abuses said access.
This is a hard, possibly technically unsolvable problem no matter how much money you might have, because the root issue is not technical, it's the fact that you legally have to give third parties access and no way to control what they do with it - and as others have mentioned in the threads, it's exacerbated by the fact that the regulation doesn't say "this is okay and this is not", it is vague and judges things "by outcome", so you may spend all the time in the world implementing a solution you think will work, and then get hit by fines/lawsuits because the implementation is judged as not sufficient after the fact.
According to GDPR, the app developer is the "data controller" and thus ultimately responsible. Only in the case where Apple knowingly participated in unlawful behavior is it likely to be held accountable, and even then, in addition to the app developer. Obviously, if we are not talking about leaks from the actual App Store system (eg. Apple account logins and user data).
So while it sounds plausible, the legal framework is exactly not what you describe here — Apple can claim to want better protection for customers by not allowing third party apps, but EU rejects that (it can similarly extend to app store itself) and pushes for competitive landscape with DMA instead.
Couldn’t someone argue that they “knowingly participated“? Do you think they want that risk?
Nothing holds them from having designed this as an API that others can use where the user has permission toggles of what data they want to share with the LLM provider.
This would be unprecedented access to user data, enabling the most complete user profiling ever.
Ad companies, like Meta and Google, are going to spend huge amounts of money getting agents ready, because there will be a ridiculous amount of money behind all the data they're going slurp up, and the profiles they'll build for you.
Unless, Apple can figure out how to keep the leaches, that have consistently proven to be so, with court cases for receipts, at bay.
There is just this minor point that their own agent simply doesn't use it and goes directly to lower level interfaces nobody else gets access to: exactly the thing DMA was designed to stop.
2: You do that.
3: Since your platform collects no private information, they get nothing from you. If they collect private information on their own, it's their job to comply with GDPR.
What you should do in case (3) is ask the user for permission to allow the 3rd party access to private data on their device. It's their choice (not yours) to allow it or not.
The DMA and the GDPR are laws that at their core make each other more difficult. the stated outcome of the DMA - allowing any vendor/user full access to your device - is not easily supported when solving for privacy.
You gotta let people make their own choices.