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

Adrian, 

sorry for the scope creep in this discussion. There are 2 discussions in 
this email: the first over "same-party" and the second over "we don't 
need to look at any response from the service". 

The second drives me up the wall. 

The first is not very controversial: I would feel comfortable with a 
"MAY" of "same-party" if browsers would react on it. So on the substance 
of the question, we disagree only partly. The same-party has 2 
functions: 
1/ tell the user that different domains are one legal entity. This is 
used in the "DPA" mode (crawler) to collect data, harvest and test 
against bad behavior schemes.
2/ tell the browser that this is still the first party in order to avoid 
getting hung up in security blockings. 

For 1/ you need a must as the incentive is not to expose information to 
authorities. 

For 2/ you need a MAY, as a service has all interest not to get 
entangled in browser security limitations. This would also serve 1/

If we say 2/ is sufficient, but nobody implements 2/, there is no 
incentive left whatsoever to deal with "same-party". In this case 1/ is 
also lost. 

Tom Loewenthal therefore suggested at least a SHOULD. I think we can go 
down to a MAY if browsers integrate some predictive behavior into their 
blocking/security considerations. 

What I hear back is: Nobody is doing TSR anyway, so the discussion is 
futile. But seeing the incentives above, not implementing is arguing for 
a MUST to achieve some minimal transparency for the user perspective. 
This has other bad implications (like showing your business relations). 
Refusing to look into and react on same-party thus creates a dead-lock. 

On Tuesday 23 April 2013 14:49:46 Adrian Bateman wrote:
> On Tuesday, April 23, 2013 6:01 AM, Rigo Wenning wrote:
> Downloading a TSR itself provides no extra privacy. And we're not
> talking about a single download. You would have to download the TSR
> for almost every origin, which you suggest would be hundreds of extra
> downloads. And how would you possibly display information from these
> hundred downloads, especially in a browser that has no visible UI
> most of the time?

Only if you have to look at Roy's toy, the well-known location. I was 
always against it for that very reason. If a site provides the TSV in 
the header it comes automagically (200) without additional round trip. 
At the time we discussed this Roy said that there is no performance 
penalty involved with the well-known location design as there is no 
performance penalty. Now there is a performance penalty. I'm used to 
more coherence with you engineers. 
> 
> The browser conveys the preference; it expresses a preference about
> tracking, if you like. Hence Tracking Preference Expression.  Sites
> either respect the preference or they don't.

This view is so overly simplistic that it is hard to respond. In your 
concept above, you can't really call that a "preference". Because a user 
needs information before she can express a "preference". Sending DNT:1 
headers for whatever reason may be a vendor's preference. 
Next time I buy software, I either pay or I don't. But you won't know as 
your MS wallet won't tell you. 

No response, no commitment, no commitment no value for the DNT header 
(other than nice decoration). 

Not looking at or collecting responses is as good as no DNT at all. You 
can log and store every bloody cookie on the web in the browser but no 
status response that is 1% the size of a cookie? You're winding me up, 
right?

And I won't make the same mistake being gentle like I have been 10 years 
ago with P3P. Not reading any response is just not an option. It is just 
providing a second cookie store in the hope it is more persistent than 
the other. As soon as the new unprotected open dnt store is abused, the 
extensions and tools will clean it like any cookie store. Which turns 
all efforts here into a rather futile exercise. So instead of providing 
a privacy communication mechanism, IE is offering a new tracking store 
called "exception mechanism". Calling this "privacy tool" is the cream 
on top.

[...]
> The definition we've been using for Party is:
> 
> "A party is any commercial, nonprofit, or governmental organization, a
> subsidiary or unit of such an organization, or a person. For unique
> corporate entities to qualify as a common party with respect to this
> document,those entities MUST be commonly owned and commonly
> controlled and MUST provide easy discoverability of affiliate
> organizations. A list of affiliates MUST be provided within one click
> from each page or the entity owner clearly identified within one
> click from each page."

I think this wording is disputed (and rightly so). Anyway, this is the 
human privacy policy trap that is known since over 10 years not to work. 
It doesn't achieve neither goal 1/ nor goal 2/ in our context and looks 
like a bureaucratic charade. 

> 
> This notion of discoverable ownership is one that we've been using for
> a while.

The above is issue 1/ that is not really contentious. But here you mix 
up definition of party and the challenge to match party and domains. 
Both things are orthogonal. The party discussions have been disputed 
only between non-lawyers. I remember all lawyers in Seattle in a corner 
not understanding how one could dispute party as there is an entire 
field of law existing since hundred years determining what a party is. 
> 
> If the market demands more explicit communication of same party
> then those who wish to respond to this demand MAY provide the
> information. If the market demands that browsers provide more
> information then they MAY also provide it.

Again a nice MS stereotype argument. The entire HTML5 debate is that the 
Web is driven by offer and browser implementation. And MS is playing 
with this. The argument with the market demand is not really a nice or 
new one. MS uses it to mask the phrase "go away". 
But this exchange prepares the discussion about user agent conformance 
criteria. I would insist that a user agent can parse/read/display/store 
a tracking status value in order to be called conformant. 
> 
> The purpose of this group is to make it possible for people to express
> their preference and for sites to receive and understand the
> preference and to behave appropriately. We do not need to mandate the
> way in which people consume the information made available to them
> from sites.

This wrongly simplifying view will not work at all. It is the 
philosophic concept of a one-way message. DNT is a communication. A site 
may not honor your header but still adhere to DNT. Because there are 
sometimes valid reasons not to adhere while still claiming conformance. 
So not reading the tracking status values will make users flying blind 
on the Web. Without browser commitment to something more than a DNT:1 
spawning privacy placebo, our effort will not go very far. 
> 
> Organisations must be allowed to compete on privacy.

Hear Hear! When does MS start? :)

 --Rigo

Received on Tuesday, 23 April 2013 16:43:25 UTC