RE: Action 229 - Data Append Definition

In an effort to kick start this dormant conversation, I don’t think it makes sense to include a “data append” restriction in this standard.

The practice of “data append” is used by a first party to enhance the user’s online experience (in line with consumer expectations) or for first party marketing (also in line with consumer expectations).  If a consumer objects to the first party marketing, they can fairly easily opt out of such marketing especially if it’s via email.

A data append restriction would not take into account the fact that any data acquired from a 3rd party may be publicly available data or that it may have been collected with consent.  In a DNT world, third parties would not be able to build databases of information about DNT:1 users, so the only data left for first parties to acquire would be publicly available, collected with consent or collected in an off-line setting.  I don’t think a DNT standard should try to restrict this kind of data – not only would that kind of restriction be out of scope, but it also would likely lead to a host of unintended consequences.

I think the proponents of a “data append” restriction would argue that it is needed to close a loophole for data flow (is that correct?).  I would argue that it is not needed, that the current standard sufficiently closes any potential loophole.  For starters, the standard prohibits first parties from sharing data with a third party.  In addition, in a DNT world, third parties will be prohibited from collecting data about DNT:1 users.  So, online data about DNT:1 from third parties will not even be available.  As noted above, the only data left for first parties to acquire about DNT:1 users would be publicly available, collected with consent or collected in an off-line setting – all of which should be out of scope for DNT.

At the end of the day, under the current framework, the only entities that would have data on DNT:1 users will be parties that have gained consent or first parties that are prohibited from sharing the data.  The loophole is closed and we should not include a “data append” restriction that would be out of scope and could lead to unintended consequences.

I look forward to the discussion.





From: Jonathan Mayer [mailto:jmayer@stanford.edu]
Sent: Tuesday, September 04, 2012 5:23 PM
To: Chris Pedigo
Cc: public-tracking@w3.org<mailto:public-tracking@w3.org>
Subject: Re: Action 229 - Data Append Definition

Under the EFF/Mozilla/Stanford compromise proposal, all but one of these use cases might not require an additional (and potentially quite broad) data append exception.

Example 1: Much like widgets are promoted to first party status once the user "meaningfully" interacts with them, Nike could become a first party once the user submits his or her shoe purchase information.

Example 3: A company that provides a geocoding API might qualify as a service provider.

Example 4: Same as Example 3, but with an IP geolocation API.  Coarse first-party IP geolocation is explicitly allowed.

Example 5: A user can always grant permission for a particular information practice, like the opt-in demographic sharing in this example.


On Tuesday, September 4, 2012 at 10:21 PM, Chris Pedigo wrote:

Hello all.  In an effort to focus our conversation about whether “data append” practices should be allowed/disallowed in the standard, I was tasked with providing a crisp definition of “data append.”  I’ve also included a few use cases which I hope will further help the discussion.



Potential definition of Data Append:  the act of adding new information acquired from a third party to information collected about a website visitor.



Use Cases:  Current business practices that would qualify as a “data append” vary greatly in scope, utility and function.  For example:



Firstparty.com<http://Firstparty.com> partners with Nike.  When a customer buys a Nike shoe, they get 6 months free of a health-related service on the firstparty.com<http://firstparty.com>.  The customer must visit firstparty.com<http://firstparty.com> and enter a code to receive the service.  When the customer visits Firstparty.com<http://Firstparty.com>, they enter the code which firstparty.com<http://firstparty.com> matches up to the sale of the Nike shoe.  The process of matching up a code with the offline sale would be considered a data append.  With restrictions on data append, DNT:1 users would not be able to participate in promotional campaigns.



Firstparty.com<http://Firstparty.com> has a large database of customers.  Occasionally, they buy data from a third party to clean up the database (purge bad email addresses, correct address information, etc).  This would be considered a data append.



A user wants to create an account on Firstparty.com<http://Firstparty.com>.  They type in their address and firstparty.com<http://firstparty.com> uses a third party data provider to automatically fill-in the zip code.  That would be a data append.



Firstparty.com<http://Firstparty.com> sells flowers via business relationships with florists around the country.  When the user visits the site, firstparty.com<http://firstparty.com> might use a third party that matches the user’s IP address with the user’s likely location within a metropolitan area.  The location information is then used to customize the inventory available to that customer.  This practice would also be a data append.



Firstparty.com<http://Firstparty.com> might acquire data from a third party about the demographics and behavior of firstparty.com<http://firstparty.com>’s users.  The third party collected the data after users opted in.  This would be considered a data append despite the fact that users opted in to the third party data collection.





Chris Pedigo

VP, Government Affairs

Online Publishers Association

(202) 744-2967