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

Ronan,

 

Rigo is right.

 

All cookies in a domain are sent in the request cookie: header. They might
not be in the set-cookie: response header but that is in the high BW leg (if
you use ADSL).

 

Mike

 

 

From: Ronan Heffernan [mailto:ronansan@gmail.com] 
Sent: 23 April 2013 19:52
To: Rigo Wenning
Cc: Adrian Bateman; public-tracking@w3.org Working Group
Subject: Re: ACTION-258: Propose 'should' for same-party and why

 

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

I think your understanding of the scale of these two things is a bit
inverted.  For instance, I cleared all cookies and visited a popular
e-commerce site, with some connection-monitoring tools.  My browser fetched
86 objects, and stored 6 cookies.  Clicking on a product fetched 147 objects
and set 3 new cookies.  Clicking on another product fetched 101 objects, and
set zero new cookies.  If a server detects that a cookie is already set, it
will usually refrain from setting it again, unless there is some new data
that really needs to be stored in the UA.

Adding something to a response header for every object, especially if you
want to mandate that UAs do something with that info, will usually consume
much more processing than cookies. 

--ronan

 

 

On Tue, Apr 23, 2013 at 12:42 PM, Rigo Wenning <rigo@w3.org> 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.

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