RE: Work ahead; volunteers?

I actually do not think the API is necessary because 1st parties are not going to be willing to ask for exceptions on a per 3rd party basis.  They will only use the '*' option which means we only need an API to see whether there is an exception for the 1st party, which does not have any finger printing risk. 

-----Original Message-----
From: Shane Wiley [mailto:wileys@yahoo-inc.com] 
Sent: Tuesday, March 06, 2012 7:59 AM
To: Matthias Schunter; public-tracking@w3.org
Subject: RE: Work ahead; volunteers?

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.*"

Received on Tuesday, 6 March 2012 17:11:06 UTC