ACTION-203 : Text for transitive model

Hi Shane, 

ACTION-203 was opened to get the transitive permissions of explicit/explicit 
or side wide exceptions into the Specification. I hereby provide a first 
DRAFT and would like you to check whether this works with the current system 
and if not to identify whether there will be a hard problem or just some 
adaption of the networks necessary. 

The issue was created in the Discussion on 23 May [1] by the suggestion from 
David Singer about what will happen when an exception is granted and then 
when it is removed [2] which is related to ACTION-176 and ACTION-183. I 
would like to attach this to ISSUE-140. But it is also related to ISSUE-143 
and ISSUE-147 that is raised but not open. 

The issue arises mainly out of the consent use case. In a US context, DNT;0 
means falling back to the situation of non-existing rules. In the EU falling 
back to the rule-system doesn't work. So DNT;0 needs a meaning beyond 
falling back to the legal system. DNT;0 needs a positive description of what 
is _at least_ permitted (open model within the constraints of a given legal 
system the site is operating in). We are struggling with this meaning and 
the current action item is one aspect of it. 

What I try to achieve with my suggested wording is to create the necessary 
semantics attached to the DNT;0 expression to allow for extended analytics 
and targeted advertisement, including catering to the current auction 
systems. All points remaining open in my definition fall back to the legal 
system one is operating in. Because (informed) consent trumps nearly 
everything, this works in 99% of the cases. The "informed" is solved because 
we define here a fixed meaning for the exchanged tokens and this meaning is 
assumed to be known.

Goal of the wording is also to make the system practical. A first party may 
know the services they are using on their site. But they don't know the sub-
systems and sub-sub-systems used in a particular case. They can't know in 
advance. The transitive nature of the consent given resolves that. It also 
comes with limitations that allow users to still feel confident despite 
their allowance being transitive. 


A site may request an exception for one or more third party services used in 
conjunction with its own offer. Those third party services may wish to use 
other third parties to complete the request in a chain of interactions. The 
first party will not necessarily know in advance whether a known third party 
will use some other third parties. 

If a user-agent sends a tracking exception to a given combination of origin 
server and a named third party, the user agent will send DNT;0 to that named 
third party. By receiving the DNT;0 header, the named third party acquires 
the permission to track the user agent and collect the data and process it 
in any way allowed by the legal system it is operating in. 

Furthermore, the named third party receiving the DNT;0 header acquires at 
least the right to collect data and process it for the given interaction and 
any secondary use unless it receives a DNT;1 header from that particular 
identified user agent. 

The named third party is also allowed to transmit the collected data for 
uses related to _this_ interaction to its own sub-services and sub-sub-
services (transitive permission). The tracking permission request triggered 
by the origin server is thus granted to the named third party and its sub-
services. This is even true for sub-services that would normally receive a 
DNT;1 web-wide preference from the user-agent if the user agent would 
interact with this service directly. 
For advertisement networks this typically would mean that the collection and 
auction system chain can use the data for that interaction and combine it 
with existing profiles and data.  The sub-services to the named third party 
do not acquire an independent right to process the data for independent 
secondary uses unless they have, themselves, requested and obtained a DNT;0 
header from the user agent. In our example of advertisement networks that 
means the sub-services can use existing profiles in combination with the 
data received, but they can not store the received information into a 
profile until they have received a DNT;0 by their own. A named third party 
acquiring an exception with this mechanism MUST make sure that sub-services 
it uses acknowledge this constraint by requiring a "tl" header (5.2.3) from 
its sub-sub-services.

The permission acquired by the DNT mechanism does not override retention 
limitations found in the legal system the content provider or the named 
third party are operating in.



P.S. we need to determine in Seattle what permissions we need for DNT;0 and 
where to note them down, which goes to the core of the EU system issue Roy 
is coming back to. We need a positive definition of tracking. What does it 
require at least. (in the US, receiving DNT;0 you may go beyond) I think 
that the minimum permissions needed should not contain open ends.

Received on Friday, 25 May 2012 16:19:24 UTC