Re: change proposals

Thanks, Mike.

In some of these cases, it would be useful to indicate the exact text you're proposing to change, to have a little more context.  Adding that below.

On 2013-06-20, at 17:21 -0400, "Mike O'Neill" <michael.oneill@baycloud.com> wrote:

> 1. Scope
>  
> Replace the term user-granted exception with user-granted tracking consent throughout the document.
>  
> Justification.
>  
> The word exception has a particular meaning in the context of software program flow and will be confusing here particularly when JavaScript issues are discussed. It is also not always an exception to a DNT general preference because it can be specified when the general preference is unset.
>  
> 2. Definitions
>  
> In paragraph 5 a new item 3.
>  
> 3. has no independent right to use or share the data.
>  

Current text:
>> An outsourced service provider is considered to be the same party as its client if the service provider:
>> 
>> acts only as a data processor on behalf of the client;
>> ensures that the data can only be accessed and used as directed by that client;
>> has no independent right to use or share the data except as necessary to ensure the integrity, security, and correct operation of the service being provided; and
>> has a contract in place that outlines and mandates these requirements.
You're proposing to replace condition three with "has no independent right to use or share the data."

>  
> Justification.
>  
> The current wording is too broad especially when applied to data sharing. It could be read as saying that data could be shared in order for “correct operation” which could be construed to be for almost any purpose. The ability to use a third party for security and integrity etc. is already covered by item 2 “and used as directed by that client”.
> This is important because the use of persistent identifiers in first-party contexts will take over the tracking role from third-party cookies and there will be pressure for them to be shared to support cross-domain tracking.
>  
>  
> A new set of definitions for persistent identifiers and duration. The term unique user identifier should be replaced by persistent identifier throughout the document.
>  
> A persistent identifier is an arbitrary value held in the User-Agent whose purpose is to identify the User-Agent in subsequent transactions to a particular web domain. It may be encoded for example as the name or value attribute of an HTTP cookie, as an item in localStorage or recorded in some way in the cache.
>  
> The duration of a persistent  identifier is the maximum period of time it will be retained in the User-Agent. This could be implemented for example using the Expires or Max-Age attributes of an HTTP cookie so that it is automatically deleted by the User-Agent after the specified time period is exceeded.
>  
> Justification.
>  
> The original name in the TPC was persistent identifier which is a better term, though it still needs defining. An identifier may not need to be unique in order for it to be used for tracking, but it would have to be persistent. We should qualify permitted uses so the duration of any persistent identifiers is purpose limited.
>  
>  
>  
>  
> 3. User Agent Compliance
>  
> In paragraph 1 replace  Do Not Track preference with Do Not Track general preference
>  
> Justification.
>  
> This is to differentiate the DNT:0 case which could be optional for a general preference but required for a site-specific tracking consent indication i.e. created as a result of calling the API.
>  
>  
>  
>  
> A new paragraph 3.
>  
> A user agent MUST have a default tracking preference of unset (not enabled) unless a specific tracking preference is implied by the decision to use that agent, or another default preference is needed in order to comply with applicable laws, regulations and judicial processes.
>  
> Justification.
>  
> The original wording in the TPE, allowing the choice of a privacy oriented user-agent, was better so why lose it, and it is possible that rights-based jurisdictions like the EU with an assumed right to privacy may require user-agents be supplied with DNT set by default.
>  
>  
>  
> In paragraph 4. Remove MUST ensure that the tracking preference choices describe the parties to whom DNT applies
>  
> Justification.
>  
> This is unclear. If it is about the difference between first and third parties then it is irrelevant in Europe.
>  
>  
>  
> 4. First Party Compliance
>  
> Replace sentence 1 to paragraph 1 with:
> If a first party receives a DNT:1 signal it may react to it as if it were a third-party as described in section 5 below, for example in order to comply with applicable laws, regulations and judicial processes. Otherwise it MAY engage in its normal collection and use of information.
>  
> Remove paragraph 3.
>  
> Justification.
>  
> First-parties may be required to follow third-party procedures, or may elect to off their own bat.

The current text is:
>> If a first party receives a DNT:1 signal the first party may engage in its normal collection and use of information. This includes the ability to customize the content, services, and advertising in the context of the first party experience.

>> The first party must not pass information about this network interaction to third parties who could not collect the data themselves under this standard. Information about the transaction may be passed on to service providers acting on behalf of the first party

>> First parties may elect to follow third party practices.

Can you clarify whether your change proposal intends any change to the meaning of the text, or is intended to be purely editorial?

> 5. Third Party Compliance
>  
> In paragraph 1 in both items 1 and 2 remove and any explicitly-granted exceptions.
>  
> Justification.
>  
> A UGE (or tracking consent) will result in DNT:0 anyway so this does not apply here.

Existing text:
>> If a third party receives a DNT: 1 signal, then:
>> 
>> the third party must not collect, retain, share, or use information related to the network interaction as part of which it received the DNT: 1 signal outside of the permitted uses as defined within this standard and any explicitly-granted exceptions provided in accordance with the requirements of this standard;
>> the third party must not use information about previous network interactions in which it was a third party, outside of the permitted uses as defined within this standard and any explicitly-granted exceptions, provided in accordance with the requirements of this standard.
I suggest that this is a purely editorial change to resolve a contradiction in the drafting, and suggest that we handle it as such.
> 

> Remove  paragraphs 5 and 7.

Existing text:

para 5:

>> When a third party receives a DNT:1 signal, that third party may nevertheless collect, retain, share or use data related to that network interaction if the data is de-identified as defined in this specification.


para 7:

>> It is outside the scope of this specification to control the collection and use of de-identified data.

> Justification.
>  
> No data should be collected when DNT is set unless it is for a permitted use. If “and otherwise be linked to” ends up being removed from the definition of de-identified data then this could create a gaping hole in the standard.

The justification here suggests that this change proposal is contingent on the eventual definition of "de-identified".  Is that correct?

> 5.1.2 Data Minimisation, Retention and Transparency
>  
> New paragraph 4.
>  
> If persistent identifiers are used then their duration should be limited to the maximum necessary for such permitted use.
>  
> Justification.
>  
> If a permitted use requires a persistent identifier then it does not need to exist beyond the purpose of the permitted use. For example if it is necessary to detect unique visitors for frequency capping the duration could be no more than some number of minutes.
>  
>  
>  
> 5.2 Permitted Uses
>  
> Add a new paragraph 5.
>  
> If a persistent identifier is required for any permitted use, for example in order to identify a unique visitor for billing or frequency capping purposes,  the duration of the persistent identifier should be limited to the maximum necessary  for such permitted use.
>  
> Justification.
>  
> Same as above.
>  
>  
>  
>