W3C home > Mailing lists > Public > public-tracking@w3.org > January 2012

Re: cross-site tracking and what it means

From: Jonathan Robert Mayer <jmayer@stanford.edu>
Date: Fri, 20 Jan 2012 16:52:51 -0800 (PST)
Message-Id: <FD680338-8BF9-48A3-8524-33E01D052899@stanford.edu>
To: David Wainberg <dwainberg@appnexus.com>
Cc: Shane Wiley <wileys@yahoo-inc.com>, David Singer <singer@apple.com>, "public-tracking@w3.org (public-tracking@w3.org)" <public-tracking@w3.org>
I would readily admit that the minutes could better reflect the conversation. I think it would be wise to start explicitly noting points of consensus in the minutes so our progress isn't hampered by differing recollections.

At any rate, here's what I remember: there was a call for any disagreement, I responded, we worked through my concern, and then we set an ACTION for drafting text. There may have even been a smattering of applause at the accomplishment. Sure seemed like consensus at the time.

On Jan 20, 2012, at 4:56 PM, David Wainberg <dwainberg@appnexus.com> wrote:

> I think I'm missing it. Where in that discussion is a consensus on baking legal precautions into the standard?
> 
> On 1/20/12 5:15 PM, Jonathan Mayer wrote:
>> 
>> On Jan 20, 2012, at 4:08 PM, David Wainberg wrote:
>> 
>>> 
>>> 
>>> On 1/20/12 1:19 PM, Jonathan Mayer wrote:
>>>>>> There was consensus at Santa Clara that the outsourcing exception requires both legal and technical precautions.  There was not consensus about what those precautions are against, either 1) collecting data that could be correlated across first parties, or 2) commingling data across first parties.  David's draft text proposes the former rule (which de facto encapsulates the latter rule), and I am in support.
>>>>> I do not recall consensus on this. Wasn't there dissent regarding the feasibility of such precautions? My view is that legal requirements in this technical standard are not workable.
>>>> See the minutes from the first day of Santa Clara.  Shane's proposal was a MUST on legal precautions and a SHOULD on technical precautions.  My proposal was a MUST on legal precautions and a MUST on technical precautions - including origin-scoped data.  The group compromised with a MUST on legal precautions and a MUST on technical precautions, with a non-normative suggestion of origin-scoped data.  It was a great example of consensus-building through compromise.  I hope Brussels will follow suit.
>>> Can you point me to this in the minutes? I don't recall a consensus on baking legal precautions into the standard.
>> 
>> http://www.w3.org/2011/10/31-dnt-minutes.html
>> 
>> Discussion of ISSUE-73.
>> 
>>>>>> I believe there is consensus on how the most common widget use cases should turn out.  There appeared to be consensus on the list and in calls to apply a user expectations test to borderline cases, but that consensus may no longer exist.
>>>>> No, I don't think we had consensus that a "user expectations" test should be used. A user expectations standard is absolutely unworkable for companies trying to implement. From my conversations with others in industry, the one thing almost everyone says they want out of DNT is clarity. The ambiguity of a user expectations test would, in my view, be a disaster.
>>>> My text on widgets in late October included an objective user expectations component.  Tom's subsequent text included a subjective user intent component.  In the lengthy discussions of both texts - in calls, on the list, and in person - I cannot recall any objection to the reliance on user expectations.  That said, I recognize that many in the group are now uncomfortable with a user expectations approach, and that's why I noted that to the extent there was consensus earlier, it "may no longer exist."
>>>> 
>>>> As for a user expectations test being "absolutely unworkable" and lacking "clarity" - I thoroughly disagree, and despite protracted grousing from many in the group, I have yet to see use cases to the contrary.  I'm sure it'll make for lively discussion in Brussels.
>>> It's one thing to use our notions of user expectations to guide our development of the spec. That's fine. However, it's something else to bake it into the spec as a standard that must be met. And regardless of any consensus in this group, my point as someone who actually may have to implement this at a company is that it's too way too vague.
Received on Saturday, 21 January 2012 00:53:20 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:38:30 UTC