I totally get the intention behind this and the final outcome is definitely a safer internet. It's also somewhat justified considering the author has mentioned they never controlled its domain, yet the library has been distributed through that domain, correct? This is a reflection of the extremely poor security practices in the web development world.
At the same time, there is a wrongness in Cloudflare being able to overwrite content and changing the 'truth'. I'm like that larry david gif, I just don't know how to process this.
One more thing to note, if you go to the polyfill repo, they've also mentioned they're using Cloudflare to distribute the library.
For me, this is why it makes sense: customers on Cloudflare signup (at least in part) for Cloudflare to protect them against attacks.
Cloudflare is all about changing the "truth". When your site is behind Cloudflare, they block many requests to your site. The lock in the browser can be lies. Cloudflare is decrypting that content - and if the site owner hasn't setup TLS between Cloudflare and the backend, it's being re-transmitted over the internet unencrypted. On paid plans, Cloudflare will compress images and swap in their version. Cloudflare will compress an uncompressed response before returning it. Cloudflare will take the HTML returned by your backend and obfuscate any email addresses in that HTML before sending it along to the browser.
Your server returns a page with evil-polyfill/bad.js and Cloudflare inspects the HTML and rewrites it to say good-polyfill/good.js
You might not want this behavior and you can shut it off in Cloudflare, but it seems like a reasonable default given that customers have signed up for a product meant to protect them against attacks. Cloudflare has never been about passing back the raw HTML it receives from the backend or passing along the raw requests it receives from browsers.
My question is when does cloudflare starts to inject ads into my content?
Is it “shots fired” situation?
Because you know bullies and other bad people start testing ground to see what they can get away with. That is why you slap them hard and quick on the first attempt right away so they see that they cannot fool around.
So I am asking can it be we have to say - well yeah technically they are right - but stop right there doing that and never do it again!
They could make terms that they don’t serve vulnerable things from their cache and it is up for the customer to update or fix it - but they shouldn’t overwrite stuff, period.
Who is the "we" here? If you're a Cloudflare customer, you're probably glad to have Cloudflare automatically defend your website against supply-chain attacks like this: after all, security is one of their selling points.
when does cloudflare starts to inject ads into my content
You content, as in, you the developer who is making a website, and has set up Cloudflare in front of your website? Presumably they wouldn't inject ads into your website, or else you'd stop using Cloudflare: just change the nameservers in DNS to point to someone else.
Cloudflare's primary raison d'être is messing with the response they serve to users - to perform caching, to inject CAPTCHAs when they detect a DDoS attack, etc.
If you don't trust Cloudflare to not abuse this to inject ads, stop using Cloudflare.
They can mess with response to make redirects/checks before my content is served, but my content is mine they should only cache it and that is it.
If they serve ads on their captcha or some redirect I'd say well it is not nice - but for me fundamental difference is messing with my content even in a good faith - send me a notification an email or stop serving my content if it is active malware but don't change it.
If you own a website and you really think this is a slippery slope, that it crosses some line in your sandpit, you can stop using Cloudflare.
But worrying about ad injection off the back of a legit good-guy action seems like an overreaction. They've always been able to alter the websites they serve. They do frequently to optimise and this seems like a very benign extension of that.
> At the same time, there is a wrongness in Cloudflare being able to overwrite content and changing the 'truth'.
This is one of the many features of Clouldflare though, that you can enable additional features that modify your website in various ways - whether it's image resizing or analytics or security scanning.
If you don't trust Cloudflare to deliver your website, then you shouldn't use Cloudflare.
I think GP’s point was more about the truth for the consumer of the site. As a user, I trust a site to deliver the content it intends to deliver. Of course this is just a trust by proxy with Cloudflare because you’re trusting the site’s judgment on who to trust. As a user of the site, it makes me just a little bit more uncomfortable knowing there’s another layer of indirect control over the content coming in.
Of course this is all just philosophical anyway. We’ve not even touched on external module usage.
That is what Cloudflare is doing. Using a Cloudflare security product intends on modifying the website it's proxying. Everyone involved in running the website - the original website owners and Cloudflare, intends for this to happen.
The one exception is Cloudflare turning this on by default for free 'customers', but hey, if you're not paying really what leg do you have to stand on?
Cloudflare can't just do this at will. This only applies to websites that have explicitly trusted Cloudflare with their TLS cert in order to protect themselves from cases exactly like this one.
Odd that github archived the repo claiming it contains malware. Was any of the malicious code even in the repo? I would guess it's only on the server they're serving the polyfill from, since it has very specific conditions for triggering.
Nobody tell him about the “Google Safe Browsing” censorship bloom filter list used by Firefox, Chrome, AND Safari.
Relevant today as ever given that the Supreme Court ruled that the 1A challenge to the executive branch asking big tech to censor doesn’t have standing to be ruled on.
Google has a big red button that can shut down any webpage on the internet for 99.9%+ of the web browsing public. There’s no bypass button in the UI like a TLS failure.
This is sort of exactly what cloudflare does, though. They host your content on their servers. They're serving a mirror of the original files from polyfill.io and browsers are getting the same original bytes. If it's a fact that pulling content from polyfill.io is a security issue, why wouldn't you want them to do this? The "truth" as you describe is a third party that you don't trust (who acquired a service you use from the original provider). The status quo is inherently bad. "We served your page for you, but without the injected code and with full compatibility" feels like an awfully nice thing for Cloudflare to do that they simply didn't need to do.
Cloudflare is rewriting the link on websites hosted on Cloudflare. I think it can be argued that those websites have in some sense opted in to some limited rewrites by Cloudflare? (Presumably they wouldn't be doing it unless their terms allowed it.)
"Contrary to what is stated on the polyfill.io website, Cloudflare has never recommended the polyfill.io service or authorized their use of Cloudflare’s name on their website. We have asked them to remove the false statement and they have, so far, ignored our requests. This is yet another warning sign that they cannot be trusted."
At the same time, there is a wrongness in Cloudflare being able to overwrite content and changing the 'truth'. I'm like that larry david gif, I just don't know how to process this.
One more thing to note, if you go to the polyfill repo, they've also mentioned they're using Cloudflare to distribute the library.
https://github.com/polyfillpolyfill/polyfill-service/commit/...