- From: David Singer <singer@apple.com>
- Date: Mon, 26 Sep 2016 07:18:10 -0700
- To: "Matthias Schunter (Intel Corporation)" <mts-std@schunter.org>
- Cc: "Roy T. Fielding" <fielding@gbiv.com>, "public-tracking@w3.org (public-tracking@w3.org)" <public-tracking@w3.org>
> On Sep 25, 2016, at 2:34 , Matthias Schunter (Intel Corporation) <mts-std@schunter.org> wrote: > > Hi Folks, > > > I would like to discuss this item and not treat it as an editorial change. > Why make something technical when as far as T least I can tell, it’s editorial? > I believe that the spec has some ambiguitiy that we can resolve in two ways: > - We can say "it is only enabled if the user has set a preference in the > browser". > This implies that the exception API cannot be used to enable DNT > - We can say that DNT can be enabled via the browser and also via the > exception API. > > Both seem viable solutions to me. Or we can say that the header is sent whenever the general preference is enabled or a exception applies. > The latter (that seems to be preferred > by Roy) has the disadvantage that a untrusted site can enable > DNT (without any required user interaction by the more trusted > browser). It has the advantage that a user can opt-in to DNT via a site > without being required to register a general preference before. Please let’s not re-open a technical discussion we already had. We decided to allow exception calls even when a preference is not enabled; it’s in the spec. > > If you believe that we had this discussion before, please educate me. > Otherwise, I suggest we quickly discuss this in our next call. > > Regards, > Matthias > > Am 23.09.2016 19:45, schrieb David Singer: >>> On Sep 23, 2016, at 17:05 , Roy T. Fielding <fielding@gbiv.com> wrote: >>> >>>> On Sep 23, 2016, at 2:00 AM, David Singer <singer@apple.com> wrote: >>>>> On Sep 22, 2016, at 20:04 , Roy T. Fielding <fielding@gbiv.com> wrote: >>>>>> On Sep 22, 2016, at 4:09 AM, Matthias Schunter (Intel Corporation) <mts-std@schunter.org> wrote: >>>>>> - Change definition of "enabled" to also include exceptions: Once you >>>>>> recorded an exception, you implicitly enabled the feature. >>>>> That would not be editorial because the term is used in normative requirements. >>>>> In any case, it isn't necessary: read the last two paragraphs of >>>>> >>>>> https://www.w3.org/TR/tracking-dnt/#determining >>>> OK. But we have a bug; we currently have text that says the header is only sent when DNT is enabled, but later we learn that a site can register an exception even when it’s not, which will cause a DNT header to be sent when applicable, even though the general preference is not enabled. That’s an editorial bug (the statement that it’s only sent when enabled claims to be a statement of fact, not a requirement). >>> Sorry, I wasn't clear. Enabled just means the user has made a choice to send DNT. >>> The spec already states that choice can be made anywhere. That includes making >>> a decision via the exception API. >>> >>> What I mean is that we don't need to change the definition of enabled because >>> it already encompasses this case. There is no bug. We could add it explicitly >>> to the list of examples, but that doesn't change the definition of enabled. >>> >>> … >>> Roy >>> >> Got it. I fear that it may be misunderstood or seen as a contradiction, so I’d suggest a minor editorial to deal with it >> >> thx >> >> >> >> David Singer >> Manager, Software Standards, Apple Inc. >> > > David Singer Manager, Software Standards, Apple Inc.
Received on Monday, 26 September 2016 14:18:43 UTC