Hi Shane,
ISSUE ADMIN:
thanks for pointing this out. I've now broadened ISSUE-111 to act as a
container for the discussion how a server can learn about exceptions
(via header, Javascript, or other mechanisms not yet discussed) and
closed ISSUE-109.
https://www.w3.org/2011/tracking-protection/track/issues/111
WAY FORWARD:
Could you reply with some examples why a server may be interested in
learning the exceptions? I want to understand these usecases and how
they might be implemented. If we find important usecases that are not
addressed by the current spec, we may add additional mechanisms.
USECASES
Usecase 1: A first party may want to understand whether its third
party elements continue to work or not (=what subset is exempted).
MEANS-A: The server may call the site-specific exception API and
obtain a result (either entered by the user or else cached).
Regards,
matthias
On 3/6/2012 3:59 PM, Shane Wiley wrote:
> Matthias,
>
> I don't believe the following issue is closed (or if it is, I'll propose we reopen the issue as Server-Side interrogation of site-specific exceptions will be an important option -- bad actors can find numerous other ways to digitally fingerprint a user's system and I believe we've agreed to not cripple the DNT standard in attempts to manage bad actors).
>
> "- we decided not to provide an API for retrieving the set
> of exceptions for a server due to the resulting finger
> printing risks"
>
> - Shane
>
> -----Original Message-----
> From: Matthias Schunter [mailto:mts@zurich.ibm.com]
> Sent: Tuesday, March 06, 2012 9:03 AM
> To: public-tracking@w3.org
> Subject: TPE: Work ahead; volunteers?
>
> Hi Folks,
>
>
> Enclosed is a summary list of areas where I believe more work is
> needed in order to create a complete and stable draft for the TPE
> document.
>
> If you want to volunteer to push one of these areas or if you want to
> propose an action for one of them, please drop me a line.
>
> Once we shipped the current draft, we need to tackle these open
> questions to finalize our spec.
>
>
> Regards,
> matthias
>
> PS: Please drop me a line if I overlooked an area of if one of these
> areas has been resolve (with me overlooking the emails)
>
>
> ---8<---
> -----------------------------------------------------
> [Sec 4.3: Querying DNT request header via Javascript]
> -----------------------------------------------------
> - ISSUE-116: Can we build an API that works reliably?
>
> ------------------------------------------------------
> [Sec 5: Server responses to user agent]
> ------------------------------------------------------
>
> The goal of this section is to define mechanisms to tell a user agent
> to what extent his preferences are followed.
>
> We have designed
> - A proposal for response headers
> - A proposal for posting information at a well-known URI
>
> Questions:
> - Which of the following options to choose:
> - Headers-only, URI-only, or both
> - What is the minimal data attached to a response.
> The URIs propose a very rich set while the headers remain slim.
> Example data that has been proposed by the URIs:
> - List of associated sites
> - List of partner sites
> - URL to an info page
> - URL to an opt-in and opt-out page
> - URL to the policy
> - Extensions
> - If we choose headers+URI: What is the best interplay
> between them
>
> -----------------------------------------------------
> [Sec 6: Informing the Server about Site-specific Exceptions]
> -----------------------------------------------------
>
> In this area,
> - we created a Javascript API that allows a server to ask for
> exceptions (Section 6)
> - we decided not to provide an API for retrieving the set
> of exceptions for a server due to the resulting finger
> printing risks
>
> Open questions 1: Informing the server about exceptions
> - ISSUE-111: Different DNT value
> - ISSUE-84: API call that allows server to query
>
> Open Question 2:
> - ISSUE-113: Should we allow for global exceptions
> of the form like "thirdparty.*"
>
>
>
>
>