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

On Apr 23, 2013, at 9:42 AM, Rigo Wenning wrote:

> 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.

Actually the incentive is to provide as much accurate information as
possible via automated means just to avoid the very small chance that
a more extensive legal discovery process would be initiated by the
authorities (which have the authority to do so regardless of DNT).

> 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.

You are barking up the wrong tree.  A MUST here has already been
rejected because the cost of maintaining such information far exceeds
its value even if every UA were to implement active verification and
color-coded DNT display fireworks.  If it turns out to be useful,
then sites that need same-party relationships can choose to use it.

> 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. 

No, I said that there is no performance penalty for those who do
not wish active verification, which is everyone outside our WG,
it can be implemented by every site (unlike header fields
that can only be implemented by server admins), it can be
used for pre-flight verification of DNT status, and when active
verification is desired it can be performed in parallel outside
the request context, which means it can occur outside the
critical path of request processing or via the use of external
tools that do not have the performance considerations of browsers.

If you want to call that a toy, fine.  The Web is just a collection
of my toys.

>> 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). 

That is entirely incoherent.  A purchase involves an exchange of
value for value -- no purchase occurs if the exchange is never made.
A validly configured user preference is just information -- nothing
more or less -- and does not require any exchange of value.  In fact,
the entire premise of DNT is to ask servers to voluntary discard
valuable data based on that preference.  There is no exchange,
no purchase, and no agreement or contract that binds the parties.
The only legal constructs relevant to DNT are independent of DNT:
privacy regulations regarding the processing of personal data and
business regulations regarding fair and non-deceptive practices.

>> 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.

DNT is a one-way message that is a communication.  Other one-way
messages you might be familiar with are light houses, fog horns,
tsunami alerts, football referees, sirens, traffic signs, turn signals,
rail schedules, laws, biblical references, and the occasional
middle finger in an appropriate regional context. They seem to work.

....Roy

Received on Tuesday, 23 April 2013 23:28:18 UTC