Re: [TCS] comments on 17 Feb 2015 editors draft

More responses inline. Edits have been made here: https://lists.w3.org/Archives/Public/public-tracking-commit/2015Mar/0003.html
On a couple points, it would be great for others to weigh in (or to chat briefly on a call) just to get a sense of the room.

Thanks,
Nick

>> 2. Definitions
>> 
>>  2.1  User
>> 
>>   A user is an individual human. When user agent software accesses online
>>   resources, whether or not the user understands or has specific knowledge
>>   of a particular request, that request is "made by the user."
> 
> Note that this differs from the definition in TPE.

Confirmed that we don't make use of the "made by the user" syntax anywhere, so it can be removed. It doesn't seem like the individual human vs. natural person distinction is important, so I've included the TPE definition.

Previously: 
https://lists.w3.org/Archives/Public/public-tracking/2013Jun/0136.html
https://lists.w3.org/Archives/Public/public-tracking/2015Mar/0013.html
http://www.w3.org/mid/010101d0568d$06736e30$135a4a90$@baycloud.com

>>  2.2  User Agent
>> 
>>   The term user agent refers to any of the various client programs capable
>>   of initiating HTTP requests, including but not limited to browsers,
>>   spiders (web-based robots), command-line tools, native applications, and
>>   mobile apps [RFC7230].
>> 
>>   Issue 227: User Agent requirements in UA Compliance vs. Scope section
>> 
>>   There is a proposal to move a sentence about user agents from the
>>   Introduction/Scope section to this section. We might also include a
>>   reference here to the conformance requirements on user agents in the
>>   companion TPE recommendation.
> 
> Is that why there is an extra sentence in section 2.1?  The issue comment
> doesn't seem to apply.

This issue was referring to a sentence in section 1 Scope, not the user definition. In a previous edit, I had revised that text ("is intended for compliance with expressed user preferences via user agents that ...") in a way that I hope would satisfy various concerns about it. As a result, I don't think we need to alter the definition here, so I hope this issue can be closed.

>>  2.10  Deidentification
> 
> All my spell-checkers and the abundance of existing external references
> say this should be hyphenated as De-identification, de-identified, etc.
> I don't think that is editorial preference (neither is spelling).

I guess I'm more familiar with the academic literature, where reidentify and deidentify are commonly not hyphenated. However, this seems to bother at least Roy and Mike so I can go through and re-hyphenate everything.

>>   A party to a given user action that disregards a DNT:1 signal MUST
>>   indicate that non-compliance to the user agent, using the response
>>   mechanism defined in the [TRACKING-DNT] recommendation. The party MUST
>>   provide information in its privacy policy listing the specific reasons for
>>   not honoring the user's expressed preference. The party's representation
>>   MUST be clear and easily discoverable.
> 
> The above seems to arbitrarily differ from the requirements in TPE for
> the "D" response.

I believe the differences from the TPE text were explicitly in response to group discussions of limiting the use of disregard signals.

>>  3.3  Third Party Compliance
>> 
>>   Issue 203: Use of 'tracking' in third-party compliance
>> 
>>   When a third party to a given user action receives a DNT:1 signal in a
>>   related network interaction:
>> 
>>    1. that party MUST NOT collect, share, or use tracking data related to
>>       that interaction;
>>    2. that party MUST NOT use data about network interactions with that user
>>       in a different context.
>> 
>>   A third party to a given user action MAY nevertheless collect and use such
>>   data when:
>> 
>>    1. a user has explicitly-granted an exception, as described below;
>>    2. data is collected for the set of permitted uses described below;
>>    3. or, the data is permanently deidentified as defined in this
>>       specification.
> 
> I dislike this contradiction of a MUST NOT and MAY nevertheless.
> I'd rather reverse the order and say MAY when 1, 2, 3; otherwise,
> MUST NOT (a) and MUST NOT (b).

I think the language here was just mirroring the conceptual agreement: general prohibition with specific permitted uses. If changing it to say 'allowed for permitted uses and otherwise generally prohibited' improves readability or interpretation of RFC2119 terms, I can do that.

>>      3.3.1.1  No Secondary Uses
>> 
>>   A party MUST NOT use data collected for permitted uses for purposes other
>>   than the permitted uses for which each datum was permitted to be
>>   collected.
> 
> Yikes.  How about:
> 
>   A party MUST NOT use data collected for permitted uses for purposes
>   other than those permitted uses.

I believe the verbose language was introduced to make it clear that data collected because it was necessary for one permitted use shouldn't later be used for another use among the permitted uses (for which it might not have been necessary). That said, your "those permitted uses" implies a reference, so maybe that's good enough. If people prefer this language and don't think we're introducing ambiguity, I'll make that change.

>> 4. User-Granted Exceptions
>> 
>>   A party MAY engage in practices otherwise proscribed by this
>>   recommendation if the user has given explicit and informed consent. After
>>   consent is received, it MAY be subsequently registered through the
>>   User-Granted Exceptions API defined in the companion [TRACKING-DNT]
>>   document, or a party MAY obtain and record out of band consent to
>>   disregard a Do Not Track preference using a different technology. If a
>>   party is relying on out of band consent to disregard a Do Not Track
>>   preference, the party MUST indicate this consent to the user agent as
>>   described in the companion [TRACKING-DNT] document.
> I find this confusing.  Out-of-band consent is, by definition, not
> something registered through UGE.  Also, "out of band consent to
> disregard a Do Not Track preference" is too specific.  The out of band
> consent may have had no mention of DNT, but still imply overriding
> some or all of the DNT requirements.  It is better to rewrite this as:
> 
>   A party MAY engage in practices otherwise proscribed by this
>   recommendation when the user has given explicit and informed consent.
>   A party MUST indicate when it is relying on out of band consent to
>   override a Do Not Track preference, as described in the companion
>   [TRACKING-DNT] document.

I think the text was intended to express the same thing as your paragraph (per its first sentence), but you're pointing out a lack of clarity. I believe this section is intended to describe consent, and we're confusing that by referring to "User-Granted Exceptions", which might refer to use of the API or to consent gathered and recorded in a different way.

Here's my revised text, including your language:

> 4. Consent
> 
> A party MAY engage in practices otherwise proscribed by this recommendation when the user has given explicit and informed consent. After consent is received, it might be subsequently registered through the User-Granted Exceptions API defined in the companion [TRACKING-DNT] document or recorded out of band using a different technology. A party MUST indicate when it is relying on out of band consent to override a Do Not Track preference, as described in the companion [TRACKING-DNT] document.
> 
> Example 5
> A site may provide a settings page to its logged-in users with an explanation of a feature that involves collecting data on that user's activity on other sites in order to provide more relevant content on the home site. To implement the feature and record that consent, the site places a cookie on the user's machine. In subsequent requests where the consent cookie is recognized and a DNT: 1 header is present, the site responds with a Tk response header of C, to indicate that consent to the user.


> s/recommendation/specification/  [the former assumes a given status] 

Previous versions had used "recommendation", "specification" and "standard" variously throughout the document. David Singer suggested that we fix by using "recommendation" everywhere:
	https://lists.w3.org/Archives/Public/public-tracking/2013Sep/0115.html
I'm fine with "specification", especially if "recommendation" is likely to be confused for "W3C Recommendation". David?

Thanks,
Nick

Received on Monday, 23 March 2015 00:58:56 UTC