Polyfill-service: Subresource Integrity

Created on 2 Oct 2015  路  7Comments  路  Source: Financial-Times/polyfill-service

Add support for Subresource Integrity on MDN.

I know it's a bit early, so see it more as a "future-todo".

Most helpful comment

I think I understand the what is being asked.

Subresource Integrity is a mechanism between the developer, the resource provider (like a CDN, like cdn.polyfill.io) and the browser. The browser does not run the script if the CDN does not provide the script that has the hash the author has provided as integrity attribute.
It could be useful for people relying on cdn.polyfill.io to be sure that the served scripts are the expected ones (polyfills) and don't contain any tracking or cookie stealing code (not accusing the FT of being malicious, but DNS poisoning or other MITM attacks can happen).

That being said there are several things that can be said:

  1. My understanding is that the author does not need to coordinate with the resource provider to generate the hashes, so there is nothing to "support" on the Financial-Times/polyfill-service side really
  2. The polyfill-service could provide the hashes in the docs so people can easily copy/paste in their HTMLs (sort of, see below)

But the FT providing the hashes comes with a massive drawback:

  1. The served code cannot be served any longer via the same URL if it changes (like if a polyfill is being fixed or another is added to the default set). This, in and of itself probably makes the idea of Subresource Integrity useless unless the polyfill-service is willing to change URLs for every change and support old URLs... ~forever (?)
  2. Financial-Times/polyfill-service sends a different content per User-Agent (and that's the point of the service), so for Subresource Integrity, website developers don't need a hash per URL, but per (URL, User-Agent) pair and they need to change the integrity attribute on a per UA basis, which becomes a ridiculous amount of work (unless they use the always flag or ua to have a stable script being served).

All in all, it looks like Subresource Integrity is a lot of work on all sides... to which point installing on your own server seems like a more reasonable solution to have a trustworthy service. It doesn't prevent the MITM, but your entire website is under attack then, so at this point, the integrity of the polyfills hosted on your server probably isn't the biggest problem.

All 7 comments

I'm not sure this is polyfillable. We can obviously ship implementations of the SHA algorithms, but is it possible to stop a browser loading and parsing a script that has been written into the markup?

i was not thinking about polyfilling SRI in itself - instead support the integrity attribute.

I'm not sure I understand what you mean, sorry. HTML5 parsers ignore all unknown attributes automatically so if we're not doing anything with the integrity attribute there should be no need to explicitly 'support' it...

I think I understand the what is being asked.

Subresource Integrity is a mechanism between the developer, the resource provider (like a CDN, like cdn.polyfill.io) and the browser. The browser does not run the script if the CDN does not provide the script that has the hash the author has provided as integrity attribute.
It could be useful for people relying on cdn.polyfill.io to be sure that the served scripts are the expected ones (polyfills) and don't contain any tracking or cookie stealing code (not accusing the FT of being malicious, but DNS poisoning or other MITM attacks can happen).

That being said there are several things that can be said:

  1. My understanding is that the author does not need to coordinate with the resource provider to generate the hashes, so there is nothing to "support" on the Financial-Times/polyfill-service side really
  2. The polyfill-service could provide the hashes in the docs so people can easily copy/paste in their HTMLs (sort of, see below)

But the FT providing the hashes comes with a massive drawback:

  1. The served code cannot be served any longer via the same URL if it changes (like if a polyfill is being fixed or another is added to the default set). This, in and of itself probably makes the idea of Subresource Integrity useless unless the polyfill-service is willing to change URLs for every change and support old URLs... ~forever (?)
  2. Financial-Times/polyfill-service sends a different content per User-Agent (and that's the point of the service), so for Subresource Integrity, website developers don't need a hash per URL, but per (URL, User-Agent) pair and they need to change the integrity attribute on a per UA basis, which becomes a ridiculous amount of work (unless they use the always flag or ua to have a stable script being served).

All in all, it looks like Subresource Integrity is a lot of work on all sides... to which point installing on your own server seems like a more reasonable solution to have a trustworthy service. It doesn't prevent the MITM, but your entire website is under attack then, so at this point, the integrity of the polyfills hosted on your server probably isn't the biggest problem.

Thanks David, that is really very helpful, and I'd agree with you.

Was this page helpful?
0 / 5 - 0 ratings