5 ms·

> Often, security experts argue that the web isn’t suited for E2EE applications because of the vast attack surface for code injection – abusable by the develope

> Often, security experts argue that the web isn’t suited for E2EE applications because of the vast attack surface for code injection – abusable by the developer or by an external attacker. For many web applications, a web browser receives and runs code from a zillion servers, retrieved over a zillion TLS connections. This feels like the wrong argument. I don't think this has anything to do with suitability of end to end encryption. It is easily worked around with e.g. subresource integrity, or rolling your own signing scheme. The real problem with end to end security on the web is you don't have a trusted base. You have to bootstrap your application with some sort of trusted base. On a website you are redownloading the website everytime. The entire point of end to end encryption is that the service provider should not be able to intercept messages. The service provider is the attacker. This is impossible to prevent if you redownload the app everytime you open the page†. You have to build trust from some starting point. If you have some trusted bootstrap code you can build from there with signatures, but you can't build trust out of thin air running code directly supplied by the party you are trying to protect against. The problem isn't the zillion TLS servers. The problem is the first TLS server, which in the e2ee threat model we have to assume is evil. † i guess service workers can extend that to once every 24 hours. Still not super compelling.

JoshTriplett 3y ago
> It is easily worked around with e.g. subresource integrity, or rolling your own signing scheme. Or, you know, not loading resources from third parties in your secure web application.
saurik 3y ago
This is where IPFS can shine, as (if you don't use the very-optional IPNS) you are browsing directly to a fixed hash that your browser could (it doesn't, but this is trivially fixable) verify; it thereby exists in a space between pre-downloaded and web-requested software (with different tradeoffs, some positive and some negative; but like, all three of these options have negatives).
- bawolff 3y ago
  Yes, i agree, this is one of the most interesting aspects of content-addressable networks like IPFS.
ahazred8ta 3y ago
Subresource integrity hash checks are supposed to let you pin a particular version of a webpage / webapp, but the W3C managed to not let SRI work on bookmarks. If you could bookmark a specific version of a url with SRI, that would make so many problems go away. You can have a personal startpage saved on your device's local storage, with an SRI link to a webapp, but that takes a bit of fiddling. E2EE: https://hn.algolia.com/?dateRange=all&page=0&prefix=false&query=e2ee&sort=byDate&type=story https://hn.algolia.com/?dateRange=all&page=0&prefix=false&qu...
- jezek2 3y ago
  Perhaps bookmarklets could make that possible? It could generate loading of the resources using the SRIs hardcoded directly in the JS contained in the bookmark itself. Or even simpler, use the data: URI for the initial page as a bookmark.
  - bawolff 3y ago
    The data: url to bootstrap trust is a really cool idea. I like that. Of course then you are starting from a null origin, which makes certain traditional web architecture things hard. Maybe that doesn't matter if you design for it from the get-go. Too bad <iframe> doesn't support integrity. I guess you also sacrafice features that require a secure origin with this method.
- bawolff 3y ago
  > Subresource integrity hash checks are supposed to let you pin a particular version of a webpage / webapp I dont think that is true. Its called subresource integrity not resource integrity. I don't think pinning a specific top level resource was ever part of the goal. > but the W3C managed to not let SRI work on bookmarks. If you could bookmark a specific version of a url with SRI, that would make so many problems go away. I don't really think this makes sense in the context of how web browsers currently work. Are you proposing that users just unilateraly pin versions of websites?
  - ahazred8ta 3y ago

JoshTriplett 3y ago

> It is easily worked around with e.g. subresource integrity, or rolling your own signing scheme. Or, you know, not loading resources from third parties in your secure web application.

saurik 3y ago

This is where IPFS can shine, as (if you don't use the very-optional IPNS) you are browsing directly to a fixed hash that your browser could (it doesn't, but this is trivially fixable) verify; it thereby exists in a space between pre-downloaded and web-requested software (with different tradeoffs, some positive and some negative; but like, all three of these options have negatives).

bawolff 3y ago
Yes, i agree, this is one of the most interesting aspects of content-addressable networks like IPFS.

ahazred8ta 3y ago

Subresource integrity hash checks are supposed to let you pin a particular version of a webpage / webapp, but the W3C managed to not let SRI work on bookmarks. If you could bookmark a specific version of a url with SRI, that would make so many problems go away. You can have a personal startpage saved on your device's local storage, with an SRI link to a webapp, but that takes a bit of fiddling. E2EE: https://hn.algolia.com/?dateRange=all&page=0&prefix=false&query=e2ee&sort=byDate&type=story https://hn.algolia.com/?dateRange=all&page=0&prefix=false&qu...

jezek2 3y ago
Perhaps bookmarklets could make that possible? It could generate loading of the resources using the SRIs hardcoded directly in the JS contained in the bookmark itself. Or even simpler, use the data: URI for the initial page as a bookmark.
- bawolff 3y ago
  The data: url to bootstrap trust is a really cool idea. I like that. Of course then you are starting from a null origin, which makes certain traditional web architecture things hard. Maybe that doesn't matter if you design for it from the get-go. Too bad <iframe> doesn't support integrity. I guess you also sacrafice features that require a secure origin with this method.
bawolff 3y ago
> Subresource integrity hash checks are supposed to let you pin a particular version of a webpage / webapp I dont think that is true. Its called subresource integrity not resource integrity. I don't think pinning a specific top level resource was ever part of the goal. > but the W3C managed to not let SRI work on bookmarks. If you could bookmark a specific version of a url with SRI, that would make so many problems go away. I don't really think this makes sense in the context of how web browsers currently work. Are you proposing that users just unilateraly pin versions of websites?
- ahazred8ta 3y ago