3 ms·

> 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 ca

> 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.

untog 6y ago
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.
- Someone1234 6y ago
  > 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.

untog 6y ago

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.

Someone1234 6y ago
> 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.