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