3 ms·

Quick shout out to GuardScript which exists to help catch malicious 3rd party (or 1st party) javascript changes: https://www.guardscript.com/ https://www.guards

by cj 6y ago

Quick shout out to GuardScript which exists to help catch malicious 3rd party (or 1st party) javascript changes: https://www.guardscript.com/ https://www.guardscript.com/ It's a really simple service that fetches a list of script URLs that you provide, and notifies you with the before/after diff whenever the file changes. I found GuardScript through a Show HN a while ago (https://news.ycombinator.com/item?id=20265141 https://news.ycombinator.com/item?id=20265141) and have been very pleased with it.

jszymborski 6y ago
Isn't this kinda solved by Subresource Integrity (SRI)? https://developer.mozilla.org/en-US/docs/Web/Security/Subresource_Integrity https://developer.mozilla.org/en-US/docs/Web/Security/Subres...
- lozenge 6y ago
  Some sites use ad networks that prevent them from setting good SRI policies.
  - jaywalk 6y ago
    So you don't set the SRI on those scripts. Nothing about the Twilio script referenced by this article would prevent SRI from being applied.
- cj 6y ago
  Not really. For example, here is Stripe's script tag: <script src="https://js.stripe.com/v3/"></script> https://js.stripe.com/v3/"></script> SRI only works for static files whose contents never change. In this example, it would mean that Stripe could never push minor bug fixes to the SDK. The workaround would be to use static versioned files instead of a generic script URL (or self-host the script), so that the value of the SRI checksum never changes. Edit: In the case of Twilio, their docs say "By linking directly to our CDN in production, any patch-level (non-breaking) changes made to the SDK will automatically be applied [...]" meaning that if you link to Twilio's CDN, you can't expect the file to be static, and therefore can't use SRI.
kirillzubovsky 6y ago
What a great example of a company that figured out a way to put a utility layer on top of existing tools and monetize it. Thanks for sharing.

by cj 6y ago

jszymborski 6y ago

Isn't this kinda solved by Subresource Integrity (SRI)? https://developer.mozilla.org/en-US/docs/Web/Security/Subresource_Integrity https://developer.mozilla.org/en-US/docs/Web/Security/Subres...

lozenge 6y ago
Some sites use ad networks that prevent them from setting good SRI policies.
- jaywalk 6y ago
  So you don't set the SRI on those scripts. Nothing about the Twilio script referenced by this article would prevent SRI from being applied.
cj 6y ago
Not really. For example, here is Stripe's script tag: <script src="https://js.stripe.com/v3/"></script> https://js.stripe.com/v3/"></script> SRI only works for static files whose contents never change. In this example, it would mean that Stripe could never push minor bug fixes to the SDK. The workaround would be to use static versioned files instead of a generic script URL (or self-host the script), so that the value of the SRI checksum never changes. Edit: In the case of Twilio, their docs say "By linking directly to our CDN in production, any patch-level (non-breaking) changes made to the SDK will automatically be applied [...]" meaning that if you link to Twilio's CDN, you can't expect the file to be static, and therefore can't use SRI.

kirillzubovsky 6y ago

What a great example of a company that figured out a way to put a utility layer on top of existing tools and monetize it. Thanks for sharing.