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

Are your first two points talking about site specific exceptions, or alternate opt-ins provided directly by the 1st party?  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 (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

On Oct 27, 2011, at 6:31 PM, Ronan Heffernan wrote:


There is no reason why the well-known URI is limited to sending the generic organization-level policy.  If there is user-specific information in a cookie, header, etc., then the well-known location can be a script that performs the same kind of lookup that will be performed by information-gathering elements, and the actual way that that user will be treated can be emitted from the well-known location.

--Ronan Heffernan

On Thu, Oct 27, 2011 at 6:45 PM, Shane Wiley <wileys@yahoo-inc.com<mailto:wileys@yahoo-inc.com>> wrote:

Roy,

I like the simplicity of the known location approach (suggest we do this no matter what - need to think through DBCS/non-English URLs which are now supported) but question if it would allow automated testing/scanning for audit & enforcement purposes - as it appears this approach would require a manual review process. One of the goals in suggesting a header response was to provide a real-time check-point to the browser/app/user that their signal was received and honored (or not) -- this would be on a per user basis versus a DNT URI that would describe an organizations general support (or not) of DNT.  Could you explain the caching issues in more detail that plagued P3P?  I'm interested to understand if these are corner case situations or have broad (high %) implications.

Thank you,
Shane