I added a ublock rule on mobile to exclude this domain ||polyfill.io^ Any other practical steps that mobile users can take?
Might as well block googie-anaiytics.com while you're at it
Polyfill supply chain attack hits 100K+ sites
131–140 of 387 posts
Re: Polyfill supply chain attack hits 100K+ sites
#132Earlier quoted context omitted.
Vendoring should be the norm, not the special case. Something like this ought to be an essential part of all package managers, and I'm thinking here that the first ones should be the thousands of devs cluelessly using NPM around the world: https://go.dev/ref/mod#vendoring
We've seen a lot more attacks succeed because somebody has vendored an old vulnerable library than supply chain attacks. Doing vendoring badly is worse than relying on upstream. Vendoring is part of the solution, but it isn't the solution by itself.
Not alone, no. That's how CI bots help a lot, such as Dependabot.
Althought it's also worrying how we seemingly need more technologies on top of technologies just to keep a project alive. It used to be just including the system's patched header & libs, now we need extra bots surveying everything...
Maybe a linux-distro-style of community dependency management would make sense. Keep a small group of maintainers busy with security patches for basically everything, and as a downstream developer just install the versions they produce.
I can visualize the artwork..."Debian but for JS"
Re: Polyfill supply chain attack hits 100K+ sites
#133Earlier quoted context omitted.
I always prefer to self-host my dependencies, but as a developer who prefer to avoid an npm-based webpack/whatever build pipeline it's often WAY harder to do that than I'd like. If you are the developer of an open source JavaScript library, please take the time to offer a downloadable version of it that works without needing to run an "npm install" and then fish the right pieces out of the node_modules folder. jQuery…
This supply chain attack had nothing to do with npm afaict. The dependency in question seems to be (or claim to be) a lazy loader that determines browser support for various capabilities and selectively pulls in just the necessary polyfills; in theory this should make the frontend assets leaner. But the CDN used for the polyfills was injecting malicious code.
Sounds like a bad idea to me.
I would expect latency (network round trip time) to make this entire exercise worthless. Most polyfills are 1kb or less. Splitting polyfill code amongst a bunch of small subresources that are loaded from a 3rd party domain sounds like it would be a net loss to performance. Especially since your page won’t be interactive until those resources have downloaded.
Your page will almost certainly load faster if you just put those polyfills in your main js bundle. It’ll be simpler and more reliable too.
Re: Polyfill supply chain attack hits 100K+ sites
#134Earlier quoted context omitted.
Does it even reduce latency that much (unless you have already squeezed latency out of everything else that you can)? Presumably your backend at this point is not ultra optimized. If you send a link header and using http/2 the browser will download the js file while your backend is doing its thing. I'm doubtful that moving js to the edge would help that much in such a situation unless the client is on the literal oth…
I'm so glad to find some sane voices here! I mean, sure, if you're really serving a lot of traffic to Mombasa, akamai will reduce latency. You could also try to avoid multi megabyte downloads for a simple page.
Content: 50KB
Images: 1MB
Javascript: 35MB
Fonts: 200KB
Someone who is good at the internet please help me budget this. My bounce rate is dying.
Re: Polyfill supply chain attack hits 100K+ sites
#135Washington Post home page external content: app.launchdarkly.com cdn.brandmetrics.com chrt.fm clientstream.launchdarkly.com events.launchdarkly.com fastlane.rubiconproject.com fonts.gstatic.com g.3gl.net grid.bidswitch.net hbopenbid.pubmatic.com htlb.casalemedia.com ib.adnxs.com metrics.zeustechnology.com pixel.adsafeprotected.com podcast.washpostpodcasts.com podtrac.com redirect.washpostpodcasts.com rtb.openx.net sc…
Exactly why I have a whitelist
https://github.com/3052/blog/blob/main/2024-06/ublock-origin...
Re: Polyfill supply chain attack hits 100K+ sites
#136Maybe this will lead to everyone building their own stuffs. A pretty good outcome for SWEs, isn't it?
Re: Polyfill supply chain attack hits 100K+ sites
#137Earlier quoted context omitted.
It seems when proprietary resources get infected it's because hackers are the problem, but when open source resources get infected its a problem with open source. But there isn't any particular reason why a paid/proprietary host couldn't just as easily end up being taken over / sold to a party intending to inject malware. It happens all the time really.
agreed, but if a company is making millions for the security of software, the incentive is to keep it secure so customers stick with it. Remember the lastpass debacle, big leak and lost many customers...
Directly security-focused products like lastpass are the only things that have any market pressure whatsoever on this, and that's because they're niche products for which the security is the only value-add, marketed to explicitly security-conscious people and not insulated by a whole constellation of lock-in services. The relevant security threats for the overwhelming majority of people and organizations are breaches caused by the practices of organizations that face no such market pressure, including constant breaches of nonconsensually-harvested data, which aren't even subject to market pressures from their victims in the first place
Re: Polyfill supply chain attack hits 100K+ sites
#138Earlier quoted context omitted.
I always prefer to self-host my dependencies, but as a developer who prefer to avoid an npm-based webpack/whatever build pipeline it's often WAY harder to do that than I'd like. If you are the developer of an open source JavaScript library, please take the time to offer a downloadable version of it that works without needing to run an "npm install" and then fish the right pieces out of the node_modules folder. jQuery…
The assumption of many npm packages is that you have a bundler and I think rightly so because that leaves all options open regarding polyfilling, minification and actual bundling.
polyfilling and minification both belong on the ash heap of js development technologies.
Re: Polyfill supply chain attack hits 100K+ sites
#139Earlier quoted context omitted.
> I always prefer to self-host my dependencies Ime this has always been standard practice for production code at all the companies I've worked at and with as a SWE or PM - store dependencies within your own internal Artifactory, have it checked by a vuln scanner, and then called and deployed. That said, I came out of the Enterprise SaaS and Infra space so maybe workflows are different in B2C, but I didn't a differenc…
> I guess my question is why your employer or any other org would not follow the model above? Frankly, it's because many real-world products are pieced together by some ragtag group of bright people who have been made responsible for things they don't really know all that much about. The same thing that makes software engineering inviting to autodidacts and outsiders (no guild or license, pragmatic 'can you deliver'…
Yep. The philosophy most software seems to be written with is “poke it until it works locally, then ship it!”. Bugs are things you react to when your users complain. Not things you engineer out of your software, or proactively solve.
This works surprisingly well. It certainly makes it easier to get started in software. Well, so long as you don’t mind that most modern software performs terribly compared to what the computer is capable of. And suffers from reliability and security issues.
Re: Polyfill supply chain attack hits 100K+ sites
#140Earlier quoted context omitted.
The shared CDN model might have made sense back when browsers used a shared cache, but they dont even do that anymore. Static files are cheap to serve. Unless your site is getting hundreds of millions of page views, just plop the js file on your webserver. With HTTP/2 it will probably be almost the same speed if not faster than a cdn in practise.
Even when it "made sense" from a page load performance perspective, plenty of us knew it was a security and privacy vulnerability just waiting to be exploited. There was never really a compelling reason to use shared CDNs for most of the people I worked with, even among those obsessed with page load speeds.
In my experience, it was more about beating metrics in PageSpeed Insights and Pingdom, rather than actually thinking about the cost/risk ratio for end users. Often the people that were pushing for CDN usage were SEO/marketing people believing their website would rank higher for taking steps like these (rather than working with devs and having an open conversation about trade-offs, but maybe that's just my perspective from working in digital marketing agencies, rather than companies that took time to investigate all options).