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.

Received on Friday, 20 January 2012 19:25:05 UTC