Hacker News Reader

Comment by untog | Hacker News Reader

It's difficult. I like the idea of subresource integrity a lot, but a counter example: Twilio discovers a bug in their JS SDK. Without subresource integrity they can push up a fix and propagate it to all clients immediately. With subresource integrity they would need every client to update their web site to change the integrity attribute. If it was a serious bug then that could be a huge issue.

Even putting the security arguments aside you can bet a lot of customers would be really irritated having to constantly update this stuff on their site. If a competitor didn't have that restriction it would become a selling point. IMO the ideal is that Twilio provides both options: a "sdk-latest.js" that's a moving target, as well as "sdk-v1.3.js" that is frozen and can be locked with subresource integrity.

View on HN

What about an alternate for these 'platform script includes' like Twilio and Stripe:

    <script src="..." report-integrity="https://cdn.stripe.com/report">

in which clients compute the integrity and asynchronously ping a lightweight payload of the integrity to the third party? You would then seed your report service with a list of known hashes and set up alerting for when new hashes were observed.

Script tags (added programmatically) should support such errors via "onerror" functions. Though, I don't know if integrity errors could truly be determined. If they can then you can do whatever you want with such an error.

> Without subresource integrity they can push up a fix and propagate it to all clients immediately.

In reality, no you cannot.

You have multiple layers of cache between the S3 bucket and rendering, unless you disable caching entirely at a massive increased cost. Some of these caches are poorly behaving (e.g. intermediary caching).

The correct way of doing this ALREADY is to increment the version number in the URL (e.g. /3.1.0/My.Lib.js to /3.1.1/My.Lib.js) and to re-point the pages to use the updated library. This is reliably cache breaking, and will assure end users are getting the bug fixed version faster (or ever in some cases).

Once you're already doing it correctly, Subresource Integrity is a freebie. There's a reason why "sdk-latest.js" is largely dead concept from a bygone era: it is a huge anti-pattern and anti-feature.

Heck allowing upstream to blindly push you changes without being informed is nuts regardless. This argument is essentially: "I'm doing it wrong, and Subresource Integrity would stop that, so it is a non-starter." Without considering that what you're doing is bad practice before Subresource Integrity joined the party.

You do not have absolute certainty that every old cached version of a file you have published has been purged by every third party cache, no. But the vast, _vast_ majority do get purged very quickly. I've done this myself when in a bind many times and it's worked fine (and I've been able to verify that via error logging).

> There's a reason why "sdk-latest.js" is largely dead concept from a bygone era

Is it, though? From a quick check, it's what Google Maps does. It's what the Facebook SDK does. We already know it's what Twilio does.

> This argument is essentially: "I'm doing it wrong, and Subresource Integrity would stop that, so it is a non-starter."

Zero dispute with that characterisation from me. But it's how things already operate in the real world. I'll join you in shouting from the rooftops that people shouldn't be doing it, but that doesn't really get you any closer to actually stopping them. For a great many people the flexibility to quickly push up changes is a feature, not a bug.

> it's what Google Maps does.

Nope. Google Maps loads an uncachable JS file that itself points to version specific sub-files that are cache breaking.

> It's what the Facebook SDK does.

Nope, they have versions in the fbAsyncInit configuration.

> We already know it's what Twilio does.

Indeed, and if you want to copy a company that almost had a massive security problem then go right ahead.

>If it was a serious bug then that could be a huge issue.

Regardless of the severity of the bug, the only-case scenario is that all the sites you have pulling from that CDN break until you recompute the hash. How annoying this is scales directly to how frequently your libraries have to release vital security bugfixes.

> the only-case scenario is that all the sites you have pulling from that CDN break until you recompute the hash

Until you recompute the hash and communicate that new hash to them and they implement it on their site. It’s not nothing from an implementation point of view.

I'm not sure who "you" and "they" are in this scenario so I apologize if this isn't what you're getting at: the failure -> fallback -> threat evaluation-> remediation process can be entirely automated except the evaluation part. I'm not a web developer so I don't know the incidence rate of using unstable builds in production and having to patch stable builds, so maybe having to manually evaluate threats in this way /would/ be annoying, but the actual devops seems pretty trivial.

Reply on news.ycombinator.com