Re: Issue-39: Tracking of Geographic Data, Action-67

I would move all this to the exceptions around tracking (which 
themselves need to be moved out from underneath an irrelevant definition 
of "tracking," but that's another story).  This also folds in with 
another outstanding action item that I have, which is that we don't 
currently allow for the collection and usage of data for contextual 
advertisements in the current draft.  I propose we added an eight 
exception to Discussion under 3.6.1:

8.  Contextual Content or Ad Serving:  A third-party may collect and use 
information contained with the user agent string (including IP address 
and referrer url) to deliver content customized to that information.

(Forgive technical ignorance if this language isn't quite right)

This will be subject to whatever data retention/minimization scheme we 
come up (looking forward to catching up on that thread).

We can move Tom's non-normative discussion there as well, though I agree 
with David that hyperlocal ads should be OK if derived from IP address 
and aren't used to profile and are subsequently deleted (our 
minimization language should address).  As for Shane's suggestion that a 
user typically has to grant access to an application or webpage to 
obtain precise geolocation from the device, that is typically true 
today, though that practice is not mandated by law, at least not in the 
U.S.  Also, that permission only logically extends to the first party 
itself, not necessarily all downstream third parties (e.g., I'm fine 
telling Yelp where I am, but don't necessarily understand that I'm 
telling Flurry and Jumptap the same thing).  That said, if the third 
party is just serving an ephemeral ad based on precise geo and then gets 
rid of the information and doesn't build a profile, I would be fine with 
allowing that information to be passed along to the third-party for the 
delivery of a contextual ad.

Justin Brookman
Director, Consumer Privacy
Center for Democracy&  Technology
1634 I Street NW, Suite 1100
Washington, DC 20006
tel 202.407.8812
fax 202.637.0969
justin@cdt.org
http://www.cdt.org
@CenDemTech
@JustinBrookman


On 2/6/2012 4:20 PM, David Wainberg wrote:
> I disagree on geo-targeting. I don't think that fits within 
> definitions of tracking I've seen. And I don't think we should be 
> crafting the standard on what might make some users think they're 
> being tracked. Rather, we should focus on what actually is tracking.
>
> Moreover, Zip or Zip+4 contextual targeting is, to me, low impact 
> privacy-wise, and extremely beneficial, both to users, and to very 
> many small local businesses that rely on precise contextual 
> geo-targeting in order to use their limited advertising dollars 
> effectively. They cannot afford broad un-targeted campaigns. By 
> limiting this usage we'd be providing another competitive advantage to 
> big national brands against small local businesses.
>
> Even though this usage of geo data is not tracking, I know of 
> companies that ensure a minimum pool size for zip+4 data. In other 
> words, they won't target to zip+4 pool of under, for example, 1000 
> households. This seems like a nice practice for privacy, but it's also 
> economic, as it's just not worth it to try to target small pools of 
> users. But, again, it's not tracking, so shouldn't be part of this 
> standard.
>
> On 2/3/12 6:34 PM, Tom Lowenthal wrote:
>> ACTION-65 ISSUE-39
>>
>> Proposed text. Compare with text currently in
>> [S-4.1.2](http://www.w3.org/2011/tracking-protection/drafts/tracking-compliance.html#third-party-compliance) 
>>
>>
>> ~~~~
>> ### Compliance by a third party {#third-party-compliance}
>>
>> If the operator of a third-party domain receives a communication to
>> which a [DNT-ON] header is attached:
>>
>> 1. that operator MUST NOT collect or use information related to that
>> communication outside of the explicitly expressed exceptions as defined
>> within this standard;
>> 2. that operator MUST NOT use information about previous communications
>> in which the operator was a third party, outside of the explicitly
>> expressed exceptions as defined within this standard;
>> 3. that operator [MUST NOT or SHOULD NOT] retain information about
>> previous communications in which the operator was a third party, outside
>> of the explicitly expressed exceptions as defined within this standard.
>>
>> #### Non-Normative Discussion
>>
>> It is acceptable to use data sent as part of this particular network
>> interaction when composing a response to a [DNT-ON] request, but it is
>> not acceptable to store that data any longer than needed to reply. For
>> instance, it would be appropriate to use an IP address to guess which
>> country a user is in, to avoid showing them an advertisement for
>> products or services unavailable where they live.
>>
>> When using request-specific information to compose a reply, some levels
>> of detail may feel invasive to users, and may violate their expectations
>> about Do Not Track. These sorts of detailed assessments should be 
>> avoided.
>>
>> *Reasonable behavior*: A user visits you from an IP address which a
>> general geo-IP database suggests is in the NYC area, where it is 6pm on
>> a Friday. You choose to show an advertisement for theaters and
>> restaurants in the area.
>>
>> *Invasive behavior*: A user visits you from an IP address which suggests
>> that they are in a particular ZIP+4, which has a distinctive demographic
>> profile. Their user-agent indicates that they are a Mac user, further
>> narrowing their expected profile. You serve them an ad for business
>> within a few blocks of them which specializes in items which their
>> expected profile indicates they may enjoy.
>>
>> In this example, even though the decision about which ad to serve was
>> based exclusively on request specific information, but was still
>> tailored to a highly-specific user profile. In particular, the
>> estimation of a user's location to within a single ZIP+4 may make a user
>> feel that they are being followed closely, even if the decision was made
>> on the fly, and the information was only held ephemerally.
>>
>> ~~~
>>
>
>
>

Received on Wednesday, 8 February 2012 15:54:09 UTC