Most active commenters
  • fsflover(5)
  • hnaccount_rng(3)

←back to thread

Private Cloud Compute Security Guide

(security.apple.com)
398 points djoldman | 18 comments | 06 Nov 24 13:48 UTC | HN request time: 1.78s | source | bottom
Show context
solarkraft ◴[06 Nov 24 15:40 UTC] No.42063965[source]▶
Sibling comments point out (and I believe, corrections are welcome) that all that theater is still no protection against Apple themselves, should they want to subvert the system in an organized way. They’re still fully in control. There is, for example, as far as I understand it, still plenty of attack surface for them to run different software than they say they do.

What they are doing by this is of course to make any kind of subversion a hell of a lot harder and I welcome that. It serves as a strong signal that they want to protect my data and I welcome that. To me this definitely makes them the most trusted AI vendor at the moment by far.

replies(13): >>42064235 #>>42064286 #>>42064293 #>>42064535 #>>42064716 #>>42066343 #>>42066619 #>>42067410 #>>42068246 #>>42069486 #>>42073933 #>>42078582 #>>42088020 #
1. patmorgan23 ◴[06 Nov 24 15:56 UTC] No.42064235[source]▶
Yep. If you don't trust apple with your data, don't buy a device that runs apples operating system
replies(4): >>42064785 #>>42066409 #>>42066447 #>>42070247 #
2. yndoendo ◴[06 Nov 24 16:32 UTC] No.42064785[source]▶
That is good in theory. Reality, anyone you engage with that uses an Apple device has leaked your content / information to Apple. High confidence that Apple could easily build profiles on people that do not use their devices via this indirect action of having to communicate with Apple devices owners.

That statement above also applies to Google. There is now way not prevent indirect data sharing with Apple or Google.

replies(3): >>42065011 #>>42065466 #>>42065965 #
3. hnaccount_rng ◴[06 Nov 24 16:44 UTC] No.42065011[source]▶
Yes, if your thread model includes the provider of your operating system, then you cannot win. It's really that simple. You fundamentally need to trust your operating system because it can just lie to you
replies(2): >>42067159 #>>42067843 #
4. dialup_sounds ◴[06 Nov 24 17:09 UTC] No.42065466[source]▶
Define "content / information".
5. afh1 ◴[06 Nov 24 17:37 UTC] No.42065965[source]▶
Depending on your social circle such exposure is not so hard to avoid. Maybe you cannot avoid it entirely but it may be low enough that it doesn't matter. I have older relatives with basically zero online presence.
6. isodev ◴[06 Nov 24 18:00 UTC] No.42066409[source]▶
That really is not a valid argument, since Apple have grown to be "the phone".

Also, many are unaware or unable to make the determination who or what will own their data before purchasing a device. One only accepts the privacy policy after one taps sign in... and is it really practical to expect people to do this by themselves when buying a phone? That's why regulation needs to step-in and enforce the right decisions are present by default.

7. mossTechnician ◴[06 Nov 24 18:02 UTC] No.42066447[source]▶
But if you don't trust Google with your data, you can buy a device that runs Google's operating system, from Google, and flash somebody else's operating system onto it.

Or, if you prefer, you can just look at Google's code and verify that the operating system you put on your phone is made with the code you looked at.

8. fsflover ◴[06 Nov 24 18:42 UTC] No.42067159{3}[source]▶
This is false. With FLOSS and reproducible builds, you can rely on the community for verification.
replies(2): >>42070042 #>>42074371 #
9. hulitu ◴[06 Nov 24 19:25 UTC] No.42067843{3}[source]▶
> You fundamentally need to trust your operating system because it can just lie to you

Trust us, we are liars. /s

10. philjohn ◴[06 Nov 24 21:51 UTC] No.42070042{4}[source]▶
Not unless your entire stack down to the bare silicon is also FLOSS, and the community is able to verify.

There is a lot of navel gazing in these comments about "the perfect solution", but we all know (or should know) that perfect is the enemy of good enough.

replies(2): >>42070272 #>>42074972 #
11. threeseed ◴[06 Nov 24 22:09 UTC] No.42070247[source]▶
And if you don't trust Apple with your data you shouldn't use a phone or internet at all.

Because as someone who has worked at a few telcos I can assure you that your phone and triangulated location data is stored, analysed and provided to intelligence agencies. And likewise this would be applying to ISPs.

12. threeseed ◴[06 Nov 24 22:10 UTC] No.42070272{5}[source]▶
We've seen countless examples of relatively minor libraries being exploited which then cause havoc because of a spider web of transitive dependencies.
replies(1): >>42074988 #
13. hnaccount_rng ◴[07 Nov 24 07:23 UTC] No.42074371{4}[source]▶
You really cannot. Both from a practical point of view. Does the thing really does what _you_ want it to do? A typical OS is much too complicated to verify this (and no theorem provers just move the problem).

But also from a theoretical point of view: I give you that the source does what you want it to do (again: unrealistic). Then you still need to verify that the software deployed is the software that builds reproducibly from the source. At the end of the day you do that by getting some string of bits from some safe place and compare it to a string of bits that your software hands you. That "your software" thing can just lie!

And yes you can make that more complicated (using crypto to sign things etc.), but that just increases the complexity of the believable lie. But if your thread model is "I do not trust my phone manufacturer" than this is enough. In practice that's never the thread model though.

replies(1): >>42074938 #
14. fsflover ◴[07 Nov 24 08:59 UTC] No.42074938{5}[source]▶
> does what you want it to do

What are you even talking about? We're talking about security, not 100% correctness, which is indeed not achievable. Security as in the software doesn't contain backdoors. This is much easier to verify, and even the very openness of the code will prevent many attempts at that.

Also, trust must not be 100%, as Apple is trying to train their gullible users. Oppenness is definitely not a silver bullet, but it makes backdoors less likely, thus increasing your security.

> you do [verification of reprodicible builds] by getting some string of bits from some safe place and compare it to a string of bits that your software hands you.

Exactly, and here's an example of how to do it reasonably (not perfectly!) well: https://www.qubes-os.org/security/verifying-signatures/

Also, please stop with the security nihilism: https://news.ycombinator.com/item?id=27897975

replies(1): >>42090602 #
15. fsflover ◴[07 Nov 24 09:04 UTC] No.42074972{5}[source]▶
> Not unless your entire stack down to the bare silicon is also FLOSS,

https://news.ycombinator.com/item?id=27897975

16. fsflover ◴[07 Nov 24 09:07 UTC] No.42074988{6}[source]▶
On Qubes OS (my daily driver), which runs everrything in VMs with strong, hardware virtualization, you can use minimal operating systems with very low number of installed libraries for security-critical actions: https://www.qubes-os.org/doc/templates/minimal/
17. hnaccount_rng ◴[08 Nov 24 21:26 UTC] No.42090602{6}[source]▶
The XZ backdoor was completely in the open. It only got found because an engineer at Microsoft was far too good at controlling his environment and had too much free time to track down a 1% performance degradation. So... no, you really cannot verify that there is no backdoor. Not against a well resourced, patient adversary.

I'm not sure what your links are supposed to be proving. I'm neither of the opinion, that PCC is useless, nor am I under the misconception that a signature would provide a guarantee of non-maliciousness. All I'm saying is that, if you include Apple as an adversary in your thread model, you should not trust PCC. But not because it's closed source (or whatever) but simply because you fundamentally cannot trust the hardware and software stack that Apple completely controls all interfaces to.

Personally I don't consider this a useful thread model. But people's situation does vary

replies(1): >>42093445 #
18. fsflover ◴[09 Nov 24 09:30 UTC] No.42093445{7}[source]▶
> signature would provide a guarantee of non-maliciousness

Nobody said that. A signature guarantees integrity and authorship.

> no, you really cannot verify that there is no backdoor

Again, nobody said that. I was talking about a lower probability to hide a backdoor and higher probability to find it in FLOSS.

> simply because you fundamentally cannot trust the hardware and software stack

Trust doesn't have to be binary (1 or 0). You can trust but verify.