Aussie living in the San Francisco Bay Area.
Coding since 1998.
.NET Foundation member. C# fan
https://d.sb/
Mastodon: @dan@d.sb

  • 1 Post
  • 19 Comments
Joined 1 year ago
cake
Cake day: June 14th, 2023

help-circle







  • Yeah, it really depends on how much you trust the vendor.

    Google? Say what you want about the company, but they’ll never intentionally serve malware.

    Random company with no track record where we don’t even know who is maintaining the code? Much less trustworthy. The polyfill . io repo is currently owned by a Github user called “polyfillpolyfill” with no identifying information.

    Third-party CDNs make less sense these days though. A lot of hosting services have a CDN of some sort. Most sites have some sort of build process, and you usually bundle all your JS and CSS (both your code and third-party code, often as separate bundles) as part of that.






  • Reposting my comment from Github:

    A good reminder to be extremely careful loading scripts from a third-party CDN unless you trust the owner 100% (and even then, ownership can change over time, as shown here). You’re essentially giving the maintainer of that CDN full control of your site. Ideally, never do it, as it’s just begging for a supply chain attack. If you need polyfills for older browsers, host the JS yourself. :)

    If you really must load scripts from a third-party, use subresource integrity so that the browser refuses to load it if the hash changes. A broken site is better than a hacked one.


    And on the value of dynamic polyfills (which is what this service provides):

    Often it’s sufficient to just have two variants of your JS bundles, for example “very old browsers” (all the polyfills required by the oldest browser versions your product supports) and “somewhat new browsers” (just polyfills required for browsers released in the last year or so), which you can do with browserslist and caniuse-lite data.



  • tl;dr there were two leaks: A Microsoft employee had compiler issues and attached the code to a publicly-visible bug report, and Microsoft’s public symbol server had debug symbols for the library (which makes it a lot easier to reverse engineer and debug the production build in a debugger).

    Did the employee that accidentally leaked it think that the public developer community was an internal bug tracker? Strange. I wonder if Microsoft do actually use the same site for both internal and external bugs and the employee just selected the wrong category when posting. Seems like an unnecessary risk.


  • Are you sure the caching headers your server is sending for those images are correct? If your server is telling the client to not cache the images, it’ll hit the URL again every time.

    If the image at a particular URL will never change (for example, if your build system inserts a hash into the file name), you can use a far-future expires header to tell clients to cache it indefinitely (e.g. expires max in Nginx).