Re: DNT Compliance and Audit Services (ACTION-56, ISSUE-21)

Like Shane, I think that this proposal would create unnecessary
implementation overhead if included in the specification.

I want to enable various levels of validation of DNT, from users
checking for a response header, auditors like TRUSTe certifying
implementors, to regulators investigating bad actors. That's why I think
that we should require a response header, because it's the baseline,
meeting the primary needs of users, and supporting others.

I think that a machine-readable tracking policy is an interesting
prospect; it might be a valuable hook for auditors and audit validation
by users. I'm all for putting options, and bright lines in the spec to
make audit/validation easier, and I absolutely want to make sure that
everyone from users to regulators and auditors can make appropriate
checks for DNT. However, I think that designing a machine-readable
tracking policy statement is explicitly out-of-scope.

Nonetheless, Kevin, if you want to design an open spec for one, I'm sure
there will be some adopters, and it could certainly push competition to
get audited.



On 01/31/2012 08:06 PM, Shane Wiley wrote:
> Kevin,
> 
> Thank you for providing a compliance and audit draft structure where TRUSTe clearly has considerable history.  At a high-level I believe the level of complexity this brings to the DNT standard (in some areas of your text below) would not be warranted and in many cases could be built outside of the standard itself.  For example, TRUSTe could build a DNT certification program that would add many elements you've outlined below but not necessarily need to live within the standard itself.  This offers the marketplace flexibility to allow alternate compliance and audit services to emerge and evolve.  That said, this sounds like a great start to one particular method of developing a DNT compliance approach.
> 
> I've only responded to the first half and will address the second half of the proposed text at another time if the working group feels this is an appropriate element of the DNT standard.
> 
> Please see comments in-line below in [ ]:
> 
> A lot of text here, much of it non-normative, but the intent was to provide a foundation for defining compliance and audit services that later can be distilled and captured into the Compliance document. It does have a linkage to the response header thread in the TPE doc. A natural offspring of this discussion was the tracking policy, so there is strawman list of components provided at the end for a starting point.
> 
> <Description>
> To ensure the integrity of the DNT system, a compliance regime is necessary for the various stakeholders.
> 
> [I don't believe a compliance regime is "necessary" but definitely "preferred".  There are other forces that are able to be brought to bear to ensure integrity of the DNT standard: Legal, other technical standards, privacy enhancing tools, etc.]
> 
> Ultimately, data collection and usage involves systems that exhibit certain externally observable behavior, but primarily involves proprietary data systems that are not observable. 
> 
> [Collection to some degree is externally observable (you can view data being sent in requests/responses, but internal "usage" is not.]
>  
> As such, two possible mechanisms for compliance can exist: 1) external monitoring capabilities and 2) audit and oversight.   A complement of both systems is recommended for DNT and each will be discussed below.
>  
> [I would suggest we focus on signals that can be monitored externally as this is necessary for User Agents as well as 3rd party audit services.  I don't believe "Audit and Oversight" are within the scope of DNT and can be built by many parties outside of this forum (I have every confidence that this will occur rapidly as a revenue generating service for many existing privacy and security audit firms).]
>  
> <External Compliance Mechanisms>
> Note: Compliance systems can be provided in various manners, and for completeness, each will be discussed, though some of these are ultimately user agent or potential third party add-ons implementation specifications or recommendations.
>  
> It should be emphasized that a Compliance agents may provide more advanced technological monitoring and analysis than the typical user agent and user.  As such, the "user" for the DNT system should be considered a separate entity from the Compliance agent.  Requirements for certain specifications for DNT can be assumed to be present for both, but potentially only used by a Compliance agent.
> 
> A firm requirement for any compliance monitoring is a response header from the server universally across the system.
> 
> [Compliance "services" themselves are not necessary for DNT standard compliance, so I would argue this still places Header Responses as a "SHOULD" and not a "MUST".] 
> 
> 1.              User.  At this level, compliance is defined as a set of interfaces to allow the user to be aware of any conflicts in their preferences and an audit file of all exhibited behavior so the user can self-audit.  Examples include:
> 	a.     The user agent should provide a user clean simple methods to ensure her DNT preferences are honored with appropriate first and third parties. 
> 	b.     The user agent should alert the user of any conflicts that exceed the user's expectations, for example, when a user preference of DNT:1 is responded to with an 	exception,  especially if that exception is not registered in the user agent or if it was agreed to outside the DNT user agent system.
> 
> [Out of band exception responses have already been proposed in Tom's draft so I believe that meets your requirements here.]
> 
> 		i.	The user agent should record all DNT interactions much like a current cookie history.
> 
> [Could you explain this in a bit more detail?  Are you requesting that User Agents log DNT interactions so that your audit service can be automated?  I would suggest this is a MAY at best and completely up to browser vendors to determine if they want to do this.  Interestingly this is a "Tracking Do Not Track" request :-). ]
> 
>         	ii.     The user agent should easily provide info to the user where they can interact directly with the tracking party for more details.
> 
> [This is beginning to prescribe a UI for User Agents, something the working group has stated is outside the scope of the standard.]
> 
> 	c.      Browser Add-ons should have access to this data to provide more granular features for interested users.
>  
> [Again, at best a MAY and completely up to browser vendors to determine if they want to build these features into their products.  It is NOT necessary for baseline DNT standard compliance.]
> 
> 2.             First Party (e.g., Publisher)
> 	a.     A first party may wish to monitor the behavior of third parties on their property to ensure their privacy policy covers all behavior on its web property and that only compliant third parties are present. 
> 
> [Some support for this is already built into the Site-Specific Exceptions draft.  There are limits to party determination via a User Agent (outside of top DOM parent/origin) so it's not expressly technically feasible to do this within the HTTP standard today.]
> 
> 	b.     This type monitoring would involve the ability to monitor all http requests and responses from third parties on the publisher's site.
> 
> [Outside of the scope of DNT but you can accomplish this with any readily available packet sniffer.]
> 
> 	c.     This also includes third parties working in a data processor construct, and both authorized and unauthorized third parties.
>  
> [This will be more difficult to ascertain technically but is an area I'm also interested in exploring outside of DNT.  As a 1st party, we know the 3rd parties that we've contracted with and are okay with being on our site, but outside of using external scanners on our own properties, it's difficult for us to discover unwelcomed 3rd parties on our sites.]
> 
> 3.             Compliance Authority
> 	a.     All tracking responses MUST include a DNT response header to enable external auditing by a compliance authority.
> 
> [A compliance vendor can make this assertion (MUST) but the standard should not.  If an organization wants to purchase compliance services, it makes sense to make this part of the deal.]
> 
> 	b.     A compliance authority via a user agent add-on or independent external monitoring service can monitor header responses based on certain user agent personas, e.g, where DNT:1 and DNT:0 are used to view the header responses and compare the response behaviors.
> 
> [Nice idea - will most likely require browser vendors to develop hooks to allow this.]
> 
> 	c.      If exceptions are stated, the compliance authority will want to view and understand the machine-readable tracking statement and available privacy policies in a scalable automated fashion.
> 
> [Allowances have been made for this - both through Site-Specific Exceptions and through Out of Band Exceptions.]
> 
>         	  i.     Suggested elements for this policy included below as sample.
> 	d.     Additionally, in certain jurisdictions it may be relevant to monitor the base state response from servers for all users, regardless of DNT user agent settings, to ensure compliance to prior explicit consent mechanisms are in place.
> 
> [Easily accomplished outside of the DNT standard.]
>  
> It should be noted that in all instances these DNT response headers and tracking policies are assumed to be self-asserted technical mechanisms of compliance that are supported by any publicly facing tracking or privacy statements.
> 
> [There SHOULD be other options outside of Response Headers such as Privacy Policy statements.]
>  
>