Re: An alternative to site-specific user granted exceptions (Issue-111)

Vincent, 

if a site would be monolithic, you would be right. But if it isn't your 
model breaks. Imagine a site where several different third parties are used 
for different pages (e.g. a Portal). The well known location (wkl) would 
either have to enumerate all different pages and the third parties related 
to them, which would make the wkl format very complex; or you have a dynamic 
wkl file but then you'll have to request the wkl with every roundtrip as it 
may have changed. You just doubled the number of roundtrips. 

Additionally, you would kill the beautiful simplicity of the current header 
proposal. 

Consequently, I don't like the proposal as I fear it will kill the header 
and eventually DNT because of lacking adaptability. 

Best, 

Rigo

On Tuesday 17 April 2012 20:03:49 TOUBIANA, VINCENT wrote:
> I suggest an alternative to site-specific exceptions (Issue-111). Instead
> of providing the list of 3rd parties through the JavaScript API, this
> list could be provided through Tracking Status Representation (available
> through the well-known URI). There is already a field to send that list
> to the UA (See section 5.1.2 in TPE document) but it is currently
> optional. If we replace the MAY by a MUST, then users could get the list
> of third parties present on a site before they visit it and then decide
> if they are ready to grant a site-wide exception.
> 
> Pros:
> - User grant exceptions knowing which third parties could track them
> - This does not broke the chain in ad-exchanges
> - Publisher do not have to ask new user granted exceptions when they add
> third parties Cons:
> - Users have to check the well known URI more often
> - Users can not provide feedback about the third parties present on a
> website (a non granted exception is – in my opinion-- an explicit
> feedback).
> 
> I still prefer the site-specific exception mechanism as it gives users
> more choices, but I believe this solution could be seen as a middle
> ground.
> 
> Vincent

Received on Wednesday, 25 April 2012 12:36:32 UTC