- From: David Singer <singer@apple.com>
- Date: Sun, 22 Jan 2012 12:44:49 -0800
- To: Kevin Smith <kevsmith@adobe.com>
- Cc: "public-tracking@w3.org (public-tracking@w3.org)" <public-tracking@w3.org>
On Jan 22, 2012, at 12:38 , Kevin Smith wrote: > I think your tunnel vision example is actually quite close to what I think of as the Cross Tracking approach. Let's talk more about it in Brussels. OK. I realized I could get rid of another exception if I say "Data recorded that identifies, or could be used to identify, a site, MUST only be available to that site, and no other, in perpetuity" That deals with outsourcing. :-) > > -----Original Message----- > From: David Singer [mailto:singer@apple.com] > Sent: Friday, January 20, 2012 8:25 PM > To: public-tracking@w3.org (public-tracking@w3.org) > Subject: Re: cross-site tracking and what it means - alternative formulations > > OK, I am going to outline two possible definitions of cross-site tracking; these are both alternatives to a 1st/3rd party distinction, and have different effects, and would have different needs for exceptions. I want to emphasize, I am doing this to explore and learn, not to 'promote' any particular direction. I hope people find it helpful. > > All these definitions etc. rely on being able to define "site" or "party", by the way. I don't see how to escape that, as many have pointed out. > > > > When DNT is on (1): > > [PARTY-BASED) The current status. We define 1st and 3rd party, and specify different rules for them. ] > > SEPARATE-RECORDS) Raised by Kevin. Something like: we define site, and say that a site must keep separate any records collected that pertain to user visits to separate sites. > > TUNNEL-VISION) Raised by me. We allow sites only to record what they do and learn *directly* about the interaction between themselves and the user. Here is the kind of way I envisage this would work: > > A site complying with DNT:1 may only collect data, and associate that data with other data, that are both derived directly from transactions between that user and that single site. In particular, a site MUST NOT collect/retain data that > A) identifies, or could be used to identify, another site; or > B) is passed, directly or indirectly, from another site. > The site MUST keep separate any records derived under this restriction, from any other data that does, or could potentially, concern the same user. > > > Comments on TUNNEL-VISION > > It still needs the exception for siloed 3rd-party data (3rd-party collected data that is only used by the 1st party), but it would be phrased as a cross-site exception, not a 1st/3rd exception, of course ("you may collect data about or passed by another site only if such data is available only to that other site"). > > Note that if a user runs sometimes with DNT:0 and sometimes DNT:1, they will end up with two records at sites, one with a lot of other-site data, and the second record with tunnel-vision. Simple correlation by the site would enable merging these; this is the weakest aspect of this strawman, IMHO. > > Note that frequency capping by advertisers is now permitted; you ARE allowed to remember what ad you showed this (anonymous) user, since that was *your* transaction. You're limited in remembering only site-generic 'why' -- you cannot remember 'they visited Sears and so I showed a dishwasher advert'. > > Note that if the user starts interacting with *you*, you can remember that also; we don't need language to make this an exception, or 'promotion' from 3rd to 1st party. > > Note that redirection services can remember basically only that the user was active on the web, since everything else they know (the original URL, the re-direct) either identify or could be used to identify another site. > > [Note that under SEPARATE-RECORDS, if a user runs sometimes with DNT:0 and sometimes DNT:1, they will end up with N+1 records (one merged, from DNT:0, and N for the N 1st parties they visited).] > > David Singer > Multimedia and Software Standards, Apple Inc. > > David Singer Multimedia and Software Standards, Apple Inc.
Received on Sunday, 22 January 2012 20:45:42 UTC