- From: Nicholas Doty <npdoty@w3.org>
- Date: Tue, 14 Oct 2014 21:16:49 -0700
- To: "Roy T. Fielding" <fielding@gbiv.com>, "Amy Colando (LCA)" <acolando@microsoft.com>, David Singer <singer@apple.com>
- Cc: Tracking Protection Working Group <public-tracking@w3.org>
- Message-Id: <0DF71F02-FBBF-429A-B46F-1D7DD9AAC84C@w3.org>
On October 8, 2014, at 11:30 AM, Roy T. Fielding <fielding@gbiv.com> wrote:
> On Oct 7, 2014, at 5:32 PM, Nicholas Doty wrote:
>
>> ## deidentification
>>
>> Added definition agreed via Call for Objections. Changed all instances to refer to "permanently deidentified" (or similar). Non-normative section currently immediately follows the definition (and includes the geolocation note from before), but we could move this elsewhere if it reads as too verbose.
>
> Okay, but it is supposed to be hyphenated (de-identified and re-identified).
I assumed that punctuation was typically an editorial decision and I prefer it without the hyphen. If someone has a reason why this would be confusing to readers, let me know. I'll be sure to do a pass as we get further along to make sure punctuation is consistent throughout.
> % cvs diff -r1.125 -r1.126 tracking-compliance.html
> Index: tracking-compliance.html
> ===================================================================
> RCS file: /w3ccvs/WWW/2011/tracking-protection/drafts/tracking-compliance.html,v
> retrieving revision 1.125
> retrieving revision 1.126
> diff -u -r1.125 -r1.126
> --- tracking-compliance.html 1 Oct 2014 06:54:43 -0000 1.125
> +++ tracking-compliance.html 1 Oct 2014 07:02:11 -0000 1.126
> @@ -551,21 +551,8 @@
> signals" may be received.
> </p>
> <p>
> - As a general principle, more specific settings override less
> - specific settings.
> + As a general principle, more specific settings override less specific settings, as where the specific consent in user-granted exceptions overrides a general preference. If a party perceives a conflict between settings, a party MAY seek clarification from the user or MAY honor the more restrictive setting.
> </p>
> - <ol start="1">
> - <li>No DNT Signal / No Opt-Out: Treat as DNT unset</li>
> -
> - <li>DNT:1 Signal / No Opt-Out: Treat as DNT: 1</li>
> -
> - <li>Opt-Out / No DNT:1 Signal: Treat as DNT: 1</li>
> -
> - <li>Opt-Out / DNT User-Granted Exception: Treat as DNT: 0 for that
> - site; DNT User-Granted Exception is honored</li>
> - </ol>
> - <p class="issue" data-number="210" title="Interaction with existing privacy controls"></p>
> - <p class="issue" data-number="207" title="Conditions for dis-regarding (or not) DNT signals"></p>
> </section>
> <section>
> <h3>Unknowing Collection</h3>
> ===================================================================
>
> The above section no longer applies in my proposal and should not be in
> compliance. There are only two possibilities: prior consent or DNT.
> Prior consent always overrides DNT, regardless of the intent of that
> consent (e.g., the consent might even limit tracking more than DNT:1).
>
> The text above implies UGE is some additional signal; it is not.
> UGE would be reflected in a different DNT header field. Hence, the
> last sentence above is simply incorrect -- there is no opportunity for
> multiple signals to be received other than consent + DNT, in which case
> consent is *not* a conflict -- it is designed to override so that a user
> doesn't have to twiddle their general preference.
This section is referring to possible interactions with, for example, DAA-related opt-out cookies, when they're present with a DNT:1 or DNT:0. As such, I don't think it's attempting to describe any conflicts between DNT and a UGE, but rather UGE and a DAA-style opt-out cookie. I believe Amy Colando (CCed) had worked on the update to that section. Amy or Roy, is there some clarification we should add to that paragraph?
> Also, the following change is apparently a clarification to the definitions
> currently in TPE. Should I add it to TPE?
Ah, yes, good catch, I think that's right. We should also be sure that we're using "first party" and "third party" in the TPE consistently to how we're using it in Compliance. I think maybe the references to first party in the Exceptions API sections should use the phrasing of "first party to a given user action".
Thanks,
Nick
[change to first party / intentional interaction definition retained below for context]
> ....Roy
>
> % cvs diff -r1.123 -r1.124 tracking-compliance.html
> Index: tracking-compliance.html
> ===================================================================
> RCS file: /w3ccvs/WWW/2011/tracking-protection/drafts/tracking-compliance.html,v
> retrieving revision 1.123
> retrieving revision 1.124
> diff -u -r1.123 -r1.124
> --- tracking-compliance.html 6 Aug 2014 04:44:06 -0000 1.123
> +++ tracking-compliance.html 1 Oct 2014 06:49:47 -0000 1.124
> @@ -8,9 +8,7 @@
> var respecConfig = {
> specStatus: "ED",
> shortName: "tracking-compliance",
> - previousPublishDate: "2012-04-30",
> previousMaturity: "WD",
> - //previousURI: "http://www.w3.org/TR/2013/WD-tracking-compliance-20130430/",
> edDraftURI: "http://www.w3.org/2011/tracking-protection/drafts/tracking-compliance.html",
> editors: [
> { name: "Nick Doty", url: "http://npdoty.name",
> @@ -174,6 +172,9 @@
> co-branding on the resource might lead a user to expect that
> multiple parties are responsible for the content or functionality.
> </p>
> + <p>
> + Network interactions and subrequests related to a given user action may not constitute intentional interaction when, for example, the user is unaware or only transiently informed of redirection or framed content.
> + </p>
> </section>
>
> <section id="third-party">
> ===================================================================
Received on Wednesday, 15 October 2014 04:17:06 UTC