W3C home > Mailing lists > Public > public-tracking@w3.org > February 2012

tracking-ISSUE-122: Should we have use limitations on referrer data? [Tracking Definitions and Compliance]

From: Tracking Protection Working Group Issue Tracker <sysbot+tracker@w3.org>
Date: Wed, 01 Feb 2012 17:16:06 +0000
Message-Id: <E1Rsdmw-0001SU-Gy@tibor.w3.org>
To: public-tracking@w3.org
tracking-ISSUE-122: Should we have use limitations on referrer data? [Tracking Definitions and Compliance]


Raised by: Aleecia McDonald
On product: Tracking Definitions and Compliance

Taken from the minutes of the 11th January call:

Roy: when you come to a website foo.com, they want to know how did you get there (referrer) as a part of analytics. May also care about where they go to, but referrer is something that is easy to get & is something commonly done. May need a new issue.

Jeff: we do need to talk about referrers. Agrees we can drop 23/34 in light of the larger exception. But referrer information is something we need to discuss.

Lauren: many services/vendors who could do a wide variety of things as a vendor for many companies. Whatever restriction there is on sharing amongst the different clients of a vendor would be the same regardless of whether its analytics or whatever.

Aleecia: two irc discussion points.

i. At a technical level referrer is different. It may be difficult or impossible to do away with collection of referrer data

ii. Use or retention is an issue though.

iii. Thomas: referrer could be used as a way to communicate identifiers across sites.

Amy: Lauren makes a good point about keeping the language as flexible as possible. Question to Roy about referrers. This is something the first party could or would see anyway. What we're more concerned about is additional data.

Roy: referrer is provided as data for the requests. If general first party exception, that would cover it.

Amy: flexible for many business models while preventing first party from seeing things that they would see already.
Received on Wednesday, 1 February 2012 17:16:08 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:38:32 UTC