- From: David Singer <singer@apple.com>
- Date: Thu, 09 Apr 2015 14:06:22 -0700
- To: Justin Brookman <jbrookman@cdt.org>
- Cc: "Roy T. Fielding" <fielding@gbiv.com>, Walter van Holst <walter@vanholst.com>, Tracking Protection Working Group <public-tracking@w3.org>
minor editorial > On Apr 9, 2015, at 13:09 , Justin Brookman <jbrookman@cdt.org> wrote: > > So, to be clear, Section 3.3 would read in full (forgive dodgy formatting): > When a third party to a given user action receives a DNT:1 signal in a related network interaction, that party may collect and use data about those network interactions when: you need to somehow clarify that these following three are separate (‘or’ conjunction, not ‘and’). insert “either” before the “:”? > > • a user has explicitly granted consent, as described below (Section 4. Consent); > • data is collected for the set of permitted uses described below (Section 3.3.2 Permitted Uses); > • or, the data is permanently de-identified as defined in this specification (Section 2.9 De-identification [ADD INTERNAL LINK]). > Other than under those enumerated conditions, that party MUST NOT > • collect data from this network interaction that would result in > data regarding this particular user being associated across > multiple distinct contexts; > > • retain, use, or share data derived from this particular user's > activity outside the context in which that activity occurred; nor, > > • use data about this particular user's activity in other contexts (e.g., to personalize a response to this network interaction) > > EXAMPLE 2 > An embedded widget provider (a third party to users' interactions with various sites) counts visitors' country of origin and device type but removes identifiers in order to permanently de-identify collected data. For the purposes of this specification, the party is not tracking the user and can create a static site-wide tracking status resource with a tracking status value of N to indicate that status. > > Outside the permitted uses and explicitly-granted exceptions listed below, a third party to a given user action must not collect, share, or associate with related network interactions any identifiers that identify a specific user, user agent, or device. For example, a third party that does not require unique user identifiers for one of the permitted uses must not place a unique identifier in cookies or other browser-based local storage mechanisms. > > ************* > > JB: The rest of third-party compliance would I think not be affected (apart from the replacement of the term "tracking data" with "that data" and "data about that activity" in 3.3.1.3 and Example 4, respectively): http://www.w3.org/2011/tracking-protection/drafts/tracking-compliance.html#third-party-compliance > > > On Thu, Apr 9, 2015 at 3:24 PM, Roy T. Fielding <fielding@gbiv.com> wrote: > On Apr 9, 2015, at 7:48 AM, Walter van Holst wrote: > > > On 2015-04-09 16:38, Justin Brookman wrote: > >> Right, this is a different issue than the use of the term "tracking > >> data." Contractual agreements with third parties to not try to > >> reidentify data sets are one way to ensure that deidentified data > >> stays that way. For example, the FTC's test for deidentification is > >> (1) a reasonable belief that the data can't be reidentified, (2) a > >> commitment not to reidentify, and (3) a commitment not to reidentify > >> from everyone you give the data set to. > >> I personally would be fine adding language about this to this > >> non-normative guidance --- would just adding "and agreements" to the > >> second bullet do it? > > > > Substitute "agreements" with safeguards and put in non-normative language that safeguards may be provided through agreements and we're closer to meaning and scope of the original text again. > > Technical safeguards are mentioned in the first bullet. I am fine with > Justin's addition of agreements to the second bullet (even though it has > nothing to do with the removal of "original tracking data" that we have > been discussing). > > I don't consider agreements to be a safeguard -- I thought the whole point > of being a safeguard was that it is effective even if a business fails > to uphold an agreement. Hence, the separate bullets. > > ....Roy > > David Singer Manager, Software Standards, Apple Inc.
Received on Thursday, 9 April 2015 21:06:52 UTC