Re: ACTION-172: Write up more detailed list of use cases for origin/origin exceptions

Changes can occur:

1/ if users change their preferences

2/ if the site changes their setup

So the * vs origin/origin cuts both ways: 

1/ The user may change mind only concerning a certain 3rd party, still 
accepting all the others. If "*" is the only choice, all others lose because 
of one black sheep. 
Note that I already said in DC that a newer preference expression will 
always replace and overwrite an older expression.

2/ If the site changes, the origin/origin gives you even better results. 
Once you've overcome the initial burden of getting the first 400 services 
into the preferences (which is very quick according to my experience with 
the W3C privacy-dashboard), changing one may mean one is not accepted. 
Asking again for the entire bundle may mean you lose them all. Only because 
one changed. So the imagined optimization can severely backfire IMHO.

Again, I do not imagine some pop-up into the face of the user, but rather an  
icon with a switch that allows people to react in case he cares (US market) 
and that allows a site to get the right communications (EU market). In the 
latter I can exemplify best: 

A user hits site A for the first time. The site wants to track to monetize 
content and uses P1, P2 and P3. It can indicate with the API that the user 
can not access the content without tracking. Ok-button, gone. This would 
mean agreement for "*". But "*" means all P1, P2 and P3. Later the user 
returns and service has P1, P2 and P4. I imagine, the service still provides 
the content even if P4 receives DNT;1. In this case, the button in the 
chrome just blinks. Clicking on it shows the dashboard with P1, P2 and P4 
while P4 is in yellow and wants agreement. 

Rigo

On Tuesday 01 May 2012 19:55:57 Ian Fette wrote:
> > Yes, sites can use other means to specify the limited set of parties
> > they
> > work with or to explain their list of parties. If the request itself
> > contains the list, users may be able to verify the list at the time that
> > permission is requested and will know that the permissions they grant
> > won't change if other resources are embedded in the future.
> 
> and if permissions change in the future, which is highly likely for
> advertising (that a new third party comes or goes from somewhere in the
> redirect chain), you have to prompt again, which is a horrible UX, so I
> doubt sites will actually use this.

Received on Friday, 4 May 2012 16:19:29 UTC