remember Lavabit [0]? will Apple choose to shut down rather than to comply [1]? if the government comes with a warrant, it will be with a gag order, and they will be compelled to silently update your phone to extract whatever the govt needs over the course of a few months.
[0] https://en.wikipedia.org/wiki/Lavabit
[1] https://en.wikipedia.org/wiki/Pen_register#Pen_Register_Act
https://en.wikipedia.org/wiki/FBI%E2%80%93Apple_encryption_d...
in this case it could have set a dangerous (and expensive) precedent for them.
that does not mean they will fight any and all requests.
Sure Apple could update your device to send all your photos unencrypted to them. They could also remotely turn on the mic and spy on all of us. They could also add key word detection to iMessage and flag law enforcement if you text out the wrong words.
I think everyone here understands what Apple could do. Which is why it’s a good thing that signs point to Apple not wanting their customer data. And why Apple refusing government orders that they feel violate their customers is unequivocally a good thing (even if they’re doing it for selfish reasons)
that e2e encryption by a third party does not give you privacy from the US government if that third party can remotely control or update your device and is subject to US laws. it is a direct reply to the assertion made in the GP: "The adversary is someone attacking the service provider, like a hacker or a government with a warrant, and getting access to Apple's storage of your data."
Apple will probably comply, just like I would probably comply rather than go to jail or suffer injury to myself or my loved ones. But I think it's fair to treat that as a distinct threat.
If only such a service existed.
If only …
Still with all that said:
>I disagree - the service provider should be considered an adversary and their service - and your tooling - should make it possible to obfuscate every single bit of data and metadata that you store there.
If you're using Apple devices at this point then I think they do unavoidably form some part of your core trust foundation. With current hardware Apple is everywhere in the stack right down to the CPU level, heck arguably below that since they have a special license with ARM and can implement their own custom extensions. If you really think they're an adversary to the point of doing custom backdoors explicitly going after you, then the hardware just can't be trusted.
It's not unreasonable though to look at both Apple's incentives and the state of American law at least and see distinctions between Apple being compelled (or hacked) to provide something they have passive access to on their side anyway vs being compelled to engage in non-consensual active work and feature development (or having that slipped in and make it into general deployment) on things that necessarily must go out to end user devices. The former is both bog standard warrant/subpoena territory and not inherently detectable outside of Apple and the government, since it doesn't directly involve the user as a party at all. The latter is very arguably illegal and provokes far more public response, and involves deploying in ways that make it far harder to keep concealed (and open up other avenues of challenge).
However, as with all things here, you can just email and discuss with a real person and we'll set you up the way you need to be set up wrt billing and pricing, etc.
This is now possible to achieve in AWS, for example.
https://aws.amazon.com/about-aws/whats-new/2022/11/aws-kms-e...
The adversary in this threat model isn't the service provider. The adversary is someone attacking the service provider, like a hacker or a government with a warrant, and getting access to Apple's storage of your data.
Now of course it's not impossible for such an adversary to also defeat other systems at Apple and get your data another way, for example by controlling Apple's ability to send over-the-air updates to Apple devices. But I think that is a sufficiently distinct threat that it's not worth dismissing solutions to the first threat. That would be like dismissing the importance of a web server storing passwords salted and hashed, since attackers could just use a totally different attack to bypass the web server's database access control. Another way to illustrate this might be to point out that attackers can physically coerce you to hand over data regardless of any security measures any service provider could possibly make, but that doesn't mean we should dismiss all such security measures.