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

On Fri, May 4, 2012 at 9:19 AM, Rigo Wenning <rigo@w3.org> wrote:

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

In your example, it doesn't mean *, it means P1, P2, P3 which has all the
drawbacks, e.g. I (as a browser) can't tell a website if it has exceptions
for sites it cares for before it starts delivering content without using
polling and introducing 1xRTT. I have no idea that P1, P2, P3 actually
correspond to * because the next time the user hits the site, as you say,
there could be a new 4th party P4. So, the only thing I can tell the site
is "There exist some third parties on your site that have exceptions" which
is not entirely useless for the site, but probably doesn't suffice for what
I perceive to be the common case.


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