Thank you Nick. I believe this was similarly assigned to me via an email from Matthias titled: " How can a server understand the site-specific exceptions that are stored in a user agent (was: Work ahead; volunteers?)". Do you agree that email covers the items you've outlined below? If you agree, I'll work on responding to the email Matthias sent (including draft text).
Thank you again,
- Shane
-----Original Message-----
From: Nicholas Doty [mailto:npdoty@w3.org]
Sent: Tuesday, March 06, 2012 7:43 PM
To: Shane Wiley
Cc: Matthias Schunter; Andy Zeigler; public-tracking@w3.org (public-tracking@w3.org)
Subject: Re: set of exceptions
We had ISSUE-109 to track the specific question about the existence of a JavaScript-accessible list property. We had a proposal to remove that particular property (I believe user agent developers agreed that the functionality could be achieved using the request() method and that the fingerprinting risk of the list was large) which was included in the recent updated JS proposal from Tom, Andy and me.
I believe Matthias has folded this into ISSUE-111. Whichever issue it's tracked in, Shane, do you want to provide alternate text as an option in the draft? (Maybe you just want the list property text exactly as it was before, or maybe you have comments on using the request() method or maybe something else entirely.)
Thanks,
Nick
On Mar 6, 2012, at 6:59 AM, 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
Forwarded message 1
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.*"
>
>
>
>
>