TLDR Add built-in end-to-end encryption support into web browsers, and prevent first-party from leaking data by denying network access once enabled. Also, allow users to choose where their encrypted data should be stored (the web site publisher won’t be able to read data anyway, because of E2E encryption)
The idea is to offer a way for web apps to run in a kind of Trusted Execution Environment (without the hardware requirement), so that user data never leaves browser, and add synchronization mechanisms so that multi-device still work (see Trusted execution environment - Wikipedia for more about TEE)
wowwwwwwwwww my god! Dude! great idea!
Dropping a link to the post that generated this, which includes details on an implementation of something like this: Building websites that cannot read, exfiltrate, or store the data they operate on
I think there’s a greater discussion to be had on storage models and where data should physically live, along with how that data can then be leveraged by tools that display it in a useful way. At the beginning of the web, the browser was a dumb device that received HTML and remained content with that. Logically, all the storing, processing, and analyzing became server-work. It’s time we reconsider where some of that work should reside in order to limit who can see what data, while still providing a valuable service.
@pauwels I wrote something here - [Idea] Decentralized and distributed network of static content - html, css and js - #2 by raphaellouis - “cdn_p2p” - The goal is to load pages faster through a Content Delivery Network with Peer to Peer - in theory - all people receive and send content to people close to them anonymously, privately
- for companies that still think web 3.0 is bad initially, cdn-p2p can be a good solution as companies want their websites/platforms to be faster
- with cdn-p2p companies could have content faster with p2p
- in this cdn-p2p network it is important to have E2EE
- the big advantage of a cdn-p2p network for companies is that it reduces bandwidth consumption
- system efficiency increases with the number of concurrent users
- Natural scalability at peak demand
- Improved quality of experience for the end user (better video quality, less buffer pauses)
This is a great idea! I took a pretty quick glance at the proposal so sorry if I missed this. But if browsers were to implement this, wouldn’t it technically be possible for them to intercept data before encryption happens?
After all, this seems to move the responsibility of data encryption from web publishers to browser vendors. But many browsers don’t open source their code. How could we guarantee that pre-encrypted data isn’t being manipulated or stored somewhere else before encryption happens?
Thanks again for drafting this.
wouldn’t it technically be possible for them to intercept data before encryption happens?
Yes it is, but only by the web browser (actually, it should be the only part allowed to see data in clear while having network access)
How could we guarantee that pre-encrypted data isn’t being manipulated or stored somewhere else before encryption happens?
Thanks again for drafting this.
This draft is nothing without your support, thanks a lot
@Minigugus @pauwels @hamblingreg52 @mkay581 Hi all! A question is it possible to use the FIDO protocol and hardware keys through E2E in browsers?
I don’t think hardware keys where designed for that use case, but I don’t see why it couldn’t work: I guess browsers could generate a long random code, store it using the public key and ask the key to decode the generated code. Then browsers could use that code for AES encryption for instance.