3PHealth Blog
Privacy: Do Not Track – Expressing a tracking privacy preference is harder than you think
Tuesday, February 28th, 2012
I’ve been reading through the actual Do Not Track spec (link). Section 4 is quite interesting, specifically as it relates to “the user hasn’t set a preference”. Here’s the current wording:
When enabled, a tracking preference is expressed as either:
- 1… This user prefers not to be tracked on the target site.
- 0… This user prefers to allow tracking on the target site.
If a tracking preference is not enabled, then no preference is expressed by this protocol. This means that no expression is sent for each of the following cases:
The user agent does not implement this protocol; or
The user agent does implement the protocol but the user has not yet enabled a preference.In the absence of regulatory, legal, or other requirements, servers may interpret the lack of an expressed tracking preference as they find most appropriate for the given user, particularly when considered in light of the user’s privacy expectations and cultural circumstances. Likewise, servers might make use of other preference information outside the scope of this protocol, such as site-specific user preferences or third-party registration services, to inform or adjust their behavior when no explicit preference is expressed via this protocol.
Here’s where things get interesting. How do I set a preference of “0”?
I just tested this with the latest version of Firefox which supports the protocol. So I turned on “Do Not Track” and sure enough I can see the HTTP_DNT=”1″ header field showing up at our Web site. So then I turned it off (unchecked the box) and checked the incoming headers. Guess what? There’s no HTTP_DNT=”0″. The browser supports the protocol so there should be a way to send that header.
So lets look to the spec to see the answer. I’ve unchecked the box so then i’m indicating that no preference is expressed (this is NOT the same as a 0). This means that no expression is sent for the following cases:
- The browser doesn’t support the protocol (this is for older browsers) but in my case it does
- The browser does implement the protocol (it does) but I haven’t “enabled” the preference yet
So how do you know which of the above two cases it is? Well the usual answer is “JavaScript” as in, write some code that I can send to the device to determine if the browser supports what I need. And here comes the next problem – what if the browser user has turned off use JavaScript (quite a few do), what if the browser doesn’t support the necessary calls to determine if it can or it can’t support the protocol (Mobile browsers come to mind)?
A stunning amount of code and bandwidth will have to be written and used, to determine something that should be there in the first place. The browser does support it and it’s currently unchecked, which means that the browser sends HTTP_DNT=”0″. In the absence of either a 1 or a 0 you only have one case left. The browser doesn’t support the protocol.
Summary:
- For browsers that do support the protocol there are two conditions
- The box is unchecked – the browser sends HTTP_DNT=”0″ – I want to be tracked
- The box is checked – the browser sends HTTP_DNT=”1″ – I don’t want to be tracked
- For browsers that do not support the protocol there’s only one condition
- There’s no header to look for
So which of the browsers that currently support the DNT header (Firefox, Safari, MSIE) are sending HTTP_DNT=”0″? None of them. So how do I express a tracking preference of 0?
Currently you can’t.
FaceBook going to New York through China to “Help Improve the Mobile Web” – but the Problem has already been solved
Monday, February 27th, 2012
I’m going to switch from Privacy to the Mobile Web for this post.
Helping Improve the Mobile Web – Facebook Developers: “When you build for the mobile web today, it’s hard to know which browsers and devices will support your app. Which is why we’re proud to be joining over 30 device manufacturers, carriers, and developers in an industry-wide effort to help accelerate the improvement and standardization of mobile browsers: the W3C Mobile Web Platform Core Community Group. For developers, this makes it easier to understand your app’s potential reach and to help prioritize which browser capabilities are important to you.”
In the industry this is colloquially known as the “DevCap” problem. As in, what are the capabilities of the connecting device. Currently there is no way to figure this out in real time. Can’t be done.
But what if it could?
Welcome to Choice™ – the worlds first browser that can tell a Web server (and Facebook) in real time exactly what the device is capable of supporting, exactly what the browser is capable of doing, and just about anything else you want to know. It does all of this using all existing Web standards, works with all Mobile devices – and it can do all of this and preserve your right to Privacy.
Privacy: Do Not Track & the real Elephant in the room
Monday, February 27th, 2012
As we continue our discussions on Privacy i’m drawn more and more to thinking about the core problem. Colloquially you’d hear this expressed as either the 800LB Gorilla or the Elephant… in the room.
First lets start with a simple and elegant definition of Privacy.
Selmer and Blekeli in 1977: Privacy is the legitimate interest of a person to control the collection and use of information that relates to him/herself. (Source: “Data og personvern” p. 21, Universitetsforlaget, Oslo))
I really like this. It describes the elephant very elegantly. It’s all about the legitimate interest of a person to control the collection and the use of that information that relates to him or herself. One word immediately jumps out at you… the word “Control”. The user (him or herself) MUST be in control of any information that pertains to them. In other words this is all about “Me” controlling “My Data” and what I’ve looked at online.
This is where the battle lines in the war on Privacy are being drawn.
Let me give you a real world example. I visit Google.com and do a search for something that triggers a keyword that the Govt. tracks. Let’s think of one – “terrorism”, lets think of two more, “bomb making”. Combined, these are three very potent words, and certain Govt. agencies may be very interested in knowing not only who is looking at them, but exactly where they were located when they looked at them.
So the idea behind the Do Not Track header is that if I had this setting turned on in my browser when I visited Google and did a search for those words, then Google would NOT track any of that information. So in essence if the Govt. requested the logs of all the Web visits and search requests in the last few days they would never see that I was searching for “terrorism” or “bomb making”. This is the whole idea behind what Selmer and Blekeli are talking about – I remain in control of my information that relates to Me.
Unfortunately as we’ve already discussed in a previous post “Privacy: Making SSL faster, and why Do Not Track is NOT using it” without even the basics like SSL running there’s very little teeth to the current Do Not Track standard. There’s simply too many ways for the Web servers to say that the user never really sent the header even though they clearly did.
So what’s the solution?
Well actually it’s pretty simple. An audit log that the user controls on the device. Think of it this way. I launch my browser, I go into my Privacy Options and there I set a checkbox that says “Audit Browser”. What this does is to keep a record of everywhere I go, every keystroke I enter, and every Web page that loads. It stores that data “compressed and then encrypted” on my device. In essence it becomes my personal log of everything that I did.
Now imagine if the Govt. pulls up at my door one day and wants to chat about my search requests. Well I would show them that I have my Do Not Track setting on in my browser, and that I have a complete record of everything i’ve done on the Web. So exactly how did you (the Govt.) learn that I was searching for information on those words.
Well there’s only one place it could have come from – Google’s logs. They either did not see my Do Not Track header (because a 3rd party caching engine stripped it off, or because the transaction was not SSL and it was lost) or they did see it, and the chose to give the Govt. access anyway.
So that’s the real Elephant in the room – It’s all boiling down to who has control over my data. Selmer and Blekeli argue (persuasively) that I should have control – the current standard being offered (DNT) is actually out of alignment with that argument. There’s nothing in the standard that extends the control back to the user by way of either additional settings (see my blog on Privacy on the Internet is not binary) or in the ability to audit themselves to see what they did.
For Privacy and Do Not Track to really work there has to be trust. The user (Me) has to trust that the Web server/entity is really protecting my privacy. The only way this will ultimately be determined is by a legal challenge. It’s pretty clear right now that there’s NOTHING in the current standard that will provide either side with the answers they need to “prove beyond a reasonable doubt” that the Web entity and 3rd party tracking sites honored my Privacy.
So the conclusion is now obvious. The Elephant in the room is going to remain in the room, because it’s in the interests of those who wish to know more about you than you’re willing to share.
Privacy: Making SSL faster, and why Do Not Track is NOT using it
Monday, February 27th, 2012
In my last post: Privacy: What “Do Not Track” really needs to make it enforceable (and verifiable) – HTTPS I finished up asking what would could be done to speed up encryption and SSL.
Before we answer the question lets chat a moment about what SSL or TLS (Transaction Layer Security) is. Here’s the definition from Wikipedia: link
Transport Layer Security (TLS) and its predecessor, Secure Sockets Layer (SSL), are cryptographic protocols that provide communication security over the Internet. TLS and SSL encrypt the segments of network connections above the Transport Layer, using asymmetric cryptography for key exchange, symmetric encryption for privacy, and message authentication codes for message integrity.
There are 3 critical elements to SSL/TLS which i’ve highlighted in bold above
-
Key Exchange -
Key Encryption -
Message Authentication
In lay terms it boils down to a method to exchange the “keys”, a way to encrypt the message to ensure privacy, and finally a way to deliver the message that ensures integrity. So when you want to buy something on the Web everyone uses SSL/TLS to ensure that the message remains private, and that the integrity of the message between the buyer and the seller remains intact.
The other advantage of using SSL/TLS is the fact that it’s standards based approach that all current caching and Web servers are intimately familiar with. Any caching server that sees a browser request for a Web page that starts with HTTPS immediately “gets out of the way” and essentially allows the browser and the Web server to communicate in a Peer-To-Peer fashion. No more dropped headers, no more corrupted messages, you know whose there.
So why isn’t the Do Not Track standard using SSL/TLS to ensure the integrity of the “tracking header” that is delivered to the Web server? Well there’s a number of reason.
- It’s processor intensive
- There are over ½ a billion Web servers out there that would have to change from HTTP to full time HTTPS (Source)
For example let’s take Google’s Mobile home page and see how it performs in both regular HTTP mode vs. HTTPS mode.
The delta between the two tests is about 1500k in page size, and let’s call it ½ a second in extra tim. It doesn’t sound like much (Google’s got some very fast servers) however when you multiple that by a billion search requests a day, the number of seconds becomes hours of lost time. Using the general rule of thumb that ½ a second is worth about a billion dollars a year to Google in revenue you get the idea very quickly that switching to SSL is not something to do lightly.
The other thing to remember here is that every element on a Web page that is requested using HTTPS has to be encrypted. That means in the above example that Google encrypted 19 elements vs. NOT encrypting 17 elements. What’s missing here is a way to “encrypt only the elements that count”.
Remember at the end of my last blog post I talked about “field level encryption”. Well lets chat about that for a moment. Let’s say I decide to buy something on Google’s site. Every single element on that page from graphics to the page itself has to be encrypted. That’s a lot of processing power to essentially protect just a few credit card fields. Why has no one had the idea that it makes sense both performance wise, and bandwidth wise, to “only compress the sensitive parts of the transaction?”.
And this is where field level encryption comes in. Right now Do Not Track has no encryption, basically because it’s not really doing anything other than saying “don’t track me”. There’s no way to really know if someone is really tracking you. So what about switching to an SSL session where now I have a Peer-To-Peer connection established with the server, no one can interfere with the DNT header and I can verify that it was me connecting to the server. Well now all of a sudden compliance becomes doable.
The absence of encryption and SSL/TLS in the current Do Not Track header spec speaks volumes as to what is really going on here. It’s basically an unenforceable standard, which if you think about it makes a lot of sense to the people who care the most about knowing more about you.
Privacy: What “Do Not Track” really needs to make it enforceable (and verifiable) – HTTPS
Sunday, February 26th, 2012
In an earlier post – Privacy: X marks the spot where… I wrote about one of the problems with enforcing the Do Not Track header (the issue with caching servers and how do you enforce and verify the Do Not Track header was really sent?).
So I thought I should offer a suggestion to improve the whole DNT idea. How about SSL (Secure Sockets Layer). Why not move the whole Web to SSL? Think about it, it’s the ONLY solution that offers a real “verifiable handshake” so you can make a “Peer to Peer” connection. No more issues with Caching servers or verification – it’s direct from “one can to another”.
It works for eCommerce so why not use it for Do Not Track? In fact if you think about it how can anyone be suggesting Do Not Track without adding security to the mix.
Of course SSL does come with a few “issues’. It’s a performance hog and requires you to do the work to set everything up correctly. But heck it’s the user’s privacy at stake here – you should be doing it. In my next post we’ll take a look at how you could tweak SSL to really improve performance, and still allow the user to protect their privacy. (Hint: It’s called field level encryption).