Could you elaborate a bit on why you've judged it as privacy theatre? I'm skeptical but uninformed, and I believe Mullvad are taking a similar approach.
Mullvad is nothing like Apple. For apple devices:
- need real email and real phone number to even boot the device
- cannot disable telemetry
- app store apps only, even though many key privacy preserving apps are not available
- /etc/hosts are not your own, DNS control in general is extremely weak
- VPN apps on idevices have artificial holes
- can't change push notification provider
- can only use webkit for browsers, which lacks many important privacy preserving capabilities
- need to use an app you don't trust but want to sandbox it from your real information? Too bad, no way to do so.
- the source code is closed so Apple can claim X but do Y, you have no proof that you are secure or private
- without control of your OS you are subject to Apple complying with the government and pushing updates to serve them not you, which they are happy to do to make a buck
Mullvad requires nothing but an envelope with cash in it and a hash code and stores nothing. Apple owns you.
Agreed on most points but you can setup a pretty solid device wide DNS provider using configuration profiles. Similar to how iOS can be enrolled in work corporate MDM - but under your control.
Works great for me with NextDNS.
Orion browser - while also based on WebKit - is also awesome and has great built in Adblock and supposedly privacy respecting ideals.
Apple has records that you are installing that, probably putting you on a list.
And it works until it's made illegal in your country and removed from the app store. You have no guarantees that anything that works today will work tomorrow with Apple.
Apple is setting us up to be under a dictator's thumb one conversion at a time.
They transitioned from “nobody can read your data, not even Apple” to “Apple cannot read your data.” Think about what that change means. And even that is not always true.
They also were deceptive about iCloud encryption where they claimed that nobody but you can read your iCloud data. But then it came out after all their fanfare that if you do iCloud backups Apple CAN read your data. But they aren’t in a hurry to retract the lie they promoted.
Also if someone in another country messages you, if that country’s laws require that Apple provide the name, email, phone number, and content of the local users, guess what. Since they messaged you, now not only their name and information, but also your name and private information and message content is shared with that country’s government as well. By Apple. Do they tell you? No. Even if your own country respects privacy. Does Apple have a help article explaining this? No.
If you want to turn on full end-to-end encryption you can, if you want to share your pubkey so that people can't fake your identity on iMessage you can, and there's still a higher tier of security than that presumably for journalists and important people.
It's something a smart niece or nephew could handle in terms of managing risk, but the implications could mean getting locked out of your device which you might've been using as the doorway to everything, and Apple cannot help you.
>Also if someone in another country messages you, if that country’s laws require that Apple provide the name
I don't mean to sound like an Apple fanboy, but is this true just for SMS or iMessage as well? It's my understanding that for SMS, Apple is at the mercy of governments and service providers, while iMessage gives them some wiggle room.
Ancedotal, but when my messages were subpoenaed, it was only the SMS messages. US citizen fwiw
Because Apple makes privacy claims all the time, but all their software is closed source and it is very hard or impossible to verify any of their claims. Even if messages sent between iPhones are E2EE encrypted for example, the client apps and the operating system may be backdoored (and likely are).
All user data is E2E encrypted, so the government literally cannot force this. This has been the source of numerous disputes [0, 1] that either result in the device itself being cracked [0] (due to weak passwords or vulnerabilities in device-level protection) or governments attempting to ban E2E encryption altogether [1].
Maybe E2E, but the data eventually has to be decrypted to read it.
Then you learn that every modern CPU has a built-in backdoor, a dedicated processor core, running a closed-source operating system, with direct access to the entire system RAM, and network access. [a][b][c][d].
What you cited is for data on a device that was turned off. Not daily internet connected usage. No one is saying you have no protection at all with Apple, it is just very limited compared to what it should be by modern security best practices, and much worse than what can be achieved on android and linux.
If they didn't want you to think key escrow might be possible, why wouldn't they just leave the wording the way it was? Why go through the effort and thereby draw attention to it? The court system doesn't use sovcit rules where playful interpretation of wording can get a trillion dollar corporation out of a lawsuit or whatever.
Well, in the much longer term they have usually mentioned they would like to use a more secure/private foundation (more in the direction of Qubes/Redox/Fuchsia) with a compatibility layer for Android apps if they have the resources to do so.
Hopefully you don't mind me asking this question, but didn't you work with people who managed to do exactly what you are suggesting with a fairly small team at Essential for a few years?
This depends what you mean by 'issues with NFC'. My understanding is that Google require an OS that is blessed by them for contactless payments in Google Wallet to work. That restriction applies to all alternative operating systems that aren't Google certified stock Android.
The OEM partnership would not change that.
In non-NA regions there may be more options for mobile contactless payments using apps that are not Google Wallet/Pay. So it also depends where in the world you are.
It's inaccurate that GrapheneOS fully endorses Signal and Tor. The GrapheneOS founder was blocked by Moxie (when they were still leading the project) for criticising their approach. They have also warned countless times about the limitations and weaknesses of Tor.
Reducing waste is very important, but I think this is something you need to take up with the Android OEMs. GrapheneOS can't really do anything about the fact that Android OEMs stop supporting the device and allow vulnerabilities to go unaddressed. For context in this situation, GrapheneOS is also trying to provide a best-in-class privacy/security experience for people. There were other projects that are/were dedicated to supporting abandoned hardware.
A connected world full of devices with excessively vulnerable hardware & software is also something GrapheneOS are desperate to avoid.
I don't think that is a consideration for the project. Their OEM partnership also includes supporting a current generation Snapdragon SoC which seems to feature an integrated modem.
>A component being on a separate chip is orthogonal to whether it's isolated. In order to be isolated, the drivers need to treat it as untrusted. If it has DMA access, that needs to be contained via IOMMU and the driver needs to treat the shared memory as untrusted, as it would do with data received another way.
Hey, If they want to improve, they can always get a second chance. At least from me.
But I'm also quite happy with my Google Pixel 9 Pro XL and I have no reason to change. And unless Google changes their bootloader-stance in the future I might continue buying Pixels anyways. But its always good to have more options.
reply