4 ms·
> 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 applica
by afh1 2y ago
> 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).
- warkdarrior 2y agoE2E does not protect metadata, at least not without significant overheads and system redesigns. And metadata is as important as data in messaging and storage.
- afh1 2y ago> 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.
- mbauman 2y agoThe 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.
- fsflover 2y agoHow is this relevant to the private cloud storage?
- Jerrrrrrry 2y agoNo point in storing data if it is never shared with anyone else. Whom it is shared with can infer the intent of the data.
- fsflover 2y agoBackups?
- Jerrrrrrry 2y agoyes, got me there. but i feel in the context (communication/meta-data inference) that is missing the trees for the forest
- fsflover 2y agoOn the other hand, useful features should not be ignored, because other, almost unrelated things are hard.
- deleted 2y ago[deleted]
- godelski 2y ago> E2E(E) I assume you wanted the second E But no, this might not be enough. If you have full control over the device, especially at the hardware level, then you got nothing. The data has to go from “not encrypted” to “encrypted” at some point. Yes, this is best if it’s on device. Even better if it is encrypted on and in memory. But can you read it? If so, there’s access. You don’t need to break encryption if you get it before, after decryption, or can just read the screen. Security is not a binary thing. It’s not ever perfect. It is “make it really fucking hard to break or get around.” But if you can get it down to needing to infect the supply chain then you’re doing really good. Because at that point the governments are looking for it and are not going to allow those devices at least for themselves (yes, it’s the governments putting the stuff in but you know… there’s more than one government and devices don’t stay in one border…)
- halfcat 2y ago> ”that can be eliminated or at least mitigated with at least one verifiably trusted piece of equipment” What’s an example of how this would work? Are there people building their own network cards, motherboards, RAM, and CPUs from scratch, or how would one verify even a single component in the stack?