RE: Work ahead; volunteers?

Kevin,

You've asked a lot of questions below but rather than address them individually I've tried to summarize my perspective to hopefully address your questions.

My goal in these requests (DNT:2, Server-Side Site Specific Exception requests) is too provide Publishers with implementation options as the vast majority of the DNT implementation overhead is being shouldered by this portion of the ecosystem.  (To be fair, web browser vendors have a lot of work to do here as well but there are fewer than 10 of those for the most part.)

Publishers should have the option to direct the user experience based on the preferences presented by users:

- DNT:0 (do nothing)
- DNT:1 (redirect user to a site-specific exception request experience)
- DNT:2 (decide to allow the user to continue unchecked or redirect to a site-specific exception request)

Note:  Publishers have many options here - pay walls, reduced experiences, blocking access, showing more ads, do nothing, etc. - only time will tell which ones emerge as preferred approaches by Publishers.

The Publisher will be able to make many of these choices PRIOR to determining what page to send back to a user as the DNT status for that domain is sent with the publisher page request -- before a resulting page is sent back to the user for loading.  

I'm not suggesting that 3rd parties are somehow determined dynamically by a Publisher - many of us know the 3rd parties that we work with and often have contracts with those parties.  These are the parties for which I care about obtaining a site-specific exception.  If an unknown 3rd party is present on the page (via beacon piggybacking for example) I don't care if they receive an exception and in many cases would actually prefer they receive the DNT:1 signal.  This is the argument against "*.domain.com" exception requests.

I like the idea of simplicity but want to be careful we're not robbing millions of publishers of flexible options because a few publishers in the WG aren't interested in having those options for themselves.  

- Shane

-----Original Message-----
From: Kevin Smith [mailto:kevsmith@adobe.com] 
Sent: Tuesday, March 06, 2012 3:31 PM
To: Shane Wiley; Matthias Schunter; public-tracking@w3.org
Subject: RE: Work ahead; volunteers?

I am not making any claims for Adobe at this point, nor am I disputing that from a business logic perspective, a site may be willing to offer various levels of content for various levels of exceptions.  Conceptually that makes great sense.  Nor am I disputing that there will be simple cases where none of my concerns are valid.  What I am saying is that 

1) In many cases it will not be technically feasible to know ahead of time what 3rd parties will be included by the time a given page has fully loaded - what good will your DNT:2 header or the API be if you do not know which 3rd parties to ask for.  
2) The cost for enterprise level sites to support partial exceptions would far outweigh the benefit (or opportunity cost) which could be acquired by partially monetizing visitors unless visitors with DNT:1 enabled make up a very significant percentage of traffic

Shane, pick a Yahoo property and ask yourself the following questions (rhetorical - you don't need to answer to the group):
* What advantages does Yahoo really get for offering an exception at all?  Would it not make more sense to the bottom line to simply state that your page requires tracking to be able to function (it probably already does this if it sees javascript or cookies disabled - I am guessing you do not make two complete versions of your sites anymore - one for JS and one for non-js.  Would you be willing to do so for DNT:1?)
* Are you really willing to change your data storage structures,  storage mechanisms, retrieval mechanisms and various internal processes to handle data differently when it comes in with DNT:1?  Or would you rather throw away that visitor or hit completely?

I am guessing the answers to these questions are threshold based.  Would you be willing to make the adjustments above for .01% of your traffic?  1%?  5%?  20%?

* If you are willing to offer an exception, how much more willing would you be if you could handle it server side with a single Boolean value - this is what I do when my 3rd parties can track, this is what I do when my 3rd parties cannot track?  Or how much less willing would you be to handle it exception by exception, page by page and have to update your entire front end?  (ie - handle DNT with a single site wide gateway, or customize each page?)
* How will you decide what content to show based on a response of 'some but not all of your 3rd parties have exceptions'?  
* Are you really willing to do all of your dnt-exception handling and dnt-exception based navigation client-side.  Do you use any sort of tag manager?  If so, are you willing to get rid of it?

I am guessing that the threshold percentage from the above tests continues to go up as you factor in these additional costs.  Again, I am not necessarily against allowing the array of 3rd parties to be passed in, I am stating that it will rarely be used by large companies and therefore should have a default of '*'.  However, if we axe it completely, a lot of issues gets simpler.  For instance, you do not need your DNT:2 header anymore, nor do you need the JS API.  We are back to DNT:1 or 0.


-kevin

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

Kevin,

I'm not sure I agree but haven't canvassed enough large first parties to have developed a broader point of view.  I can see real situations where users reject exceptions for one or two 3rd parties and that a publisher would be okay with that if the bulk of their business is with others and/or they can dynamically decide to only call for ads from those 3rd parties that have been granted exceptions.  Are you stating that Adobe will only go for an "all or nothing" approach for 3rd party site specific exceptions?

Thank you,
Shane

-----Original Message-----
From: Kevin Smith [mailto:kevsmith@adobe.com] 
Sent: Tuesday, March 06, 2012 12:10 PM
To: Shane Wiley; Matthias Schunter; public-tracking@w3.org
Subject: 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 Wednesday, 7 March 2012 04:12:22 UTC