- From: Shane Wiley <wileys@yahoo-inc.com>
- Date: Wed, 11 Apr 2012 11:40:05 -0700
- To: Peter Eckersley <peter.eckersley@gmail.com>, Tracking Protection Working Group WG <public-tracking@w3.org>
- Message-ID: <63294A1959410048A33AEE161379C8023D11A993A8@SP2-EX07VS02.ds.corp.yahoo.com>
We're unable to accept this draft. :( I'd rather we leverage the text that Jonathan and I originally used to highlight that a 3rd party should be able to identify its activities as a 3rd party in most situations. There are edge cases where content can be re-hosted outside of 1st party knowledge (iFraming, Mashable, etc.) thus making it 3rd party but we agreed to not attempt to cripple legitimate 1st party practices for these outcomes. I further offered non-normative text on methods for 3rd parties to know they are 3rd parties in most cases (known 3rd party vs. accidental 3rd party). - Shane From: Peter Eckersley [mailto:peter.eckersley@gmail.com] Sent: Wednesday, April 11, 2012 2:23 PM To: Tracking Protection Working Group WG Subject: ISSUE-60: proposed to close Issue 60 raises the question of whether a recipient of a DNT: 1 header knows whether it is in fact a first or a third party. This can in some instances be ambiguous: for instance a host of an image may not be able to tell the difference between users who follow a hyperlink to that image (in which case they host is a 1st party) and users who are seeing the image randomly embedded on some other page (in which case the host is arguably a 3rd party) The text that Tom, Jonathan and I drafted resolves this with the following language: A "first party" is any party, in a specific network interaction, that can infer with high probability that the user knowingly and intentionally communicated with it. Otherwise, a party is a third party. A "third party" is any party, in a specific network interaction, that cannot infer with high probability that the user knowingly and intentionally communicated with it. If the authors of other drafts are willing to accept our "high probability" standard for resolving this issue, it can be closed. -- Peter
Received on Wednesday, 11 April 2012 18:41:11 UTC