4 ms·

How many websites do you know that have implemented Subresource Integrity or CSP? These technologies are a pain in the ass and don't provide enough benefit to b

How many websites do you know that have implemented Subresource Integrity or CSP? These technologies are a pain in the ass and don't provide enough benefit to be worth it. If you're interested in pursuing something like this I think you really need to find a problem that is big and important enough for your average developer to agree that the cost is worth it. Being able to use insecure networks safely turned out to be important enough that we're making strides to TLS, though with a lot of struggle, what problem is as important as that for people to start thinking of doing this much work? And is there any way to scope it down to be less work? Maybe you could convince people that we need to sign ads so that it's not so trivial to deploy exploit kits inside ads, but we're largely solving that by making exploits more expensive, rather than solving ad integrity, so the gain on this is smaller than it would have been a decade ago.

tbiehn 9y ago
This is exactly my point - the available controls are not sufficient (plus immature). Providing a control that lets you create trusted client code lets you (comprehensively) cover the risk of code introduced 'after build time'. This would be obviously difficult to deploy - but it isn't without precedent, most clients (that aren't web) are already protected by signatures at build time, and orgs where that really matters (Signal, GPG, etc) get to pursue signing on air-gapped computers, with ceremonies and deterministic build processes. Preventing the implanting of client code has been deemed so important that even when updates go out over TLS, their signatures are double-checked by the recipient. I do not see how our use of the web-browser as a client becomes more trivial over time, it is clear that eventually the exposed capabilities, and desired use-cases, will eventually mandate assemblies verifiable in this manner.

tbiehn 9y ago

This is exactly my point - the available controls are not sufficient (plus immature). Providing a control that lets you create trusted client code lets you (comprehensively) cover the risk of code introduced 'after build time'. This would be obviously difficult to deploy - but it isn't without precedent, most clients (that aren't web) are already protected by signatures at build time, and orgs where that really matters (Signal, GPG, etc) get to pursue signing on air-gapped computers, with ceremonies and deterministic build processes. Preventing the implanting of client code has been deemed so important that even when updates go out over TLS, their signatures are double-checked by the recipient. I do not see how our use of the web-browser as a client becomes more trivial over time, it is clear that eventually the exposed capabilities, and desired use-cases, will eventually mandate assemblies verifiable in this manner.