Re: on negotiating site exceptions


for me, neither route A nor route B are really problematic. A cookie is an 
object that is mainly controlled by the server-side and reflects state. 

But DNT is a _user_ preference, not controlled at all by the service side. 
As I'm a schizophrenic paranoid privacy afficionado, I control my cookie 
preferences. So I allow some sites to set cookies and prohibit others from 
doing so. I can delete all my preferences and start over from scratch. But 
those are MY preferences. 

The sending of a signal like DNT=0 is a mere reaction of the UA on my 
preferences. I see that you seem to slip into a paradigm where you 
(understandably) want to control the DNT states from a server perspective. 
This is a very high level difference. But IMHO server centric leads into a 
dead end here. 

For me,  a preference is stored in the UA and we should leave it to UAs 
(like Opera unite) to share the preferences among devices. 

E.g. I may want to have an exception for my desktop, but not for my mobile 
because of dangerous location tracking etc. 

Once you accept that, the solution is the following:

On Friday 06 April 2012 22:34:52 Shane Wiley wrote:
> To coin Rigo, I see Route B as attempting to eat your cake (DNT stored in
> UA) and have it too (force 3rd party exceptions outside of the UA).

If you claim an out of band agreement, you'll send the corresponding 
response header and the UA has to react (or not) on this. Either by asking 
the user or by behaving like tracking would be ok. (and you know about it 
because you got the log in credentials or something similar)
> Route A (site-wide exception - AKA "*") is the better route to bring
> balance to the equation in my opinion.

I think A and B are not exclusive. I welcome site wide exceptions as they 
set the right incentives to invent lesser privacy invasive advertisement for 
better business and more ROI. If we define side wide within the "same-
origin" bucket we even get good implementations from browsers as they know 
what "same-origin" means and have already code to handle it. This just adds 
a feature to the "same-origin" trigger or frame.



Received on Saturday, 7 April 2012 20:04:44 UTC