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

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

Received on Friday, 4 May 2012 17:52:10 UTC