W3C home > Mailing lists > Public > public-tracking@w3.org > March 2013

Re: RE: ACTION-258: Propose 'should' for same-party and why

From: Rigo Wenning <rigo@w3.org>
Date: Wed, 20 Mar 2013 16:05:45 +0100
To: Adrian Bateman <adrianba@microsoft.com>
Cc: "public-tracking@w3.org Working Group" <public-tracking@w3.org>
Message-ID: <2772978.2NGPn4Re1v@hegel.sophia.w3.org>
Adrian, 

you make valid points. Nevertheless, it is sometimes very hard to 
determine which entities are the same and to what extend they are the 
same party. 

So the core issue here is that the browser should be careful before 
accepting something from a different origin. And the same-party element 
in the TSR is a way to give the browser concrete information to consider 
whether to open up or not. 

Now comes the chicken-egg thing that usually appears. If there is no 
same-party element used, why should the browser depend its decision on 
it? And if there is no decision by the browser, why should people use 
that element?

I personally could live with the old text provided it adds non-normative 
text explaining the above (apart from the chicken-egg argument)

 --Rigo

On Wednesday 20 March 2013 04:24:51 Adrian Bateman wrote:
> Something cannot be both optional and required to "SHOULD", which as
> we've discussed many times before means "MUST unless you have a very
> good reason". Being expensive isn't usually a good reason.
> 
> The compliance spec already provides a definition that allows people
> to determine same party status.
> http://www.w3.org/2011/tracking-protection/drafts/tracking-compliance.
> html#def-party
> 
> If sites want to voluntarily also provide concrete information in the
> TSR then they are welcome to but they should not be required to do
> this. This may be complex and costly for parties that have a large
> number of domains but which otherwise easily meet the same party
> definition (commonly owned, easy discoverability, etc.)
> 
> As I've said before, I think the old text is better.
Received on Wednesday, 20 March 2013 15:06:34 UTC

This archive was generated by hypermail 2.3.1 : Friday, 3 November 2017 21:45:07 UTC