Privacy: What “Do Not Track” really needs to make it enforceable (and verifiable) – HTTPS
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).