ACTION-373 Append: background memo on append and related topics

A full agenda for the Wednesday call will circulate later today.  For the compliance spec, the two main topics are: (1) Alan Chapell's language, posted last week, about user education and user experience; and (2) append.

For the latter, my thanks to Yianni and Nick for their work on the attached background memo, which initially was about "first party data in third party context" and now also includes our "append" discussion.  As with other background memos, it attempts to pull together the relevant previous discussions on the same and closely related subjects.  That way, members of the group can easily refresh their recollections about how these topics have been discussed previously.

John (with Jeff's concurrence) have given quite clear answers to my questions about the scope of coverage of their proposed append provision.  In Wednesday's discussion, we will discuss the various categories.  On quite a few, I think there may well be consensus (or close to consensus).  The list of categories thus can help us focus on the shorter list where there are important disagreements.

John and Jeff asked one question about categories 2.2.4 and 3.23 -- analytics.  Perhaps those who have been working on the audience measurement proposal could help out here.  Tentatively, here are my answers:

"2.2.4:  Use data to enhance 1st Party analytics, but don’t target back to an individual user."  I welcome thoughts here.  My idea was that audience measurement providers may provide to 1st parties information about the tendencies of a group.  For instance, suppose left-handed red-heads had higher-than-average interest in a certain product.  This category is when a 3d party tells the 1st party about the left-handed red-head category.
Note that the audience measurement proposal would allow collection (subject to its limits) from DNT:1 users for purposes of calibrating differences with other users.

"3.23:  Analytics or other scenarios?"  On further thought, I'm not sure I see any examples here.



Professor Peter P. Swire
C. William O'Neill Professor of Law
    Ohio State University

From: Jeffrey Chester <<>>
Date: Tuesday, April 9, 2013 9:35 AM
To: Peter Swire <<>>
Cc: "<> (<>)" <<>>, John Simpson <<>>
Subject: Re: ACTION-373 Append: Issues list based on today's call


Many thanks for setting out these scenarios, which I just reviewed.  I totally agree with John Simpson's perspective on what it means under the scenarios. I also agree the header should be persistent, unless a site is otherwise instructed.

As John,  I would appreciate clarification with 2.24.   Can you or colleagues identify what form of analytics would be used that would not be connected to the targeting function?




Thanks for setting out these data categories.  In line below I outline what I believe should happen with data append when when DNT:1 is sent to a 1st Party site.  It's my hope that the proposed data append text and current spec language accomplishes the goal, but it's possible that it misses the mark.  This is what I intended the data append text to accomplish.


On Apr 3, 2013, at 12:47 PM, Peter Swire <<>> wrote:

Based on discussions to date, here are some categoriesrelated to the “append” discussion.  Perhaps I could ask the authors to consider which of these categories they believe would be covered by their proposals where DNT:1 is set at a 1st Party site? (Apologies if I have made any mistake on what is in the currentspec.)

Three major categories:
1. Data from a 1st Party
2. Data to a 1st Party
3. Data used by a 1st Party

Yes, I agree that when a 1st Party receives a DNT:1 message the compliance obligations would involve how the 1st party would handle each of the three categories of data listed above.

1.     Data from a 1st Party
1.1.  1st Party to Outsourced Service Provider.  Current spec allows this if there is no leakage.  Data can only be “accessed and used as directed” by the 1st Party.

I agree the current spec allows data to flow to an outsourced service provider to be used only on behalf of and at the direction of the 1st Party. There needs to be ways to silo the data, etc. I believe our data append text allows this.

1.2.  1st Party to 3d Party.   Current spec says “The first party must not pass information about this transaction to non-serviceprovider third parties who could not collect the data themselves under this standard.”

I agree the the current spec prohibits 1st Party data to be shared with a 3rd Party who couldn't collect the data.  This should remain the same under the data append text.

2.     Data to a 1st Party
2.1.  Data from public records.  Example discussed of employee of the 1st Party using the telephone white pages to look up an address.  A variation is where the 1st Party purchases information from a service about bankruptcy or other court records.

My view is that an employee of a 1st Party could use public data to augment data gathered from the network interaction while a 1st Party for out-of-band communication.  So, in this case, the employee could determine based on the data gathered during the online interaction that it was necessary to telephone the user.  He or she could look up the telephone number in the white pages and call them.  What should not be allowed with DNT:1 enabled is for the offline data, be it from the white pages, bankruptcy or other court records to be combined with 1st Party data to shape the online network transaction.

2.2.  Data from non-public records.
2.2.1.     Dynamically use data to serve real-time ads.

This would not be allowed if DNT:1 is enabled.

2.2.2.     Use data to supplement knowledge of 1st Party about a user, and use the updated set of information to serve online ads in the future.

This would not be allowed if DNT:1 is enabled.

2.2.3.     Use data to supplement knowledge of 1st Party about a user, and use for purposes other than to serve online ads, such as update address and other contact information.

If this were for the purpose of  out-of-band communication with the user, it would be allowed.

2.2.4.     Use data to enhance 1st Party analytics, but don’t target back to an individual user.

I'm sorry, I'm not sure what you envision here. Could you please give an example?

3.     Data used by a 1st Party
3.1.  Use in 1st Party context.  Generally permitted under the spec.

Yes, a 1st Party is allowed to use data gathered in a 1st Party context for 1st Party interactions, including future ones.

3.2.  Use in 3d Party context.  Would be prohibited by Simpson/Chapell proposal.

Yes, I envision our text as prohibiting a Party to use data gathered as a 1st Party when it is a 3rd Party.

3.2.1.     Personalized widgit – user sees a different widgit based on information known to the 1st Party.

This would not be allowed.  It would have to be a generic widget. However, if the user had a meaningful interaction with the widget -- actually clicking on it and interacting as opposed to merely mousing over it -- the widget would become a 1st Party. If the widget were provided by a service that required a login, the widget, appearing as a 3rd Party could be personalized if the user remained logged in.

3.2.2.     Personalized advertisement – user sees a different ad based on information known to the 1st Party.

Not allowed to personalize based on 1st Party info when in 3rd Party context.

3.2.3.     Analytics or other scenarios?

I'm not sure I understand what analytics would be performed  using data gathered as 1st Party when the site was in a 3rd Party context, but it would not be allowed under the data append proposal

One additional issue raised in the call: persistence of DNT header vs. header used for a particular network interaction.

I'm not sure I follow the point here.  The DNT:1 header should be persistent.  That is, once it's enabled it should remain enabled until the user turns it off, the user grants an exception or the site obtains out-of-band consent.  It is conceivable that a user could visit a 1st Party site with DNT:1 enabled and return the next day with DNT:0.  When DNT:1 is enabled, all of the data append compliance obligations would be in effect. If the user returned with DNT:0 they would not be

Received on Tuesday, 9 April 2013 13:58:47 UTC