- From: Justin Brookman <jbrookman@cdt.org>
- Date: Wed, 18 Dec 2013 16:43:55 -0500
- To: David Singer <singer@apple.com>
- Cc: Mike O'Neill <michael.oneill@baycloud.com>, "public-tracking@w3.org (public-tracking@w3.org)" <public-tracking@w3.org>
- Message-Id: <A30EACF8-1DB3-462E-BA53-A80DBF9062F4@cdt.org>
On Dec 18, 2013, at 12:00 PM, David Singer <singer@apple.com> wrote: > > On Dec 18, 2013, at 8:43 , Justin Brookman <jbrookman@cdt.org> wrote: > >> Hi Mike, I appreciate the feedback. A couple thoughts below (not vetted by other Chairs, so perhaps they disagree with me). More discussion is welcome. >> >> On Dec 18, 2013, at 11:22 AM, "Mike O'Neill" <michael.oneill@baycloud.com> wrote: >> >>> Justin, >>> >>> Here are my immediate thoughts on the basis of the chairs’ decision. >>> >>> It is not correct that “the Working Group’s understanding [is] that Do Not Track is not fundamentally intended to limit data collection and use by first parties”. The long standing intention is that DNT should limit the use of collected data by first parties by at least not permitting sharing of it with other parties. >> >> Yes, but that language is just designed to prevent workarounds to the standard by which parties could still do cross-site tracking. It doesn't envision any limitations on what the first party can do with the data itself for its own purposes, nefarious or benign. Option B runs counter to that notion. > > No, it really doesn’t. What users object to is having stuff remembered about them. They might allow sites that they visit to remember stuff about them, but to pretend that those sites are not building a dossier about the users, and hence tracking them, is foolish. It *is* tracking, even if the users realize that in order for the internet to function pleasantly, they are going to have to allow it. > > This is the serious confusion that resulted in a confusing definition. At a philosophical level, I agree that first-party data collection is a form of tracking. But I don't think it's the sort of tracking this group was designed to address, and the group has made the decision not to pursue that type of data collection and use. In which case, maybe you want to make it more clear in the spec that this is designed to address cross-site tracking? I'm certainly going to be clear about that in the scope document in the compliance section (which should be updated with the new definitions tomorrow). I don't think it's right that users would expect Facebook or Gmail to delete their records when they see a user's "Do Not Track" flag. I don't think the working group members think that's what the flag is intended to convey. The group has been settled that it's designed to address a particular online privacy issue --- cross-site tracking. There's obviously some nuance around that, and we have the opportunity to address that in part by adding more language around context, and elsewhere. > >> >>> >>> My objection was to the ambiguity of Option A which can be read as allowing activity data being collected and retained by anyparty (i.e. third-parties or first-parties), if it was derived solely from within that context. This immediately requires the definition of not only “contexts” but also the definition of data that has been tainted through its association with other contexts, and this could further delay the process of getting to LC. >> >> We will be discussing whether we need to define or further describe context on the call today. It would be very helpful if you could present specific textual proposals, though we're not going to adopt a definition of context that radically changes the definition we just agreed to. I think that data that has been "tainted through its associations with other contexts" would constitute tracking under our definition, though if you want to suggest refining language, I'll bring it to the group to consider. >> >> To be clear, not saying you should have textual proposals by noon EST today! But as we move the new issue through the process, specific ideas (as early as possible!) would be appreciated. >> >>> >>> This problem arises from trying to smuggle a particular compliance interpretation into the definition of tracking. A better way might be to have non-normative text saying that the DNT header (with the UGE API) has been designed to be primarily a cross-domain signalling mechanism which can be overridden by assumed consent in specific situations as described in the relevant compliance document, or by actual consent signalled by other mechanisms. >> >> We are not trying to smuggle any compliance notions into the definition of tracking! > > Indeed you very clearly are. The current split of 1st/3rd parties is very much an artefact of the way that the group has currently defined compliance, and it’s at the core of why you mistakenly rejected option B. There are many problems with the 1st/3rd split, not least that the definition is not machine testable. It is not hard to imagine other compliance regimes which have no such distinction, and so using the current ‘first parties can track you’ to define tracking in a contorted way that tries to exclude first parties is absolutely smuggling the current compliance into the definition. > > Since many are now arguing that we should explicitly design for a multi-compliance world, this is a serious flaw in the decision. We're not importing the current compliance standard, but we are taking note of every compliance standard the group has meaningfully discussed. They all envision a distinction between first-party data collection and companies that track you around the web. It would be very odd to have the DNT signal mean something much, much broader than that and then only design a compliance regime to address a particular subset. The tracking definition is for both documents.
Received on Wednesday, 18 December 2013 21:44:27 UTC