3 ms·

If you talk HTTPS to a given host, assuming that TLS has not been compromised and the host itself has not been compromised, you can trust the app published by t

If you talk HTTPS to a given host, assuming that TLS has not been compromised and the host itself has not been compromised, you can trust the app published by the developer to be correct. For stuff which is pulled in from other hosts which you don't control (e.g. CDNs), you can use subresource integrity: https://developer.mozilla.org/en-US/docs/Web/Security/Subresource_Integrity https://developer.mozilla.org/en-US/docs/Web/Security/Subres.... Agreed that it feels like there should be another mechanism to publish subresource integrity hashes for your own resources somewhere so that people can spot if your server or TLS gets compromised though (similar to CT). Sounds like someone else had the same idea at https://lists.w3.org/Archives/Public/public-webappsec/2014Jul/0062.html https://lists.w3.org/Archives/Public/public-webappsec/2014Ju... - I wonder why it didn't go anywhere? Meanwhile, if you don't want to trust TLS or the host which originates the code, then for now you're probably better off using a desktop app (e.g. electron, although that comes with a whole different attack surface) or a browser extension which can be distributed as signed code.

dane-pgp 7y ago
It makes sense to use SRI to control the subresources which get loaded, but there is a clever trick which can be done to ensure that an entire webapp uses a fixed bundle of code. The trick was discussed on Hacker News some time ago[1], but the basic idea is to use a bookmarklet (or saved local page) which contains a single <script> tag with an integrity hash baked into it. The loaded script (once the hash check passes) then acts as a bootloader for all the other resources that it pulls in, eval'ing them only if their hashes (or perhaps signatures) match a hardcoded list (or public key). Of course there are some UX issues with this, such as the location bar not containing an actual domain (and reassuring padlock), although it might be possible to fix this depending on how the proposed <portal> tag[2] interacts with SRI. Also, the process of creating the bookmarklet is more awkward than just clicking a link, and it may have to be repeated every time a new version of the webapp is released (or rather, when the new version has been audited by one or more trusted entities). [1] https://news.ycombinator.com/item?id=17776456 https://news.ycombinator.com/item?id=17776456 [2] https://web.dev/hands-on-portals/ https://web.dev/hands-on-portals/

dane-pgp 7y ago

It makes sense to use SRI to control the subresources which get loaded, but there is a clever trick which can be done to ensure that an entire webapp uses a fixed bundle of code. The trick was discussed on Hacker News some time ago[1], but the basic idea is to use a bookmarklet (or saved local page) which contains a single <script> tag with an integrity hash baked into it. The loaded script (once the hash check passes) then acts as a bootloader for all the other resources that it pulls in, eval'ing them only if their hashes (or perhaps signatures) match a hardcoded list (or public key). Of course there are some UX issues with this, such as the location bar not containing an actual domain (and reassuring padlock), although it might be possible to fix this depending on how the proposed <portal> tag[2] interacts with SRI. Also, the process of creating the bookmarklet is more awkward than just clicking a link, and it may have to be repeated every time a new version of the webapp is released (or rather, when the new version has been audited by one or more trusted entities). [1] https://news.ycombinator.com/item?id=17776456 https://news.ycombinator.com/item?id=17776456 [2] https://web.dev/hands-on-portals/ https://web.dev/hands-on-portals/