Earlier this week, I tried out a starter theme for a blog platform. The theme had loads of nice default features: pretty typography, fancy navigation, dark mode widget… and a couple of default trackers I really don’t want just sitting there in a header component, waiting for me to add my account information.
As web development has become increasingly complex, more starters, frameworks, and embeddable tools have been created to simplify our developer experience. Just paste this one line of code into the <head> of your site, and you’ll be a 10× full stack developer in no time. Sometimes we’ll pull out a feature we don’t want or the code we don’t need, but who has the time for a line-by-line review? If you got a feature for free, you might as well use it!
Over-simplifying our setup is risky. When we don’t fully understand what we’ve embedded on our site, we give up control of that feature to an unknown third party. We assume the maintainer knows best because the repository has a load of stars on GitHub or because a big name uses that same script on their site. Somebody must have checked this package is legit, right?
The malicious risk
Table of Contents
Malicious scripts for password jacking and other nefarious purposes are sometimes found in popular npm packages. Cryptojacking, where crypto miners are installed on your site without your knowledge, are more common. Just recently, Alibaba Cloud services were targeted to mine the Monero cryptocurrency. If we’re a customer of a hacked service, we might hope our provider lets us know if our site is hacked in a timely fashion. If it’s an open source package, we’ve just got to hope we’re online when someone discovers the vulnerability so we can get our sites updated quickly.
The reliability risk
Many third parties we rely on for critical features are just incompetent or unreliable. We make jokes when some big internet infrastructure goes down and leaves us with no choice but to take it easy at work, but it’s not all fun and games for sites providing vital utilities and information for people.
For many years, we’ve been sold on third-party solutions to improve performance issues on our sites. And, occasionally, you will find a service that genuinely serves your site faster and in more locations across the globe than you can throw together yourself. But the majority of the most popular sites on the web have way more than one third-party script embedded on their site. From my work on Better Blocker, I can tell you that around ten third-party scripts is low, and as many as thirty on one homepage is common, especially on news sites. Does that many third-party scripts on one page have a positive impact on performance?
The privacy risk
Whether or not the third-party feature we’ve installed on our site is nefarious, incompetent, unreliable, or does its job, it’s always a privacy risk for our site visitors.
In a world where developer experience is often the priority, it’s too easy to forget we’re using these tools to build experiences for other people. And we have a responsibility to build experiences that don’t put our site’s visitors at risk.
Any third-party script, or any resource that can log visitor information, can be considered a tracker. At best, it has tracker potential. Your analytics, fonts, iframes, content delivery networks, CAPTCHAs — they all have the potential to collect information about your site’s visitors. What information, how much, and how often depends on what the feature does and the access you’ve provided it. That information collected about an individual could be used to sell them ads, build sellable profiles of them or even be used to discriminate against them.
I know privacy isn’t a popular topic in the web community. It feels like we’re already near the bottom of the slippery slope… and sometimes it’s easier to give up than to address how reliant we are on privacy-exploiting funding models. But there are small changes we can make to protect our visitors, even if we simply start with our own personal projects.
1. Review the third-party tools you use
Do you really need two different analytics scripts on your site? Can you embed that font locally instead? Reviewing the tools you already use gives you a manageable way to improve the privacy of your project a little at a time. And you’ll get a bonus when your site’s performance improves.
2. Use privacy-respecting alternatives
Over the last few years, privacy-respecting alternatives to mainstream technology have become more popular. One of my favorite sites is switching.software, which helps you find alternatives to the popular tools you use every day. Good Reports is another one that explains the reasoning behind each recommendation.
Privacy isn’t as hard as giving up the defaults
In this post, I decided not to go into the legal issues around privacy on the web. Making sites that adhere to laws and regulations around respecting rights is essential, but we’re more likely to make great experiences for the people using our sites if we care about their privacy, rather than worrying about what we can get away with on the legal side.
Privacy is not as hard as giving up the defaults, the tools that save us time, or uncritically copying our colleagues’ approaches. But removing one tracker at a time, we can make a difference.
