Re: navigator.doNotTrack

> In any case, I don't agree with the Web browser philosophy.
> If I had, HTTP would suck as badly as HTML.

That's cool.  I'll be the first to admit that there are serious
downsides to web browsers' commitment to not breaking pages.  But
that's our commitment with the DOM, and this is part of the DOM.
We're not going to apply the "HTTP philosophy" to the DOM any more
than I'd expect this working group to apply the "web browser
philosophy" to HTTP.

That's why I proposed that the property exposed to the DOM be
different from the property exposed to HTTP.  We can handle extensions
in a similar way, by exposing new properties on the DOM.

-Justin

On Wed, Apr 11, 2012 at 6:55 PM, Roy T. Fielding <fielding@gbiv.com> wrote:
> On Apr 11, 2012, at 5:31 PM, Justin Lebar wrote:
>
>>>> But I don't see how extensions would fit in here without breaking
>>>> existing logic.  Suppose you added a "foo" extension, so now people
>>>> send "DNT: 1 foo".  If we reflected this verbatim in the DOM, then
>>>> every site which checks for navigator.doNotTrack == "1" will break.
>>>
>>> Yes, so don't do that.  There is no "existing logic".  There are no sites
>>> that check navigator.doNotTrack == "1" right now.  I don't care about
>>> the potential ability for web developers to write bad code given
>>> that there is no current documentation that they can copy that tells
>>> them how to test it properly.  The standard specifies it properly, so
>>> we just need to make sure the implementations and examples do the same.
>>
>> It's my experience at Mozilla that web developers will assume anything
>> and everything they can about the interfaces exposed to them.  "Yes,
>> so don't do that" is not a solution for the Web.  None of us here will
>> be able to ensure that all implementations and examples do
>>
>>  navigator.doNotTrack.indexOf("1") == 0
>>
>> instead of
>>
>>  navigator.doNotTrack == "1".
>
> I don't care.  If a website wishes to use the feature, they are capable
> of writing the correct code to test it.  If they fail to do so, it is
> a bug that they are responsible for (not Mozilla, not the standard, and
> not the user).
>
>> Indeed, the former is so counter-intuitive, I'd expect a lot of
>> websites to use the latter, even if we deem it to be incorrect.
>
> Almost all website developers copy by example.  If the example is
> correct and provided, they will merely copy it.  An example of testing
> the feature will be provided in the spec once the WG has agreed on the API.
>
>>>> Or alternatively, suppose we added DNT: 2.  Again, websites would
>>>> handle this incorrectly if we returned it in navigator.doNotTrack,
>>>> because many sites would do an if {} elseif {} else {}.
>>>>
>>>> To be clear, it's a problem that web servers would have to be updated
>>>> to handle this new DNT field, but at least there's some hope of
>>>> getting that right, since there are only a handful of web servers.
>>>> With the Web, there's no hope of getting legacy pages updated.
>>>
>>> There are no legacy DNT pages.
>>
>> But there will be, right?
>>
>> Again, my concern is that web pages will use this interface
>> incorrectly, and then we'll be stuck in a position where we can't
>> change the interface without breaking those pages.  Web browsers are
>> loath to "break the Web" even when pages are using an interface
>> "incorrectly".
>
> Um, your position is to define an interface that can never be
> changed in the first place.  The concern that extensibility won't
> be usable in the future because some pages might not implement the
> test correctly is no worse than defining an interface that can't
> be extended.  You are advocating a "solution" that would be the
> worst case scenario for the existing syntax.
>
> In any case, I don't agree with the Web browser philosophy.
> If I had, HTTP would suck as badly as HTML.
>
>>>> It seems to me that we'd want to expose an extension as
>>>> navigator.doNotTrackFoo, or perhaps
>>>> navigator.doNotTrackExtensions['foo'], or something other than
>>>> navigator.doNotTrack.
>>>>
>>>> Perhaps I'm missing the point of these extensions?
>>>
>>> The whole point of having extensibility is that we don't know what
>>> extensions will be needed.  This is not a problem.
>>>
>>> If you implement it according to the spec, then the test will be
>>> future-proof.  If you don't implement the test as specified, then the
>>> test will fail.
>>
>> That is precisely what, for the purposes of the DOM, I would like to
>> avoid.  Again, it is my experience that if we do not avoid this, then
>> we will be in a position in the future where we are unable to make
>> changes because those changes will break sites.
>
> My experience is the opposite, and I build websites and CMS systems
> that are expected to implement this side of the protocol.  If we don't
> design the field with extensibility in mind, then it cannot be
> extended in the future, which is a significant concern given how
> poorly the all-or-nothing 0/1 value reflects the actual desires of
> users to not be tracked.  I expect there to be a demand for extensions
> to add or remove specific allowed forms of tracking almost immediately
> after the WG agrees to what the current 0/1 means.
>
> ....Roy

Received on Wednesday, 11 April 2012 23:23:34 UTC