Re: [Issue-5] [Action-77] Defining Tunnel-Vision 'Do Not (Cross-Site) Track'

"Records derived when DNT is on (1), MUST be held separately from other
data derived when DNT is not on (1).": By "MUST be held separately", you
are not intending to imply any particular technical or physical approach
to the "separation" are you?

As noted in other threads, "research/market-analytics" and "product
improvement" are important exceptions that depend upon short-term
retention of data (typically not PII though) prior to analysis/aggregation.

Otherwise your definition looks very close.

Thanks,
Bryan

On 1/29/12 8:15 AM, "David Singer" <singer@apple.com> wrote:

>This is a revision of my previous email, and a response to Action-77,
>which is one of 6 (?) actions related to Issue-5.  Please ask questions
>as needed to clarify, and I will write a composite revised definition, so
>we can close Action-77, and (once that's been done for the other
>formulations) Issue-5.
>
>This is an alternative to restricting tracking via a 1st/3rd party
>distinction. 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, since it's within a 'party' that information flows, and so
>on.)
>
>
>RULE
>
>Informally, we allow sites only to record what they do and learn
>*directly* about the interaction between themselves and the user.
>
>The formal rule is this:
>
>When DNT is on (1):
>Data records that both identify or could identify, a single USER, and
>also identify, or could identify, a single SITE (that is part of a Party),
>* MUST identify or be capable of identifying no other Party, or site that
>is part of any other Party;
>* MUST be derived only from transactions directly between the identified
>Party and the user, possibly combined with publicly available data,
>* MUST be available/accessible only to/by the identified Party,
>* MUST NOT contain user-specific non-public information derived or
>passed, directly or indirectly, from any other Party,
>
>If the data is held by another party on behalf of the identified party,
>that holding party MUST have no rights to use the data.
>
>Records derived when DNT is on (1), MUST be held separately from other
>data derived when DNT is not on (1).
>
>EXCEPTIONS
>
>not needed:
>
>Outsourcing exception: not needed, it's part of the rule in the first
>place.
>1st-party exception: not needed: all sites/parties are allowed to
>remember the user's interactions with them.
>Unidentifiable data exception: not needed, as the definition here only
>concerns user-identifiable data in the first place (which can probably be
>true for all rule sets)
>Operational exceptions:
>  frequency capping, story-boarding: not needed; the ad site is permitted
>to remember what IT served YOU, just not a lot of why (which 1st party
>you were on, etc.)
>  financial logging: separate un-identified records can be kept on the
>number of impressions on a 1st-party site (why is this not true for all
>proposals?)
>  3rd party auditing: again, is it necessary to keep a record that
>identifies a specific user?
>
>potentially needed:
>
>Operational exceptions:
>  security/fraud: an exception may be needed here, especially if
>cross-site fraud is to be detected
>  research/market-analytics: we don't have a current formulation, and the
>title is broad enough to allow almost anything, so I can't tell
>  product improvement: this is an issue, again with a serious risk of
>slippery slope
>  debugging: yes, an exception may be needed for debugging
>Legal exception: tracking to the extent required by law
>
>Comments on TUNNEL-VISION
>
>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.  Correlation by the site would enable
>merging these; this is the weakest aspect of this strawman, IMHO.  Under
>the alternative 'cross-site' formulation, I think each site would keep
>N+1 records (1 for when DNT is off, and N for the number of 1st party
>sites 'seen' by this 3rd party for this user).
>
>Frequency capping and storyboarding by advertisers are 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'.
>
>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.
>
>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.
>
>The attraction of this rule is that many fewer exceptions are needed.
>The downside of this formulation is that it relies on sites not to
>re-correlate the records, though there is still a lot of data that cannot
>be recorded.
>
>David Singer
>Multimedia and Software Standards, Apple Inc.
>
>
>

Received on Thursday, 2 February 2012 05:01:07 UTC