- From: David Singer <singer@apple.com>
- Date: Wed, 03 Jul 2013 11:47:50 -0700
- To: "Dobbs, Brooks" <brooks.dobbs@kbmg.com>
- Cc: "public-tracking@w3.org List" <public-tracking@w3.org>
Hi Brooks I certainly don't mind improving the introduction. It was a weak push-back at best… Amy's suggestion "to allow or limit online third party tracking" had the problem that it implied only 3rd parties are affected. We felt that yours was editorially quite a bit harder to read than the existing succinct statement, and at this point in the document, a general succinct statement, that is then amplified and made more specific by the rest of the document, was best. you wrote: Do Not Track is designed to provide users with a simple preference mechanism to limit online tracking relative to the collector being a 1st or 3rd party to the user. Do Not Track further lays the groundwork for how a user may express the allowance of tracking either globally or selectively. perhaps something like: Do Not Track is designed to provide users with a simple preference mechanism to limit online tracking, both globally (for all sites) and selectively (for specific sites). There are requirements for sites, and those requirements differ between sites that the user intended to visit, and other sites. On Jul 3, 2013, at 7:55 , "Dobbs, Brooks" <brooks.dobbs@kbmg.com> wrote: > David, > > There is nothing in the language that suggests that there are no > requirements on 1st parties. It is completely syntactically neutral and > one could as easily conclude that there are no obligations on 3rd parities > as no obligations on 1st parties. As a factual matter, the spec does > create very different compliance obligations on 1st parties and 3rd > parties. This distinction is fundamental and is worthy of introduction > early in the document. If you (or others) feel that my proposed language > implies no compliance obligations on 1st parties, please feel free to make > a suggestion. Alternatively, if you don't see a fundamental distinction > on 1st and 3rd party requirements, please make a convincing argument and I > can remove the language. I can't fix what I don't see. > > Now what was not implied, but rather expressed directly by the original > language, was that the spec saw obligations around the offering of a > preference mechanism to allow or deny tracking equally. As no where in > the spec is there a requirement for a mechanism to "allow" tracking, this > is indeed misleading, and I have tried to fix the language. > > Let's get the first sentence right. It would seem such a good start. > > -Brooks > > > > -- > > Brooks Dobbs, CIPP | Chief Privacy Officer | KBM Group | Part of the > Wunderman Network > (Tel) 678 580 2683 | (Mob) 678 492 1662 | kbmg.com > brooks.dobbs@kbmg.com > > > > This email including attachments may contain confidential information. > If you are not the intended recipient, > do not copy, distribute or act on it. Instead, notify the sender > immediately and delete the message. > > > > On 7/2/13 8:13 PM, "David Singer" <singer@apple.com> wrote: > >> http://www.w3.org/wiki/Privacy/TPWG/Change_Proposal_Scope >> >> Problem: >> >> The scope sentence sets the general scope of the specification, and the >> proposed alternatives imply no rules for anything other than 3rd parties, >> which is misleading. >> >> Solution: >> >> no change. we think the current sentence sets the general scope well. >> >> >> Question: >> >> do we need formal 'no change' proposals for everything, or (if we fail to >> agree on a proposal) is that always implicitly there? >> >> >> David Singer >> Multimedia and Software Standards, Apple Inc. >> >> > > David Singer Multimedia and Software Standards, Apple Inc.
Received on Wednesday, 3 July 2013 18:48:17 UTC