Re: ACTION-114 ISSUE-107 : Revised response header.

I wanted to put a few more thoughts into the pile around response headers....but I have to admit, I am a little confused between MUST vs. SHOULD as it relates to conformance to the overall standard and the technical requirements...I think a few are discussing that right now in another thread.  Seems like a good think to clarify on the call today.



As I think about response headers, I am trying to envision the use cases for the consumption of them, to understand the actual need for them in the differing user/server interactions.  To me, transparency (Issue-8) starts to blur with Enforcement/Compliance and our response header requirements.  A lot of this depends on whether the user agent will make available certain features or not, and I know this is out of scope for what we are doing, but it informs the usefulness of our requirements so I'll re-frame it in that context to lead to some logic.

I'll take these the first two areas and start with some questions and then try and explain certain scenarios that would drive differing requirement scenarios.  From the response header perspective, I am taking the lens that turning on the response header is "not free", so it shouldn't be required if not used in some way.


1.	Transparency

Feature Questions:
a.	Do we wish to enable the user agent to let the user know when any form of tracking is occurring (per DNT definitions)?
b.	Do we wish to enable the user agent to let the user know when an exception occurs that exceeds their expectation? I define this as the user saying "don't track me" and for any reason the user gets a response that says, "I heard you but we are still tracking you according to some reason in the Compliance document that says we can."

I think a) is something that is already in progress of rolling out from the ad industry - the icon system whereby ad companies are telling users that their profile is currently in use and they have a choice to opt-out if they can.  In the DNT world, which would theoretically expand to beyond display ad functions, this would be the same as saying: "you have not turned on your DNT feature, but we are tracking you and sending a response header as a courtesy to let you know."  However, if the user can't see this in the user agent, then this is useless from a transparency perspective and is moot.  

The current requirement is that a third party MAY send a response when DNT is not turned on, which seems appropriate UNLESS we want to mimic the icon behavior for transparency.  This also brings up a bootstrap problem because if the typical user does not go into his browser settings to turn on DNT AND there is no server response when DNT is not turned on, very few users will ever naturally discover this system.  IMO, the fundamental level of transparency should be "You are being tracked and you have a choice in the matter.  If you are so inclined, you can go into your browser to set your preference."

b) to me is where we need to think about this a little different.  This is the case that I think consumers will react negatively, even if there is a good reason behind this (per our definition).  But, to me, some form of interaction is a MUST in this case: if we have an exception and we disregard the user wishes, then we NEED to tell them and give them the option to find out more info should they care.

Accordingly, from a transparency-only perspective, I would argue that if a user says "Don't track me" and the user's wishes are honored, then there is no reason to repeatedly tell the user that as it is in accordance with their expectations.  But, it would be nice to do that from a trust perspective so they can feel good about it. An example here is the location arrow on IOS phones. So, in that case, I think SHOULD or even MAY makes sense depending on what the user agent plans to do with it.  


2.	Enforcement/Compliance

Feature Questions:
a.	Is the user agent going to provide some mechanism to enforce compliance to the standard?
b.	What controls are in place for the user to manage exceptions?
c.	What is role of compliance agent vs. a typical user?

If the user agent is going to help assist the user with dealing with only DNT-compliant companies, then some form of technical signal is necessary to do this. We discussed the following options including combinations:

1.	response header
2.	tracking policy (machine readable)
3.	Privacy policy (human readable)

Each of these presents a balance of implementation cost (adding the header to transactions), management complexity (keeping policy accurate in place) and contributory value to compliance or user controls.

As per a) if the user agent does in fact want to help users navigate those companies that are DNT or not, then it can be done one of two ways.  One is the 2) tracking policy that can be read the first time a tracker is discovered by the user agent.  The second is requiring a header for each transaction.  Per above, ensuring compliance for each transaction seems extraneous if the organization is simply saying "my organization is compliant with DNT."  So, this seems most practically handled by a tracking policy, or even a DNT-compliant list curated by a trusted third part(ies).  Are there reasons an organization would want to separate compliance by transaction type, assuming it comes from the same [tracking] domain?  Maybe the frequency capping discussion?  (see thread on URI vs. header).

Following the transparency discussion above, if another goal of the user agent is to b) provide controls to the user to manage exceptions, then having a way to see an exceptions seems like an important element for users to decide:
1) Why are you still tracking me? [read exception text]
2) Can I still override this exception? [I am a privacy zealot and want absolutely no tracking whatsoever and might even pay for this content if you really push me]

This would argue for the existence of a simple tracking policy and a easy-to-find link to it (either embedded in the header or at a well-known location).  If we just rely on the existing privacy policy framework, we are taking steps backwards, as I would feel some obligation as part of this group to at least improve the tracking elements of a privacy policy so people can understand what is going on as part of this system. I think the header pointer is redundant assuming the well known location is known to the user agent.

For c) compliance monitoring, I assume as long as an agent can "log" the transaction request and response, then the tracking file can be found and read asynchronously as needed, so there is no need for including this in the header.   More generally, searching for DNT compliance can be done by simply looking at tracking policies, in particular when exceptions are fired.  Where this needs more granular tracking is to look for tracking domains that do not have tracking policies associated with them, in particular those responding with exceptions.



Summarizing my points for what I see as a baseline requirements:

1.	A tracking policy in a well-known location seems like a MUST.  This implies the policy has something in it to identify it as such to a user agent.  "I am a tracking policy for TrackingCo.com."  
2.	A machine readable tracking policy seems like a SHOULD.  (i.e., certain disclosures can be read by an external agent, perhaps exception codes)
3.	A response header for exceptions seems like a MUST. No pointer is necessary.
4.	A response header for non-exceptions seems like a MAY or SHOULD.

Open Questions that could lead to alternative conclusions:

1.	What are the use cases for requiring a response header in the "meets user expectations" situation?  
- Transparency
- User agent compliance enforcement (filtering DNT-compliant trackers from non-compliant ones)
- Regulatory/compliance agent requirements
2.	Is transparency a true goal of DNT -- or is just the choice framework the primary goal?  This clearly has impacts on the response header requirements and could make them all MUST.
3.	What happens when a user doesn't agree with an exception and still does not want to be tracked?  



On Feb 3, 2012, at 3:01 PM, Tom Lowenthal wrote:

> ACTION-114 ISSUE-107 ISSUE-47 ISSUE-48 ISSUE-51 ISSUE-76 ISSUE-90
> ISSUE-106 ISSUE-45
> 
> Here is the latest version of the response header. I've also added it to
> the action on the tracker.
> 
> Editors: it is in markdown, but *do not panic*, any of us can convert it
> to HTML at a moment's notice.
> <dnt-response-2.2.md>

Received on Wednesday, 8 February 2012 20:01:00 UTC