Florian Maury on Nostr: All these web applications handling end-to-end encryption of user content (think ...
All these web applications handling end-to-end encryption of user content (think npub1zw2eyejauwya33lgxmqyhwmga5mk6uy6hxdw3232etpef7ktfmcsm32aln (npub1zw2…2aln), npub1ddth5ddtu2zp0rewcn5tjjq2znvr9tcw322ylk2ypf8g5thdm52s6p3lql (npub1ddt…3lql), or even Whatsapp web) have a common flaw: the user needs to trust the javascript sent by the web servers of the provider. This situation defeats the purpose of E2EE because the point of doing encryption in the user agent is precisely that the provider does not need to be trusted.
For some reason, signed javascript has never been a thing. No transparency program (like cosign), no key commitment, no nothing. Weird. Sad and weird.
The most frequent solutions to this problem is to not use web pages: publish a mobile app, a desktop client or a web browser extension.
I've been thinking about it for a while now, and the "solution" I came up with is to use IPFS.
IPFS uses content addressing, meaning the address of a file is a hash of the content of the file. Every time you request a specific address, you get the same file. If you store that address in your bookmarks, then you are sure that you are using a specific version of the web content. If that web content is a web application (frontend) and all resources referenced in that web application are either linked using IPFS content addresses or linked via the "traditional web" with SRI hashes, then you have an integrity-verified web application.
Put that IPFS content address in a transparency program, and you have a publicly auditable log of the javascript served by the providers.
So, my request to npub1ddth5ddtu2zp0rewcn5tjjq2znvr9tcw322ylk2ypf8g5thdm52s6p3lql (npub1ddt…3lql) and npub1zw2eyejauwya33lgxmqyhwmga5mk6uy6hxdw3232etpef7ktfmcsm32aln (npub1zw2…2aln) is: could you please publish your frontend on IPFS?
#javascript #cosign #e2ee #ipfs
For some reason, signed javascript has never been a thing. No transparency program (like cosign), no key commitment, no nothing. Weird. Sad and weird.
The most frequent solutions to this problem is to not use web pages: publish a mobile app, a desktop client or a web browser extension.
I've been thinking about it for a while now, and the "solution" I came up with is to use IPFS.
IPFS uses content addressing, meaning the address of a file is a hash of the content of the file. Every time you request a specific address, you get the same file. If you store that address in your bookmarks, then you are sure that you are using a specific version of the web content. If that web content is a web application (frontend) and all resources referenced in that web application are either linked using IPFS content addresses or linked via the "traditional web" with SRI hashes, then you have an integrity-verified web application.
Put that IPFS content address in a transparency program, and you have a publicly auditable log of the javascript served by the providers.
So, my request to npub1ddth5ddtu2zp0rewcn5tjjq2znvr9tcw322ylk2ypf8g5thdm52s6p3lql (npub1ddt…3lql) and npub1zw2eyejauwya33lgxmqyhwmga5mk6uy6hxdw3232etpef7ktfmcsm32aln (npub1zw2…2aln) is: could you please publish your frontend on IPFS?
#javascript #cosign #e2ee #ipfs