On the surface, CDNs (Content Delivery Networks) present a great way of speeding up the loading of websites.

Without a CDN, requests take longer for users that are far away network-wise, but not a lot longer if users are near the server (perhaps on the same continent). Here are some results about this site: Izmir (Turkey) is close to Romania and loads my page quickly (0.974 seconds), but Medellín (Colombia, South America) is quite slower (my page loads in a bit over 3 seconds).

This doesn't just have to do with the speed of light through fiber optic and/or electrons through copper, but also with the amount and performance of network devices along the way.

With a CDN, you rely on a company which has servers in many parts of the world, thereby reducing the time it takes to serve clients.

However, CDNs have quite the caveats, as we'll explore in this post.

Another practice that has similar impact is websites tracking their visitors using a third-party analytics site, which may be more convenient than using a self-hosted solution.

Privacy

The most important caveat is loss of privacy. When a website tells a browser to request a resource from a CDN, the CDN usually gets the referrer field as well. So, the CDN can see what IPs visit what other websites.

If you're particularly unlucky, the CDN partners with a data broker. Quote:

Google says the idea here is to “encourage the best practice of regularly distributing content originating from Cloud Platform out to the edge close to your end-users. Google provides a private, high-performance link between Cloud Platform and the CDN providers we work with, allowing your content to travel a low-latency, reliable route from our data centers out to your users.”

So, your search for a health insurance scheme, for instance, might result in personal health data disclosures.

This is a blatant violation of privacy, even more proof that the GDPR is a joke designed to give people cookie warnings (and a false sense of privacy). See my recent edit on my GDPR article.

Security

If a CDN gets hacked, which luckily hasn't happened too often, the users could get a malicious version of, say, a JS library. This can lead to arbitrary stealing of data, personal of financial.

A technique for validating such scripts has been developed, but it's an extra burden on a website developer.

Censorship

In addition to the surveillance introduced by these ubiquitous centralized middlemen, relying on their infrastructure introduces an extra point of failure in a website: namely, the website can be effectively and easily censored by the middleman.

CloudFlare admits and "recognizes" this power, and seems to even brag about it. Please don't give them more power.

What you can do as a user

It is important to know there are two kinds of CDNs:

  1. Content hosting; where the webmaster sends a website to a CDN to host on many servers; these are usually paid services, and there is not much you can do, if you want to see the site properly (since the CDN has the customer billing data, and the site won't serve you directly, you have to go through the CDN tracking you).
  2. "Generic" library hosting, like Bootstrap or various Javascript frameworks. These are noticeably missing from the Wikipedia article. These are available for "free" (as in, you pay with private data), via Google Hosted Libraries, cdnjs, jsDelivr, Microsoft AJAX CDN, jQuery CDN and so on (I won't link to them). These can be blocked more conveniently, because many sites work in spite of blocking surprisingly many scripts. And even if you do request them, stripping their referrer renders them relatively blind (they won't know which site asked for Bootstrap).

First of all, you should strip cross-origin referrers. Firefox in private mode tries to prevent this, and it might be effective against CDNs.

Firefox (or the more private IceCat) lets you configure it in regular browsing mode also, by setting network.http.referer.XOriginPolicy to 1 or 2, but I can't find a setting or a plugin I would trust for Chrome.

Second of all, stripping referrers still can't prevent an analytics script from encoding something before sending it home. To solve this, you can block third-party requests as well, with a tool I warmly recommend: uBlock Origin, but this might affect site functionality).

I usually use "hard" mode, and choose which 3rd-party resources to unblock (if any) the first time I visit any site (then click the "lock" icon if I want to save them). But for not-so-hardcore users, I recommend "medium" mode, in addition to the stripped referrer.

In uBlock's "medium" mode, CDNs still track you via images and CSS, if you don't strip it.


Using uBlock Origin's "advanced user" panel, one can block (red) or permit (green) requests:

uBlock Origin: interface crash course


Third, you can use Firefox (and therefore IceCat) to comfortably read pages without any CSS loaded; simply click the "Reader View" button which arranges everything for a magical experience:

Firefox Reader view; shortcut is Ctrl+Alt+R

What you can do as a site owner

It is simple to respect users' privacy: do not use any 3rd party resources. Host everything yourself: CSS, minified JS, and media.

Usually, the resource sizes are on the same order of magnitude as HTML pages anyway (at least CSS, JS, and typically-sized images). Sure, you'll get more requests, but you can cache the resources way longer than the HTML (for instance, my site asks your browser to cache them for a week).

As for advertising, a site owner can make old-fashioned deals with people who want to advertise, and can host the ads on the site itself, and not through a third-party ad platform. Admittedly, this is more difficult to do, if you rely on the income. But if you're catering to a privacy-savvy audience, they likely have ad blockers anyway.

I am proud that my website does not make unrequested external requests. The only external requests your browser might make are the Disqus ones, and only if you click on the "Load Disqus" button below, to see the comments. But very few people do that, and I am glad that I respected their wish!

Still, I'd love to hear more from you (if not through Disqus, then via plain e-mail)! What should I write about next?

Comments