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

RE: Well-known URI vs response headers? [ISSUE-81, ISSUE-47, ISSUE-80]

From: Kevin Smith <kevsmith@adobe.com>
Date: Mon, 5 Mar 2012 15:49:04 -0800
To: Nicholas Doty <npdoty@w3.org>
CC: Ronan Heffernan <ronansan@gmail.com>, "public-tracking@w3.org (public-tracking@w3.org)" <public-tracking@w3.org>
Message-ID: <6E120BECD1FFF142BC26B61F4D994CF3064CC1FEF0@nambx07.corp.adobe.com>
That's a great question Nick, and to be honest, I am not positive.  Perhaps Roy should weigh in.  My understanding is that caching is still possible.  Obviously, the extent to which the URI doc would have to be dynamic, would inversely affect its cacheability (if that's not a word, it should be).  On the other hand, I would not expect exceptions to change frequently per user, so I would not expect it to affect cacheability much.  I would think Roy and possibly the browser vendors could probably answer more authoritatively though.

From: Nicholas Doty [mailto:npdoty@w3.org]
Sent: Monday, March 05, 2012 4:04 PM
To: Kevin Smith
Cc: Ronan Heffernan; public-tracking@w3.org (public-tracking@w3.org)
Subject: Re: Well-known URI vs response headers? [ISSUE-81, ISSUE-47, ISSUE-80]

Hi Kevin,

I don't think we had a solid distinction between user-agent-managed and out-of-band exceptions/opt-back-in back in October. I'm particularly concerned here about the out-of-band case, though it might also apply when the user agent sends a different DNT value. Can a site that offers out-of-band opt-back-in (and wants to start tracking as soon as that permission is granted) allow significant caching of the relevant well-known tracking status resource?

Thanks,
Nick

On Mar 5, 2012, at 2:51 PM, Kevin Smith wrote:


Are your first two points talking about site specific exceptions, or alternate opt-ins provided directly by the 1stparty?  Regardless, I think the answer is yes, a dynamically generated doc at a well-known URI could absolutely do these things, however, the extent to which it must be generated dynamically also increases the percentage of time that it needs to be requested

From: Nicholas Doty [mailto:npdoty@w3.org]
Sent: Monday, March 05, 2012 3:26 PM
To: Ronan Heffernan; public-tracking@w3.org<mailto:public-tracking@w3.org> (public-tracking@w3.org<mailto:public-tracking@w3.org>)
Subject: Re: Well-known URI vs response headers? [ISSUE-81, ISSUE-47, ISSUE-80]

[I recently discovered that part of this thread from October wasn't shared with the public list due to an address mix-up. With Ronan's permission, I'm sending these messages to the public list now; I think these questions are still relevant, though some points are of course affected by the details of the well-known URI proposal as published by Roy in February.
On Oct 27, 2011, at 8:05 PM, Nicholas Doty wrote:]

I'm not convinced that a well-known location alone (even if dynamically generated) has enough granularity to communicate to the user what's going on.

* How often should the user agent load the well-known location to check whether a tracking party has registered an opt-back-in?
* Can a user opt-back-in to trackers only for a particular site? (The New York Times asks me to consent to tracking, I trust their decision and accept that third parties will track me on their site, but don't expect to be tracked by the same parties on other sites.)
* Could a well-known URI tell the user that some items on a page are tracking her and others aren't? (I click a widget -- the tracking party decides it can track me under a first-party exception, say -- on a page that also has a 1x1 pixel gif from the same tracking party.)
* Will a tracking party that uses LSOs, browser fingerprinting or some other non-cookie technology be able to distinguish users who later access the well-known location? If the opt-back-in is communicated via postMessage or stored in localStorage, how will the well-known location script inform the user that they're opted back in?

Thanks,
Nick
Received on Monday, 5 March 2012 23:49:44 UTC

This archive was generated by hypermail 2.3.1 : Friday, 21 June 2013 10:11:26 UTC