RE: Agenda for 2012-02-01 call (V02: added more incoming issues with text)

Lauren,

Response headers will be an expensive implementation for many organizations.  The logic of the SHOULD is that an organization can declare their support for DNT in their privacy policy or in other locations and be following all the rules internally - just not yet having developed the response header.  The response header is a NICE TO HAVE but not necessary to comply with the guidelines surrounding DNT (unless of course we say the response header is a requirement).

- Shane

From: Lauren Gelman [mailto:gelman@blurryedge.com]
Sent: Monday, February 06, 2012 9:27 PM
To: Shane Wiley
Cc: David Singer; Matthias Schunter; Tracking Protection Working Group WG
Subject: Re: Agenda for 2012-02-01 call (V02: added more incoming issues with text)


I am having problems with the logic of using a SHOULD given that the standard is optional to begin with.

I understood the response header is the affirmative statement where a company says "I am DNT compliant."  So if a response header is not required, what is the difference between a company that chooses not to be DNT compliant and a company that chooses to be DNT compliant but doesn't send a response header because it is not mandatory?

How would I as a user know the difference?

On Feb 6, 2012, at 7:11 PM, Shane Wiley wrote:


The difficulty with time bounding is that its arbitrary.  I would rather promote this as the "best practice" and then allow large organizations to help develop technology in this area for dissemination to the rest of the world (Apache and IIS packages, for example).

The proposal is not linked to a specific response - or rather response headers SHOULD be an option for all transactions (where appropriate - being sensitive to the caching discussions).  I'm not sure I follow your logic - in both cases where a company is choosing to not comply or has not yet complied, then there would be no response header...?

- Shane

From: Lauren Gelman [mailto:gelman@blurryedge.com]
Sent: Monday, February 06, 2012 6:05 PM
To: Shane Wiley
Cc: David Singer; Matthias Schunter; Tracking Protection Working Group WG
Subject: Re: Agenda for 2012-02-01 call (V02: added more incoming issues with text)


Could there be a time period at which SHOULD--> MUST?  I think you are right about adoption in terms of mind-share, but in terms of actual adoption engineers need to prioritize.

Also, is this linked to the proposal for a DNT:2 option?  Otherwise the response header can never be the last word on compliance if there is no way to distinguish between a company who is choosing not to comply and a company that has not yet complied.

On Jan 31, 2012, at 7:22 AM, Shane Wiley wrote:



To add more to the SHOULD side of the discussion:

By allowing a SHOULD on response headers will allow companies across the globe, large and small, as well as trade organizations, to immediately embrace the DNT standard, move forward with implementations, and include DNT in Codes of Conduct.

If we move forward with a MUST on response headers, it may prove to be a motivator for implementation but will likely take months and years for full compliance.  Large companies will move forward with implementation of response headers regardless of the SHOULD/MUST outcome, but I fear that regulators and some advocates will deem this working group's efforts a failure if industry-wide support of DNT drags on for an extended period of time.  There are natural incentives to support response headers (as the draft text points out) so I would suggest we allow these market forces to drive the appropriate outcome.

- Shane

From: David Singer [mailto:singer@apple.com]
Sent: Tuesday, January 31, 2012 7:43 AM
To: Matthias Schunter
Cc: Tracking Protection Working Group WG
Subject: Re: Agenda for 2012-02-01 call (V02: added more incoming issues with text)


On Jan 31, 2012, at 13:12 , Matthias Schunter wrote:





7. Collect arguments "SHOULD" vs. "MUST" for response headers
    https://www.w3.org/2011/tracking-protection/track/issues/120


Since I can't be on the call...

Background: We have a service that claims compliance to the protocol, responding to a DNT request.

If the response header is only a SHOULD, then we need to define a default.  We could say "for cacheable objects, the default value is "not trackable"; for all others it is "I may be tracking you (claiming all possible exceptions)".  The UA will have to work out whether the service is 1st or 3rd party, to work out which set of exceptions are possibly claimed.  In addition, it's possible that the entity determining the default is not able to see the cache headers (there were discarded by the HTTP end-point) and that it therefore erroneously concludes that untrackable resources are potentially being tracked.

The advantage of a SHOULD is that the service only needs to add the header in the systems that handle tracking; ordinary (cacheable) resource delivery would not need any engineering changes, to remain in compliance (even if that's dangerous).

David Singer
Multimedia and Software Standards, Apple Inc.


Lauren Gelman
BlurryEdge Strategies
415-627-8512
gelman@blurryedge.com<mailto:gelman@blurryedge.com>
http://blurryedge.com<http://blurryedge.com/>


Lauren Gelman
BlurryEdge Strategies
415-627-8512
gelman@blurryedge.com<mailto:gelman@blurryedge.com>
http://blurryedge.com