←back to thread

295 points djoldman | 2 comments | | HN request time: 0s | source
Show context
solarkraft ◴[] 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(10): >>42064235 #>>42064286 #>>42064293 #>>42064535 #>>42064716 #>>42066343 #>>42066619 #>>42067410 #>>42068246 #>>42069486 #
tw04 ◴[] No.42064286[source]
As soon as you start going down the rabbit hole of state sponsored supply chain alteration, you might as well just stop the conversation. There's literally NOTHING you can do to stop that specific attack vector.

History has shown, at least to date, Apple has been a good steward. They're as good a vendor to trust as anyone. Given a huge portion of their brand has been built on "we don't spy on you" - the second they do they lose all credibility, so they have a financial incentive to keep protecting your data.

replies(8): >>42065378 #>>42065849 #>>42065988 #>>42066649 #>>42067097 #>>42067858 #>>42068698 #>>42069588 #
afh1 ◴[] No.42065849[source]
> There's literally NOTHING you can do to stop that specific attack vector.

E2E. Might not be applicable for remote execution of AI payloads, but it is applicable for most everything else, from messaging to storage.

Even if the client hardware and/or software is also an actor in your threat model, that can be eliminated or at least mitigated with at least one verifiably trusted piece of equipment. Open hardware is an alternative, and some states build their entire hardware stack to eliminate such threats. If you have at least one trusted equipment mitigations are possible (e.g. external network filter).

replies(1): >>42066004 #
warkdarrior ◴[] No.42066004[source]
E2E does not protect metadata, at least not without significant overheads and system redesigns. And metadata is as important as data in messaging and storage.
replies(1): >>42066083 #
afh1 ◴[] No.42066083[source]
> And metadata is as important as data in messaging and storage.

Is it? I guess this really depends. For E2E storage (e.g. as offered by Proton with openpgpjs), what metadata would be of concern? File size? File type cannot be inferred, and file names could be encrypted if that's a threat in your model.

replies(2): >>42066793 #>>42067070 #
mbauman ◴[] No.42066793[source]
The most valuable "metadata" in this context is typically with whom you're communicating/collaborating and when and from where. It's so valuable it should just be called data.
replies(1): >>42066915 #
fsflover ◴[] No.42066915[source]
How is this relevant to the private cloud storage?
replies(1): >>42067399 #
Jerrrrrrry ◴[] No.42067399{3}[source]
No point in storing data if it is never shared with anyone else.

Whom it is shared with can infer the intent of the data.

replies(1): >>42069525 #
1. fsflover ◴[] No.42069525{4}[source]
Backups?
replies(1): >>42070331 #
2. Jerrrrrrry ◴[] No.42070331[source]
yes, got me there.

but i feel in the context (communication/meta-data inference) that is missing the trees for the forest