4 ms·
It's great to hear that you want this added to browsers themselves, and you're right that browsers are more likely to implement such changes if you can show tha
by dane-pgp 5y ago
It's great to hear that you want this added to browsers themselves, and you're right that browsers are more likely to implement such changes if you can show that users are deliberately installing an extension to add the missing functionality.
There has been some discussion at the W3C about extending the SRI spec in this direction[0], but it seems they are reluctant to do that unless "multiple browser vendors" choose to implement something like this.[1] Hopefully the existence and adoption of this browser extension helps to solve that bootstrapping / Catch-22 problem.
As for usability, would it be sufficient to just adopt a TOFU model, where the browser pins the first key it sees for a domain? To prevent the risk of permanently bricking a site (if the key gets lost, or the host gets temporarily compromised) you could politely warn the user that the key has changed, or just show a different colour icon representing that the code is correctly signed with an unknown key.
[0] https://github.com/w3c/webappsec/issues/449 https://github.com/w3c/webappsec/issues/449
[1] https://github.com/w3c/webappsec-subresource-integrity/issues/85#issuecomment-570752283 https://github.com/w3c/webappsec-subresource-integrity/issue...
- elithrar 5y ago(Feel free to drop me an email - silverlock@cloudflare.com - if you want to chat more) We’re iterating on a standard for this - our current thinking is to use well-known URIs to publish both a public key (is the hash legit?) and hash endpoint URIs for clients to pull. The extension requirement is an “unfortunate” friction point due to needing a separate security context for hash verification. Doing this part natively will be the biggest adoption win.