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

I think a policy is stored at a well known location for those who care to
fetch it to read up on a site's policy. I do not imagine that it's
something that a browser should ever fetch as a (blocking) part of browsing
to a website. If we're imaging that a browser fetches a policy file on
every navigation, that would be a failure IMO...

As for the " Ok, this is slower, but this is unknown territory for both." -
it is not slower in the case where only * exists. You either have a site
wide exception or you don't, this is trivial for the browser to message to
the site.

I maintain that your suggestion is quite a bit more complex. Web-wide
exception handling is already a breeze, that's not the problem. The problem
is complex UI around which third parties are granted exceptions tied to a
particular site, and telling a site the status of the exceptions for third
parties on that site.

-Ian

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

> On Friday 04 May 2012 09:53:10 Ian Fette wrote:
> > 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.
>
> You do have exactly the same issue for "same_party". Why aren't you
> complaining there? WKL always means +1xRTT. That's why I want the
> communication in the header. Vincent already suggested to have those third
> parties in the WKL file
>
> Your issue is a protocol issue. If a site wants to block unless tracking is
> allowed, it will send a corresponding response header on the GET request
> with DNT;1. Ok, this is slower, but this is unknown territory for both.
> Once
> it is known territory things can be very fast. If we do not have that
> response header, we should create one.
>
> I think in another email you rightly raise the question of where user
> preferences are stored. I don't want to stand in the way of innovative
> services, but I would only use a DNT tool that stores its preferences
> locally (in the browser).
>
> You know that the site has added P4 when you've parsed the page and you
> have
> no preferences for P4 in your store. If "*" means "I as a browser do not
> care at all, because its * anyway" I see that it can become simple. Either
> you open the floodgates or you don't. But does this also override web-wide
> exceptions?
>
> My suggestion is just a bit more complex but makes web-wide exception
> handling a breeze: You just monitor where the requests are going and match
> with your preferences database. If it goes to an unknown site, you need to
> take action. This allows for very quick fetching of known things and less
> quick fetching of unknown things. And this is exactly how you would behave
> in real life in some unknown terrain. Prudent and slower in still unknown
> areas and fast in already explored areas.
>
> Note that I'm not a programmer!
>
> Rigo
>