Re: Deciding Exceptions (ISSUE-23, ISSUE-24, ISSUE-25, ISSUE-31, ISSUE-34, ISSUE-49)

How are situations then handled where you have proxy or dynamic IP addresses or have a falsely represented user agent – for example the Kindle Fire (android device) represents itself as a Mac Device in the User Agent string:


Here’s the breakdown:

Mobile – no Silk

Mozilla/5.0 (Linux; U; Android 2.3.4; en-us; Silk/1.1.0-84) AppleWebKit/533..1 (KHTML, like Gecko) Version/4.0 Mobile Safari/533.1 Silk-Accelerated=false

Mobile – Silk

Mozilla/5.0 (Linux; U; Android 2.3.4; en-us; Silk/1.1.0-84) AppleWebKit/533..1 (KHTML, like Gecko) Version/4.0 Mobile Safari/533.1 Silk-Accelerated=true

Desktop – no Silk

Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10_6_3; en-us; Silk/1.1.0-80) AppleWebKit/533.16 (KHTML, like Gecko) Version/5.0 Safari/533.16 Silk-Accelerated=false

Desktop – Silk

Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10_6_3; en-us; Silk/1.1.0-80) AppleWebKit/533.16 (KHTML, like Gecko) Version/5.0 Safari/533.16 Silk-Accelerated=true


Geoff Gieron
Business Development Strategist

[Description: AdTruth-logo-final_withstar-02]

O:   +1.480.776.5525
M:  +1.602.418.8094
ggieron@adtruth.com
www.adtruth.com


From: Jonathan Mayer <jmayer@stanford.edu<mailto:jmayer@stanford.edu>>
Date: Fri, 10 Feb 2012 09:16:21 -0800
To: Justin Brookman <jbrookman@cdt.org<mailto:jbrookman@cdt.org>>
Cc: <public-tracking@w3.org<mailto:public-tracking@w3.org>>
Subject: Re: Deciding Exceptions (ISSUE-23, ISSUE-24, ISSUE-25, ISSUE-31, ISSUE-34, ISSUE-49)
Resent-From: <public-tracking@w3.org<mailto:public-tracking@w3.org>>
Resent-Date: Fri, 10 Feb 2012 17:16:54 +0000

Thinking more about tracking through IP address + User-Agent string, it occurs to me that the greatest challenges are stability over time and across locations.  For some of the "operational uses" we have discussed, time- and geography- limited tracking may be adequate.  Scoping the "operational use" exceptions to protocol data would somewhat accommodate those uses without allowing for new data collection, and it would be easier to implement than a client-side privacy-preserving technology.  Thoughts on whether this is a possible new direction for compromise?

Jonathan

On Feb 10, 2012, at 8:30 AM, Jonathan Mayer wrote:

Justin,

I think you may be misreading the state of research on tracking through IP address + User-Agent string.  There is substantial evidence that some browsers can be tracked in that way some of the time.  I am not aware of any study that compares the global effectiveness of tracking through IP address + User-Agent string vs. an ID cookie; intuitively, the ID cookie should be far more effective.  The news story you cite glosses over important caveats in that paper's methodology; it is certainly not the case that "62% of the time, HTTP user-agent information alone can accurately tag a host."

Jonathan

On Feb 9, 2012, at 6:48 PM, Justin Brookman wrote:

Sure.  As the spec current reads, third-party ad networks are allowed to serve contextual ads on sites even when DNT:1 is on, yes?  In order to do this, they're going to get log data, user agent string, device info, IP address, referrer url, etc.  There is growing recognition that that information in and of itself can be used to uniquely identify devices over time (http://www.networkworld.com/news/2012/020212-microsoft-anonymous-255667.html) for profiling purposes.  It was my understanding that one of the primary arguments against allowing third parties to place unique identifiers on the client was because of the concern that they were going to be secretly tracking and building profiles using those cookies.  My point is that they will be able to do that regardless, with little external ability to audit.  This system is going to rely to some extent on trust unless we are proposing to fundamentally rearchitecture the web.

The other argument that I've heard against using unique cookies for this purpose is valid, though to me less compelling: that even if just used for frequency capping, third parties are going to be able to amass data about the types of ads a device sees, from which you could surmise general information about the sites visited on that device (e.g., you are frequency capping a bunch of sports ads --> ergo, the operator of that device probably visiting sports pages).  Everyone seems to agree that it would be improper for a company to use this information to profile (meta-profile?), but there are still concerns about data breach, illegitimate access, and government access of this potentially revealing information.  This concerns me too, but the shadow of my .url stream is to me considerably less privacy sensitive than my actual .url stream.  I could be willing to compromise on a solution that allowed for using cookies for frequency capping, if there was agreement on limiting to reasonable campaign length, rules against repurposing, and a requirement to make an accountable statement of adherence to the standard.  I would be interested to hear if it would be feasible to not register frequency caps for ads for sensitive categories of information (or if at all, cap client-side), though again, it's important to keep in mind that that data may well be collected and retained for other excepted purposes under the standard (e.g., fraud prevention) --- cookie or not.
________________________________
From: Jonathan Mayer [mailto:jmayer@stanford.edu]
To: Justin Brookman [mailto:justin@cdt.org]
Cc: public-tracking@w3.org<mailto:public-tracking@w3.org>
Sent: Thu, 09 Feb 2012 18:32:19 -0500
Subject: Re: Deciding Exceptions (ISSUE-23, ISSUE-24, ISSUE-25, ISSUE-31, ISSUE-34, ISSUE-49)

Justin, could you explain what you mean here?

Thanks,
Jonathan

On Feb 9, 2012, at 3:17 PM, Justin Brookman wrote:

> the standard currently recognizes that third parties are frequently going to be allowed to obtain uniquely-identifying user agent strings despite the presence of a DNT:1 header


The information contained in this e-mail is confidential and/or proprietary of AdTruth. The information transmitted herewith is intended only for use by the individual or entity to which it is addressed. If you are not the intended recipient, you should not copy, distribute, disclose or use the information it contains, please e-mail the sender immediately and delete this message from your system.