4 ms·
1. The author is correct that the real purpose of E2EE, and the reason companies expend considerable R&D resources on it, is to have a plausible excuse not to p
by SheinhardtWigCo 3y ago
1. The author is correct that the real purpose of E2EE, and the reason companies expend considerable R&D resources on it, is to have a plausible excuse not to produce records; and to protect against malicious insiders. That's it. You don't have real "end-to-end" encryption unless you or someone you really trust has thoroughly audited the hardware and software stack. Obviously, almost no-one has the resources to do that.
2. The author's argument also applies to the App Store distribution model. Apple or Google may choose or be compelled to publish an app or OS update that is only visible to certain users. By default, iOS and Android install app updates without user approval. (You can and should, of course, disable that if you're concerned about such things.) The key difference is that app developers can't mount targeted attacks in this manner; only Apple and Google can.
3. Here's a simpler iteration on the author's idea for applying subresource integrity to service workers: an "immutable" variant of the https scheme that requires the lowest level of the domain to match a hash of all resources loaded on the page. JS is only enabled if the hash matches.
https+immutable://mhzwdnyyv5turofr8kkivabqyvamg7yteeitzwrg64o00taouw.signal.org
As far as I can tell, this mitigates the issues outlined by the author, and has the following nice properties:
- You can bookmark the URL and be certain that the code can't change in future.
- You can share the URL with someone else and be certain that they will be served the same code.
- Not affected by client-side state (e.g. cache) and thus can't be abused for fingerprinting.
- No risk of bricking the app in perpetuity.
- Thanks to Certificate Transparency, the existence of any published update is public knowledge.
- snowstormsun 3y ago3. Nice idea! But how will that prevent any pinned script from loading new code by making some request to the server of Eve (simple get request, for example) and running it using something like `eval`. The problem is that the pinned scripts would need to be thoroughly audited, which is hard to do for non-open source compiled/minified Javascript.
- SheinhardtWigCo 3y agoTrue, but that problem applies to "native" apps as well.
- ryan-c 3y ago> The author's argument also applies to the App Store distribution model. This is explicitly called out.
- SheinhardtWigCo 3y agoOops, good point, I missed that.
- kpdemetriou 3y agoRegarding #3, you'll need to load the immutable URL, perhaps indirectly, from someplace that ultimately has a user-facing URL. If an attacker can modify content in transit, then they can modify the content under the user-facing URL to bypass this scheme.
- SheinhardtWigCo 3y agoThe idea is that the immutable URL serves the entire app. Then if your threat model calls for it, you can bookmark the URL to "pin" that version of the app, or send the URL to someone else and be sure that they're getting served with the same code as you. Sort of like an onion URL.