Re: ACTION-373 Append: Issues list based on today's call

Peter,

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.

Thanks,
John


On Apr 3, 2013, at 12:47 PM, Peter Swire <peter@peterswire.net> 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.

> 
> Hope this is helpful.
> 
> Peter
> 
> 
> 
> 
> 
> Professor Peter P. Swire
> C. William O'Neill Professor of Law
>     Ohio State University
> 240.994.4142
> www.peterswire.net
> 
>