Improving the Trustworthiness of JavaScript on the Web
blog.cloudflare.com
Improving the Trustworthiness of JavaScript on the Web
1–10 of 39 posts
Re: Improving the Trustworthiness of JavaScript on the Web
#2This is really cool, and I'm excited to hear that it's making progress.
Binary transparency allows you to reason about the auditability of the JavaScript being delivered to your web browser. This is the first significant step towards a solution to the "JavaScript Cryptography Considered Harmful" blog post.
The remaining missing pieces here are, in my view, code signing and the corresponding notion of public key transparency.
Re: Improving the Trustworthiness of JavaScript on the Web
#3Ok (let's pretend I didn't see the word "blockchain" there), but none of this should interfere with browser extensions that need to modify the application code.
Re: Improving the Trustworthiness of JavaScript on the Web
#4Ok (let's pretend I didn't see the word "blockchain" there), but none of this should interfere with browser extensions that need to modify the application code.
EDIT: Disregard this comment. I think there was a technical issue on my computer. Keeping the original comment below.
-----
> let's pretend I didn't see the word "blockchain" there
There's nothing blockchain about this blog post.
I think this might be a rectangles vs squares thing. While it's true that all blockchains use chains of hashes (e.g., via Merkle trees), it's not true that all uses of append-only data structures are cryptocurrency.
See also: Certificate transparency.
Re: Improving the Trustworthiness of JavaScript on the Web
#5Ok (let's pretend I didn't see the word "blockchain" there), but none of this should interfere with browser extensions that need to modify the application code.
EDIT: Disregard this comment. I think there was a technical issue on my computer. Keeping the original comment below. ----- > let's pretend I didn't see the word "blockchain" there There's nothing blockchain about this blog post. I think this might be a rectangles vs squares thing. While it's true that all blockchains use chains of hashes (e.g., via Merkle trees), it's not true that all uses of append-only data struc…
They specifically suggest using a blockchain for Tor:
> A paranoid Tor user may not trust existing transparency services or witnesses, and there might not be any other trusted party with the resources to self-host these functionalities. For this use case, it may be reasonable to put the prefix tree on a blockchain somewhere. This makes the usual domain validation impossible (there’s no validator server to speak of), but this is fine for onion services. Since an onion address is just a public key, a signature is sufficient to prove ownership of the domain.
Re: Improving the Trustworthiness of JavaScript on the Web
#6Earlier quoted context omitted.
EDIT: Disregard this comment. I think there was a technical issue on my computer. Keeping the original comment below. ----- > let's pretend I didn't see the word "blockchain" there There's nothing blockchain about this blog post. I think this might be a rectangles vs squares thing. While it's true that all blockchains use chains of hashes (e.g., via Merkle trees), it's not true that all uses of append-only data struc…
They specifically suggest using a blockchain for Tor: > A paranoid Tor user may not trust existing transparency services or witnesses, and there might not be any other trusted party with the resources to self-host these functionalities. For this use case, it may be reasonable to put the prefix tree on a blockchain somewhere. This makes the usual domain validation impossible (there’s no validator server to speak of),…
Oh, weird. I didn't see that (and a subsequent Ctrl+F showed 0 results) but now it's showing up for me?
Re: Improving the Trustworthiness of JavaScript on the Web
#7[deleted]
Re: Improving the Trustworthiness of JavaScript on the Web
#8As a site owner, the best thing you can do for your users is to serve all your resources from a server you control. Serving javascript (or any resource) from a CDN was never a great idea and is pointless these days with browser domain isolation, you might as well just copy any third party .js in your build process.
I wrote a coincidently related rant post last week that didn't set the front page of HN on fire so I won't bother linking to it but the TL/DR is that a whole range of supply chain attacks just go away if you host the files yourself. Each third party you force your users to request from is an attack vector you don't control.
I get what this proposal is trying to achieve but it seems over complex. I would hate to have to integrate this into my build process.
Re: Improving the Trustworthiness of JavaScript on the Web
#9As a site owner, the best thing you can do for your users is to serve all your resources from a server you control. Serving javascript (or any resource) from a CDN was never a great idea and is pointless these days with browser domain isolation, you might as well just copy any third party .js in your build process. I wrote a coincidently related rant post last week that didn't set the front page of HN on fire so I wo…
You're right that, when your own server is trustworthy, fully self-hosting removes the need for SRI and integrity manifests. But in the case that your server is compromised, you lose all guarantees.
Transparency adds a mechanism to detect when your server has been compromised. Basically you just run a monitor on your own device occasionally (or use a third party service if you like), and you get an email notif whenever the site's manifest changes.
I agree it's far more work than just not doing transparency. But the guarantees are real and not something you get from any existing technology afaict.
Re: Improving the Trustworthiness of JavaScript on the Web
#10As a site owner, the best thing you can do for your users is to serve all your resources from a server you control. Serving javascript (or any resource) from a CDN was never a great idea and is pointless these days with browser domain isolation, you might as well just copy any third party .js in your build process. I wrote a coincidently related rant post last week that didn't set the front page of HN on fire so I wo…
You're right that, when your own server is trustworthy, fully self-hosting removes the need for SRI and integrity manifests. But in the case that your server is compromised, you lose all guarantees. Transparency adds a mechanism to detect when your server has been compromised. Basically you just run a monitor on your own device occasionally (or use a third party service if you like), and you get an email notif whenev…
If they want to make a proposal, they should have httpc://sha-256;... URLS which are essentially constant ones, same as SRI but for top-level domains.
Then we can really have security on the Web! Audit companies (even anonymous ones but with a good reputation) could vet certain hashes as being secure, and people and organizations could see a little padlock when M of N approved a new version.
As it is, we need an extension for that. Because SRI is only for subresource integrity. And it doesn't even work on HTML in iframes, which is a shame!