-
-
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
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
[1] https://github.com/w3c/webappsec-subresource-integrity/issue...
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
[1] https://github.com/w3c/webappsec-subresource-integrity/issue...