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

Lauren,

You make the perfect argument to allow Response Headers to be optional (SHOULD).

As you state, if a company does not create a response header, then the user agent will be forced to communicate to users that they did not receive a response header and the user should consider the site to NOT support DNT.  If a company has gone through the work to develop DNT support, they'll most likely develop response headers as well to avoid user confusion.

As it's a self-supporting incentive model, there is no reason to force a MUST in this situation and allow natural market forces to drive implementation in this regard.  Therefore a SHOULD meets the need.

- Shane

-----Original Message-----
From: Lauren Gelman [mailto:gelman@blurryedge.com] 
Sent: Tuesday, February 07, 2012 10:29 PM
To: Roy T. Fielding
Cc: David Singer; Tracking Protection Working Group WG
Subject: Re: Agenda for 2012-02-01 call (V02: added more incoming issues with text)


I briefly was the co-owner of www.p3psearch.com back when it was introduced and we had a plan for a privacy portal (this was when portals were popular and it was trivial to build a java search engine). My belief was, and still is, that no privacy solution will ever have any chance to work unless people have some ability to shop based on privacy. "Find my a box of huggies at the store that best protects privacy."  It needs to be that simple.  We decided not to do a start-up for other reasons, but wish we had done it or someone else had.  I have since tried to work with start-ups, browsers, anyone who can actually turn a person's interest in purchasing from a privacy friendly entity into a reality.  The MAIN impediment is privacy policies.  No one shops based on privacy policies because no one has any idea how to parse them.  [sorry-- i am not going to reference the ridiculous amount of data on this subject.  If you disagree, show one to your mom and ask her who the company shares data with and under what conditions].

As I understand it, the response header is the only option on the table for a machine readable assertion that a company is DNT compliant.  This can be used to allow people to make decisions based on DNT:1 and to create an audit trail.  This can create incentives for companies to want to say they are DNT:1 and do the innovation necessary to make it happen.  If this procedure relies on privacy policies, it will fail.  Privacy policies are written to make the least factual assertions about a product in order to avoid any misrepresentations. I have not seen anything in these discussions that would make me advise a company to write in their PP that they are DNT:1.

Unless IAB or other organizations are planning to condition membership on compliance.  But if that was the case, wouldn't they want a MUST?  Otherwise they will have the same problem auditing to determine if their companies are complying.



On Feb 7, 2012, at 6:13 PM, Roy T. Fielding wrote:

> On Feb 7, 2012, at 9:50 AM, David Singer wrote:
>> The absence of a response header does have the huge downside that there is no 'automated discovery' of compliance in the transaction, and UAs that rely on that will assume the worst.  If we go with SHOULD, this needs clearly stating.
> 
> There is no automated discovery of compliance in headers, regardless.
> Compliance to requirements that apply over time and across multiple
> requests can only be detected by observing behavior over time and
> multiple requests.  Just because a header says that the server complies
> does not mean the server complies.  UAs that actually depend on compliance
> should be checking against a curated list, just like fraud avoidance.
> 
> IMO, the response header is a complete waste of time and bytes.  It is
> a very expensive delusion.
> 
> In the entire history of HTTP, the only other protocols that defined a
> response header to indicated compliance were MIME-version (ignored),
> DAV (ignored), PICS (failed), and P3P (ignored).  I don't understand why
> this WG needs to make the same mistake.
> 
> ....Roy
> 
> 

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

Received on Wednesday, 8 February 2012 06:42:55 UTC