Privacy: It can be Global, Local & now Regional

 

In yesterdays post Privacy: Do Not Track is Global – But can it ever be Local? I talked about Mozilla proposed new “Three state setting for “Do Not Track”

The current standard is either Allow Tracking or Do Not Track (binary). However this doesn’t satisfy all the use cases on the Web, nor fit well with laws in Europe. (The three-state setting for Do Not Track will consist of “no preference,” “do not track,” and “allow tracking.”).

I pointed out that this approach has a few potential pitfalls. So I offered some ideas that I think will work. So that you can see how this would work in the real world we added the changes to our Choice™ browser. Here's a screen shot of what things look like using a "two state approach" but allowing for 3 states, in this case supporting regional privacy.

What the blue arrow is pointing to:

• Choice™ Verified - means that the server sends us a message that it's honoring "Tracking Allowed"
• Tracking Allowed - means that we've set "Do Not Track" to off (we're ok with you tracking us)
• Using Regional Privacy - means that the server is observing regional (e.g. US vs. EU) privacy laws

We've also adopted a "traffic light" metaphor - Green is good, Red is a warning. The user has the ability to disable these warnings via a checkbox.

So there you have it… a two state approach to the Do Not Track standard that allows for regional privacy laws to be observed.

 

 

 

Privacy: Do Not Track is Global - But can it ever be Local?

 

Yes… (read on)

Today Mozilla proposed a new "Three state setting for "Do Not Track" The current standard is either Allow Tracking or Do Nott Track (binary). However this doesn’t satisfy all the use cases on the Web nor fit well with laws in Europe. (The three-state setting for Do Not Track will consist of “no preference,” “do not track,” and “allow tracking.”)

Here's the idea around the three states...

• In the US
  • DNT = 1 - Do Not Track
  • DNT = 0 - Allow Tracking
  • DNT = "" - Null. This means users did not make a choice, keep tracking
• In the EU
  • DNT = 1 - Do Not Track
  • DNT = 0 - Allow Tracking
  • DNT = "" - Null. Users have NOT consented, Do Not Track

Ok so lets dig in and see what the issues are.

In the US and the EU we're in perfect alignment when the DNT header is set to 1 or 0. The complication (the third state) appears in the case of the "Null" condition. It means different things in different countries i.e. it's regional. So what happens if I set my browser to "No Preference". Well I have insufficient data to resolve the condition. What I need to know in real time, is the current location of the user so I can determine the best solution. In other words if someone sets the browser to "No Preference" then every time they connect to the Web they have to be constantly sharing their location.

In theory this is not a big deal. Simply access the GPS, Cell Tower or Wi-Fi and resolve the location. In practice it's a huge deal. Think about the amount of extra code, extra transmissions and extra battery energy (in the case of Mobile) required to send all this data to the Web server so that it can adhere to the correct regional privacy laws. And because the majority of transactions on the Web use standard HTTP vs. HTTPS (encrypted) there's no way to encrypt all my location data.

 

So is there a solution to the "Do Not Track is Global - But can it ever be Local" problem.

Yes. Here's a thought. Lets go with the following scenario:

• In the US
  • DNT = 1 - Do Not Track
  • DNT = 0 - Allow Tracking
    • In this case send my real time location encrypted as part of the Web request
• In the EU
  • DNT = 1 - Do Not Track
  • DNT = 0 - Allow Tracking
    • In this case send my real time location encrypted as part of the Web request

That works. The default in the browser should be "Do Not Track". In the case that the user "chooses" to allow tracking then a dialog box pops up and indicates that his location will ONLY be used to determine his/her location to comply with local privacy laws. All data will be sent encrypted.

The beauty of this approach is that the Web server doesn't have to ask the browser for the location of the user. It gets it as part of the request. It reads DNT = 0 and looks for the location data. It uses this to only resolve the regional privacy laws and then discards the information. If the user comes back to the site it includes the update location information. In the case that the user has selected DNT = 0 and no location data is shared then the default reverts back to a setting of DNT = 1 or Do Not Track me.

Summary...

Do Not Track can be a Global and Local standard - Only two conditions are required, and my privacy is assured without the need for computationally expensive (and battery consuming) HTTPS communications.

 

Privacy: Do Not Track - Expressing a tracking privacy preference is harder than you think

 

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

 

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

 

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

 

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

1. Key Exchange

2. Key Encryption

3. 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

 

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).

 

Privacy: X marks the spot where...

 

In the beginning there was the Internet… and the Internet was HTTP

The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information systems. It is a generic, stateless, protocol which can be used for many tasks beyond its use for hypertext, such as name servers and distributed object management systems, through extension of its request methods, error codes and headers [47]. A feature of HTTP is the typing and negotiation of data representation, allowing systems to be built independently of the data being transferred. HTTP has been in use by the World-Wide Web global information initiative since 1990. (Source: RFC: 2616)

Those “request methods” mentioned above can contain something called an X header. They are fields in the request that begin with an X and allow for either non-standard or proprietary add-ons to the regular fields in the HTTP header.

So what’s an example of an X header?

x-h3g-network-quality – this tells you the type of network. "3G" for example. It’s a very straightforward idea on how you can add some data to the request that a browser makes to a Web server. The Web server now knows that the phone that the browser made the request from is on a 3G network.

Why are X headers so important?

Well because they’re a “standard” way to add “non-standard” data to the HTTP protocol. Pay special attention to the word “standard”. Everything is about standards.

So why all the fuss about “X” marks the spot.

Well there’s something else I need to tell you about how the Internet works. Remember our familiar picture – two cans and a piece of string. One can (the browser) talks to the other can (the Web server). Ok. Now we have to introduce a new term – Caching. A web cache is a mechanism for the temporary storage (caching) of web documents, such as HTML pages and images, to reduce bandwidth usage, server load, and perceived lag. (Source Wikipedia). The biggest caching engine in the world is probably Google or maybe Bings. But there are tens of thousands of cache sites out on the Web, virtually every ISP uses them to accelerate content. Browsers can connect with a Web caching server vs. going directly to the “origin” Web server. The cache serves as an intermediary.

So what’s the big deal?

Well some of those caching engines have critical problems when it comes to headers. (Source: link) and so if they see something they don’t understand they strip it out.

So what?

Well Do Not Track is a header – it’s not an X header (there’s no X_DNT) which they wouldn’t strip out. So older caching engines may not respect that new header (HTTP_DNT=”1”) and simply strip it out.

Ok… so why’s that a big deal?

Enforcement of the Do Not Track standard – that’s the big deal. How will the origin server ever know if the browser really sent a header that said “Don’t Track Me”? If an intermediary has removed it then there is no knowledge, and therefore it becomes unenforceable. Both Caching and Web servers will need to be upgraded to support a new standard header that is being transmitted in a non standard way i.e. not as an X-header, but as a regular header (that was never planned for in the original HTTP design).

And that is going to be the biggest problem facing the Do Not Track standard. Unless it’s implemented as an X header vs. a standard header then “EVERY” caching engine will have to be updated to support the new standard (to make sure it doesn’t strip anything important out). There are tens of thousands of caching servers out there that will have to be modified and upgraded. Normally no one would care about this… but now due to Privacy they will have to.

Therefore X marks the spot where in this case something is enforceable or not. 

Privacy on the Internet is NOT binary - But what if it was?

 

Back at the end of October last year I wrote a blog post on why Privacy on the Internet is NOT "binary". So I thought I would follow up with another blog post discussing the alternative viewpoint - What if it was binary?

Well first we need a little context about the Internet and how it works. At it's core it's basically two cans and a piece of string. The can (client) on one end talks to the other can (server) on the other end. The string acts as the communication layer (protocol) between the two cans. The protocol that runs across the string is "stateless".

In short that means that there is no means of storing a users data between requests. The work around for this is…. Cookies which allows the server to track requests from the originating client (can). So how we do we stop one of the cans tracking the other one?

 

 

 

Obviously we cannot get rid of cookies otherwise the Web is going to grind to a halt. So what we need is another "binary" method of allowing me to control my privacy.

Enter the "Do Not Track" option. This is a browser setting that tells the first can (client) to send a message to the second can (server) that it doesn't want to be tracked. (We'll discuss how you enforce this in a later blog). Great - I now have a method of communicating with a Web server telling it that I want to remain Private.

Well here's where it gets interesting or should I say "binary". Most people think of binary as either a Zero or a One (0,1) however there is actually a third state in the case of the Do Not Track header and it's called "not set". So in essence the absence of a Zero or a One is another "state".

So what does this mean. Actually quite a lot. If the user turns on his Do Not Track option then the answer is obvious. The server MUST not track him/her. If the Do Not Track option is turned off then the server can track away. However if the option is NOT set at all what is the server to do?

Here comes the really big problem – what if the Web service providers are forced either by legislation or by the W3 standards group to start honoring the Do Not Track option? It’s really easy to spot a Zero or a One as part of the communication request. But what if you don’t see anything? Well it means that you have "insufficient data" to make a decision. Which in turn means that you have to send another message back to the client (can) and ask it for more data.

So how does this all work? Well I have to figure out how to send a pop up message to that device and ask the user if they want to be tracked. Well you can guess what the answer will be – no thanks! So in essence we’ve wasted bandwidth, processing cycles, battery life (on a Mobile phone). And at the same time we’re ruining the users experience. The only thing this third “binary state” (which actually doesn’t exist) has done is draw attention to the problem. Think of all the code that is going to be written to solve this problem. What a waste of resources!

Everybody is trying to solve this “Do Not Track” problem through the lens of the “Web server”. (Because it’s where all the content is stored). What no one is thinking about is solving it through the lens of the Browser user i.e. ME. It’s pretty clear that Privacy cannot be binary – there’s simply not enough information to make real decisions which effect my rights.

By making it binary the Web is risking billions and billions in revenue. Why? Because people want a Choice – if forced to pick between Privacy and NO Privacy which one would you pick.

Pretty obvious really. 

Privacy: Does it Scale

 

Well it sure has been a busy day on the Privacy front. However as I watch all of this, I can't help but ponder if people really understand the magnitude of the problem the Web faces. Lets talk about "Scaling".

On a thermometer today would have Privacy scaling above boiling point. Something is going to happen for sure. Browser companies will have to make changes, Web services will have to make changes - but does it scale?

 

 

Let's think about it for a moment in the context of the "Do Not Track" header which is proposed standard to help curb the Privacy problem. If the Do Not Track header is on then Web services "MUST" observe the customers requests and not track them. There is no ambiguity in the word MUST. It's a have to do vs. a should or may do.

But what are the implications? Well no one really knows, but Web servers, ISP, all tiers of the Internet will be affected. They will have to add code, a lot of code, to accurately support this measure. We're talking years of coding efforts in some cases.

Up until now we've been living in a free for all world. Then Mobile came along and the world changed. Now Privacy is Personal and that means everybody is going to have to honor my request to not be tracked.

And lets not forget "location". What if I get on a plane and access a Web site from a foreign country. Before they can really service my request there's a lot of context they have to determine. And that translates into code, which translates into bandwidth and processor issues.

People want a Choice - because without it there is no Privacy. Today was just a glimpse at what is coming down the pike. The temperature is rising, and it's rising fast.

 

Privacy: Clash of the Titans - Where Humans battle Algorithms

 

Well it seems like a epic battle is about to get underway. To the North are the Humans - demanding that their Privacy be protected and to the South are the Algorithms - constantly "searching" to undermine my Privacy in the name of a better experience.

Years ago when I was studying for my Airline Pilot's license, one of subjects was the Inter Tropical Convergence Zone, colloquially known as the "ITCZ". It's that area on the planet (Source: link) that circles the Earth, near the equator, where the trade winds of the Northern and Southern Hemispheres come together. The intense sun and warm water of the equator heats the air in the ITCZ, raising its humidity and causing it to rise. As the air rises it cools, releasing the accumulated moisture in an almost perpetual series of thunderstorms.

 

 

Well that's exactly what's happening right now. Especially with the announcement this morning by the WSJ (link) that Google is tracking iPhone users. There is now intense heat coming to bear from the "Humans" regarding their privacy. Something is going to give. People want a Choice when it comes to their Privacy. Sort of like "Freedom of Speech". You just can't take it away from people and expect them to not be upset.

For those of you who are interested in Privacy I suggest you head over to this link It's the W3.org's Web site on Public Tracking. Take a spin through the mailing lists. It's fascinating. Everything is hinging on one binary number… 1 This is the setting that users will be able to control in their browser to stop Web sites tracking them. Unfortunately as we've seen today Google et al is ignoring those settings.

This cannot end well for the Algorithms - and here's why. The Humans (Lawyers and Privacy Rights Activists) will write legislation to reign in the ability to track. As scissors always beats paper so will the legislation. However here's where the law of unintended consequences comes into play - Privacy on the Internet is NOT binary (as I have written about before - link). Setting a Do Not Track header to 1 is not enough context to make a really informed decision about what a customer wants.

Ask anyone these days - Privacy is about Choice not about a number. Any solution MUST offer me a Choice otherwise it will fail. In the meantime get ready for some serious thunderstorms - the ITCZ is heating up.

 

Privacy is a Balance

 

As I watch the news unfolding about Path (link) and the controversy over accessing my address book, I can't but shake my head in amazement that people are still missing the point. It's not that they accessed my data without my permission that's the problem - it's that I have no choice in what I choose to share that's at the heart of the matter.

Think about it for a moment, Michael Arrington is an investor in Path. Now Michael probably has an address book only second to Ron Conway's. Can you just imagine the number of aspiring entrepreneurs who would love to access that database. And it's probably all sitting up on someone's servers somewhere.

Now to their credit Path immediately issued an apology and deleted everyone's data from their servers. So far so good. Now comes the problem - they then updated their app so that it asked "permission" to access your address book. As someone would tweet - #fail.

They are still missing the core problem - I want to allow Path access to "some of the people in my address book" - but only those who Path turn into something of value for me. And therein (as the Bard says) lies the problem. Privacy is NOT binary, it's contextual. Not only do I want a choice in what I share, I want to ensure that sharing the data results in a better outcome for both parties.

What the current approach to Privacy has #failed to do is deliver not only a choice, but it has failed to make it contextually aware of not only Who I am, but Where I am. My Privacy has value - it must have because at the moment this topic is becoming radioactive - and yet my only "Choice" is binary. Either share it or not. Well how about offering me something in return? Why do you get to keep the value and I don't. Seems like an unfair choice to me.

Ultimately Privacy is a balance between ensuring Privacy and allowing information to be shared for a better outcome.

 

 

And that's why we invented the new Choice™ browser. It gives you a choice in what and to whom, you want to share your personal data with.