By the way, I'm not sure if the solution here it to bypass the proxy for assets with integrity checking enabled or to have the proxy not modify the content, but I figured I'd raise it and let you decide :-)

Thanks for reporting this issue. I can reproduce it.
This seems like a bug, not a security issue in Chrome so changing the issue type.

+jww@ to determine if this should be considered a bug v/s security bug.

Assigning to bengr@ for triage since I am OOO.

This isn't a security bug; it means that SRI-protected script will not run if processed by DataSaver, even when it should. It's a MitM proxy, and has the same effect as any other proxy out there on the internet.

DataSaver should do one of the following:

1. Do not modify integrity-checked assets (e.g. `<script integrity="...">` and `<style integrity="...">`.

2. Modify the integrity metadata of the page to match the result of the data-saving modifications.

3. Remove the `integrity` attribute from munged script.

I don't think any of the relevant code is in Chrome, however: I'm pretty sure that the server-side component is doing the munging before the client sees any of the data.

---

I'm not sure I consider this a "serious blow" to SRI. It makes SRI _over HTTP_ less useful, but SRI over HTTP is already ~useless. *shrug*

It's something proxies should fix to the extent possible, of course, but the most likely fix basically renders the integrity check moot.

I don't think it's a blow to SRI, it's working as intended. The script has been modified so should be blocked. I just think this is a potential point of failure for those using SRI that could be hard to track down. 

Agreed that SRI over http is kind of pointless but we should either require https in the spec or support SRI in proxies. As for the solution, it seems like stripping the integrity attribute would be best. Updating the value adds work for the proxy and if it can modify the script then the integrity is useless.

The one case we can't do anything about is a https page loading a http asset with integrity, but mixed content, so ¯\_(ツ)_/¯

This is working as intended. One should not be relying on SRI over HTTP, since one can never be sure whether there's an intermediary (like Data Saver) modifying the assets along the path.

In general, the Data Saver proxy tries to avoid modifying HTML, so modifying <script> tags is pretty much a non-starter. Even if we could do this, we don't always know the context in which a given .js or .css file is loaded -- for example, the HTML might not be proxied, or might be cached downstream from the proxy.

A site that cares about resource integrity should either (a) use Cache-Control: no-transform on such resources (hoping that any intermediaries will respect it), or (b) use HTTPS.

@scott: SRI over HTTP isn't pointless! What if there wasn't a mitm between myself and http://example.com, but there was one between myself and http://randomcdn.net?  SRI is still helpful in that regards.

It's also still helpful in the case of somebody on http://randomcdn.net maliciously modifying a resource I've included from there.

You're right, perhaps that statement was a little too broad for wider considerations. I was thinking more in this scenario with an active attacker able to intercept all traffic. There are still cases where it could offer some protection bit with the above issue, it does raise problems.

You could still use SRI on a site being accessed over HTTP as it is serving its purpose but you should expect people to come along breakages more than if they were to access the site via HTTPS if they turn out to use something like the Chrome Compression Proxy (which many users turn out to use and is restricted to HTTP).
SRI would still help out with resource verification but it will have downsides when using HTTP alongside it. Perhaps not exactly a bad thing as HTTP, as pointed out, is susceptible to the potentially malicious kind of MiTM.

As a workaround: if you are able to alter the file you are requesting, you could lay it out the file the way that the compression proxy does so that it could verify correctly (assuming the hash is based off of the file content and perhaps the URI used). Minifying the file content might do the job.

In addition to the potential workaround, you would then store the altered content somewhere where you wish to request it, get the SRI integrity hash and then use it alongside the altered/new file.

 Issue 660731  has been merged into this issue.

Looking at that merged issue I realised that there are still CDNs out there that provide links to assets over HTTP, such as: https://www.asp.net/ajax/cdn#jQuery_Releases_on_the_CDN_0

There are also wider considerations like sites that included HTTP versions of assets historically too. These can all potentially be broken by this bug. 

In response to #12, the workaround would work but requires the user to report the problem to site owner and for them to then debug and arrive at the conclusion that Data Saver is responsible, which isn't straightforward. I don't think we should create special cases for Data Saver, we need a wider solution to the problem, like not interfering with integrity checked assets to allow the security mechanism to work as intended. 

As for #9, I'm not sure I agree. "This is working as intended. One should not be relying on SRI over HTTP, since one can never be sure whether there's an intermediary (like Data Saver) modifying the assets along the path." Using SRI over HTTP is perfectly reasonable and fully supported. The use of SRI on HTTP pages is also mentioned in the spec: https://www.w3.org/TR/SRI/#security-considerations If we shouldn't be using SRI on HTTP pages then why is the browser enforcing it? It seems like we've created a 'trap' for sites to fall into. 

https://www.w3.org/TR/SRI/#non-secure-contexts-remain-non-secure

SRI on HTTP might not provide network protection, but the spec accurately notes that it still provides protection against local tampering of third party resources. I'd layer the risks of compromise as:

1) High - local MITM, e.g. Wi-Fi
2) Medium - CDN or resource host compromise, against which SRI protects even over HTTP from the origin.
3) Low - Deep MITM, e.g. between Google and the origin.

Case #1 is mitigated by Data Saver itself since Data Saver requires a TLS connection between Chrome and Google, so that leaves us with #2 and #3.

In that order, SRI over HTTP still mitigates a risk that outweighs the reason for which this bug appears to have been labeled as WontFix.

I'd say this was mislabeled. :) If the beef is with the spec, the spec offers protection in the interim while the web transitions to full HTTPS. There should be respect for the specification here at least in my mind.

After some discussion on Twitter a suggestion has been put forward that the browser should be sending a Cache-Control no-transform header on requests for assets that have SRI protection. This would prevent HTTP and/or HTTPS proxies from altering integrity checked files. 

The relevant rfc's i used as basis for the suggestion on twitter
https://tools.ietf.org/html/rfc7234#section-5.2.1.6
5.2.1.6.  no-transform
   The "no-transform" request directive indicates that an intermediary
   (whether or not it implements a cache) MUST NOT transform the
   payload, as defined in Section 5.7.2 of [RFC7230].

https://tools.ietf.org/html/rfc7230#section-5.7.2
5.7.2.  Transformations
   Some intermediaries include features for transforming messages and
   their payloads.  A proxy might, for example, convert between image
   formats in order to save cache space or to reduce the amount of
   traffic on a slow link. 

 Issue 672387  has been merged into this issue.

I had to remove SRI from a popular JavaScript build tool because we offer no configuration, and generating it by default turned out to be a bad choice since some websites would break.

As a result even users who only serve under HTTPS would not get this feature as we can't turn it on by default. So it seems like net negative for end user security even if intentions behind failing the check are good. 

Disclaimer: my opinion is lately irrelevant as I have very shallow understanding of this issue. 

Ref: https://github.com/facebookincubator/create-react-app/issues/1231#issuecomment-266314837