Blog: How Tos

Top Tips For Internet Privacy

David Lodge 04 Apr 2014

In an attempt to prove that I can’t write two articles in a row about the same subject, I’m going to switch to talking about something that I’ve been a big advocate of for quite a few years: personal privacy on the Internet.

Thanks to EU regulations we are all warned when a website wants to use cookies to store persistent information about us, but does this help in all circumstances?

Please note, this article does not recommend the use of any hotel booking website, social media website or visiting town starting with an “S” and ending in “lough”.

A Bit of Background

About a year ago I was looking around for a hotel in some place in the country where there was a data centre and not much else, for the sake of argument, let’s just say that it was Slough. So I went to a popular hotel booking website and booked my rooms and then forgot about it. That is until I opened up Facebook a couple of hours later, and what did I see facing me in the advert column, I’ll show you:


So where in Dante’s nine circles did this come from? With its rather exact prediction of an impending visit to Diss erm… Slough.

Surely cookie requirements restrict by domain. How could Facebook track where I’m going?

Storing Stuff

Ever since the world wide web was little more than a vector for donkey porn and Star Trek, web sites have wanted to make life easier for themselves by tracking information about their visitors. The problem is that HTTP, the base protocol of the web, is essentially stateless: a request is made, a response is received, future requests shouldn’t impact on the primary request.

So the clever people at Netscape came up with the concept of the cookie, a little string that can be stored on your computer, either temporarily, or persistently and can send information back to the web server. Here’s an example of one from a site not a million miles from where you’re browsing now:

Set-Cookie: PHPSESSID=o5g4cajusjgt563hffecem4k62; path=/

This defines a Cookie called PHPSESSID. Now, the in-built security of cookies locks them to the originating domain. In the above case, only the original server will be sent the cookie by the web browser.

But, this wasn’t good enough for a lot of business and with the rise of rich media content (e.g. Flash, Java, Silverlight, HTML 5) the use of local shared objects came about and with some sneaky techniques it’s very hard to get rid of tracking information if the provider doesn’t want you to.

But, this still only refers to stuff being sent from the originating domain. Yes, and it’s mostly irrelevant to my previous problem, I just wanted to give an idea of the history behind the war, and how we’ve mostly lost it.

Enter Social Media

Social Media is everywhere nowadays and in many ways that’s a good thing, like everybody else I have a Facebook account and I use it for the same reason the rest of you do: having pointless arguments, making pithy comments, looking up that person you fancied at school, stalking your ex, etc. etc.

But it is no longer just a large list of people talking within the web site: it has spread out onto the web like that bottle of fizzy drink does that you accidentally dropped and when you’re wearing your best suit. Everywhere, including on this site we see buttons like this:


This button allows a simple mechanism for the user show their appreciation of something. Users like it because they can “talk” social media from within another site’s experience; web sites like it because it identifies a real person who may even have given the social media their real name.

But, for this to work, the originating site needs to give some control over to the social media site, usually by allowing the social media site to run some JavaScript, if we look at the source then we see this:

<html xmlns=”” xmlns:og=”” xmlns:fb=”” xml:lang=”en-GB” lang=”en-GB” class=”no-js intl-en_GB mvt-336 mvt-336-one-brand-price-color-enabled mvt-336-one-brand-font-enabled” >

This allows content and functionality to be linked to Facebook easily like:

<div id=”fb-root”>
<div class=”fb-like” data-href=”” data-width=”160″ data-colorscheme=”light” data-layout=”button_count” data-action=”like” data-show-faces=”false” data-send=”false”></div>

And, when the page is rendered this gets transferred into:


Now, the magical HTML tag there is the <iframe> – this is essentially loading up a bit of Facebook in the page of another site), which due to weaknesses in the same origin policy means that the iframe may be able to see some information from the parent page, such as the location (depending on the browser in use). Now Facebook can need see about your pressing need to visit the sights and sounds of Slough.

This wouldn’t be too bad if it was only one or two sites; then you could boycott them and everybody would be happy. No, these like and share icons are everywhere, each time reporting back to the social media site exactly what you like and then they can sell it to their real customers: the advertisers.

Protecting Yourself

So how do I stop these social media sites knowing about my love for Slough and my secret desires for Hammond organs every time I do a web search or buy something from online?

You can’t easily. I personally have a web browser on my home computer which is only used for Facebook and nothing else; it’s not perfect, there can still be tracking by IP address, but it’s a simple low tech solution that works for me.

You could try and use the privacy mode (aka pr0n mode) in most browsers, but this goes too far an offers no persistence of data which does not give a rounded user experience.

What is really needed, and my challenge to the browser makers is a middle option: a semi-private web browsing mode where only some data is recorded, i.e. I have a session just for Facebook and that cannot talk to sessions outside and outside sessions cannot talk to it, but Facebook data is persistent.