I’d like to tell you something not to do to make your website better. Don’t add any third-party scripts to your site.
That may sound extreme, but at one time it would’ve been common sense. On today’s modern web it sounds like advice from a tinfoil-hat-wearing conspiracy nut. But just because I’m paranoid doesn’t mean they’re not out to get your user’s data.
All I’m asking is that we treat third-party scripts like third-party cookies. They were a mistake.
Browsers are now beginning to block third-party cookies. Chrome is dragging its heels because the same company that makes the browser also runs an advertising business. But even they can’t resist the tide. Third-party cookies are used almost exclusively for tracking. That was never the plan.
In the beginning, there was no state on the web. A client requested a resource from a server. The server responded. Then they both promptly forgot about it. That made it hard to build shopping carts or log-ins. That’s why we got cookies.
In hindsight, cookies should’ve been limited to a same-origin policy from day one. That would’ve solved the problems of authentication and commerce without opening up a huge security hole that has been exploited to track people as they moved from one website to another. The web went from having no state to having too much.
Now that vulnerability is finally being closed. But only for cookies. I would love it if third-party JavaScript got the same treatment.
When you add any third-party file to your website—an image, a stylesheet, a font—it’s a potential vector for tracking. But third-party JavaScript files go one further. They can execute arbitrary code.
Just take a minute to consider the implications of that: any third-party script on your site is allowing someone else to execute code on your web pages. That’s astonishingly unsafe.
It gets better. One of the pieces of code that this invited intruder can execute is the ability to pull in other third-party scripts.
You might think there’s no harm in adding that one little analytics script. Or that one little Google Tag Manager snippet. It’s such a small piece of code, after all. But in doing that, you’ve handed over your keys to a stranger. And now they’re welcoming in all their shady acquaintances.
Request Map Generator is a great tool for visualizing the resources being loaded on any web page. Try pasting in the URL of an interesting article from a news outlet or magazine that someone sent you recently. Then marvel at the sheer size and number of third-party scripts that sneak in via one tiny script
element on the original page.
That’s why I recommend that the one thing people can do to make their website better is to not add third-party scripts.
Easier said than done, right? Especially if you’re working on a site that currently relies on third-party tracking for its business model. But that exploitative business model won’t change unless people like us are willing to engage in a campaign of passive resistance.
I know, I know. If you refuse to add that third-party script, your boss will probably say, “Fine, I’ll get someone else to do it. Also, you’re fired.”
This tactic will only work if everyone agrees to do what’s right. We need to have one another’s backs. We need to support one another. The way people support one another in the workplace is through a union.
So I think I’d like to change my answer to the question that’s been posed.
The one thing people can do to make their website better is to unionize.
I’m already sold on this, however i still use this wonderful service: https://polyfill.io
It’s a bit complicated to setup properly, and eventually it could profit from being shared with other websites using it.
For example it gives this website i made recently: https://piercan.fr/
Just curious: If you don’t want people using third-party javascript, then
Being able to analyze behavior to make improvements is crucial for any team. The best vendors for web analytics use Javascript, and so by default you have to load third-party Javascript if you want to do any sort of analysis.
So if such a thing is effectively required, then third-party javascript is required? If not, I would love to hear how to be able to analyze web data effectively without such services.
I love the appeal but I miss nuance:
Why limit this to third-party scripts; what about third-party code snippets, style sheets, images, videos, and other file types.
Why limit this to security and performance; what about accessibility, or technical (validation) and legal compliance (for example, with the GDPR).
What about the problems third-party solutions solve.
The reality seems to be that a) the Web has always made use of third-party embeds, and that b) third-party embeds have always been lacking (technical quality, transparency about use of data).
Personally, I believe one path is to demand more from embed code—make it easy to use, make it high quality, and make sure it’s frugal and transparent when it comes to the processing of data. (That’s one path.)
Yet as the Web has always been making use of third-party embeds, the solution to the various problems they bring may require nuance.
“That’s astonishingly unsafe.”
That’s true, provided you don’t know what is being referenced really does.
If you do, and you know how it functions, that’s fine, and we have tools like Subresource Integrity (SRI) to ensure that that code doesn’t change.
Also, if you’re worried about a 3rd party script pulling in another 3rd party script, we have Content Security Policies (CSP) to whitelist what we will accept being loaded in our page.
It is possible to use 3rd party code safely. It’s just hard.
All that said, broadly I agree with you – avoid third party scripts when you can.
With browsers performing “cache partioning” for privacy reasons, there’s no opportunity for a performance boost due to the browser cache having already been populated by another site.
And contacting a 3rd party’s domain typically involves a DNS lookup, TLS handshake, etc. – it can be pretty slow. Preconnect resource hints help, but only so far.
Personally, though, I think more unsafe is letting users – typically marketing – loose with GTM. I keep coming across sites where, late in the page load, theres suddenly a pile of junk pulled in by GTM.
https://andrewwburns.com/2019/06/03/why-i-dont-like-google-tag-manager/
A tracking script with subresource integrity is still a tracking script.
I’m surprised there is no mention of CSP, which is a great solution to this problem.