If you don't use HTTPS you are also forgoing the integrity check and not only the encryption. Any router standing between your users and your servers could inject anything into your code, html, etc.
If a site exists just to host resources protected with SRI then you can in principle use HTTP, the resource integrity protection will fire and so long as the main page's origin was genuine (e.g. protected with HTTPS) you come out OK...
But SRI isn't even implemented at all in Safari or IE. So, there's a good chance if you have Mac or Windows users they're screwed.
This really is a corner case, even if some day Safari and IE get SRI, you should always just use HTTPS to actually protect resources in flight. The purpose of SRI is more around not fully trusting a sub-resource you've intentionally linked not to be changed.
There is the possibility of corrupting the integrity of the application code in this way, but this doesn't void privacy thanks to the same origin policy. https://en.wikipedia.org/wiki/Same-origin_policy
If integrity of the application is violated the application is broken or defective. Fortunately the application is open source and so integrity violations can be easily verified. More fortunately still the application is a diff tool, so it can perform self validation across the wire by comparing the transmitted application code against the stored application code.
> Fortunately the application is open source and so integrity violations can be easily verified. More fortunately still the application is a diff tool, so it can perform self validation across the wire by comparing the transmitted application code against the stored application code.
It could, if you had any guarantee that the application code was not compromised the first time, and if you had a customized browser that responded to a navigation request by checking for and running the stored application code for th URL to decide whether or not to use the downloaded code. But that's not the way browsers normally work.
Furthermore, even if it was, the case of “A web application hooks into the web request lifecycle to guarantee that it's code can never be changed once first loaded and which stores all user data locally” is an unusual-enough case (if even possible to implement) that there is a good reason that the always-HTTPS crowd doesn't address it: it's simply not a case which has any real-world relevance. At that point, sure, you don't need HTTPS after the initial download, because you don't need web requests at all since you are effectively unconditionally throwing away the response in favor of locally stored code.
I may be misunderstanding but I don't believe the Same-origin policy will protect you there. You're browser wouldn't be able to tell whether the JS it's reading is the real one or the modified one. So it would be all "same origin" for it.
It won't stop a modified code from pushing data to anywhere in the web either.
> More fortunately still the application is a diff tool, so it can perform self validation
Yes, if the application has been loaded before but I feel like it would be a half-baked HSTS implementation.
tialaramex|7 years ago
https://developer.mozilla.org/en-US/docs/Web/Security/Subres...
If a site exists just to host resources protected with SRI then you can in principle use HTTP, the resource integrity protection will fire and so long as the main page's origin was genuine (e.g. protected with HTTPS) you come out OK...
But SRI isn't even implemented at all in Safari or IE. So, there's a good chance if you have Mac or Windows users they're screwed.
This really is a corner case, even if some day Safari and IE get SRI, you should always just use HTTPS to actually protect resources in flight. The purpose of SRI is more around not fully trusting a sub-resource you've intentionally linked not to be changed.
icebraining|7 years ago
austincheney|7 years ago
If integrity of the application is violated the application is broken or defective. Fortunately the application is open source and so integrity violations can be easily verified. More fortunately still the application is a diff tool, so it can perform self validation across the wire by comparing the transmitted application code against the stored application code.
dragonwriter|7 years ago
It could, if you had any guarantee that the application code was not compromised the first time, and if you had a customized browser that responded to a navigation request by checking for and running the stored application code for th URL to decide whether or not to use the downloaded code. But that's not the way browsers normally work.
Furthermore, even if it was, the case of “A web application hooks into the web request lifecycle to guarantee that it's code can never be changed once first loaded and which stores all user data locally” is an unusual-enough case (if even possible to implement) that there is a good reason that the always-HTTPS crowd doesn't address it: it's simply not a case which has any real-world relevance. At that point, sure, you don't need HTTPS after the initial download, because you don't need web requests at all since you are effectively unconditionally throwing away the response in favor of locally stored code.
skuzye|7 years ago
It won't stop a modified code from pushing data to anywhere in the web either.
> More fortunately still the application is a diff tool, so it can perform self validation
Yes, if the application has been loaded before but I feel like it would be a half-baked HSTS implementation.
Edit: it was too convoluted