RE: ISSUE-187 - some thoughts on using javascript

Roy,

Another thought.

The other parameters to the JS API (siteName, explanationString, detailURI)
are important because the UA can show them in a UI later, e.g. so the user
can revoke the exception etc. Maybe these, or similar, should be added to
the WKL tracking resource, the UA can load them when it needs to show the
UI. It would also be easier to make the info. extensible.

Also, another argument to support the _dnt_ cookie is that it can have an
expiry or maxdays argument in the value, so the exception will automatically
get revoked after a period.

BTW I got my own protocol for the qualifier wrong, that should have been
t=toplevel.com

Mike


-----Original Message-----
From: Mike O'Neill [mailto:michael.oneill@baycloud.com] 
Sent: 09 November 2012 08:59
To: 'Roy T. Fielding'; 'Shane Wiley'
Cc: 'Walter van Holst'; public-tracking@w3.org
Subject: RE: ISSUE-187 - some thoughts on using javascript

Roy,

I like this because, as you say, we can already do it in headers or
javascript and we have a tried & tested spec covering it. It is also more
transparent that doing it all in JS because you can see the _dnt_ cookie in
retained logs. If users delete all their cookies then they must mean they
want to return to DNT: 1, so that's fine.

The necessary extra API to cover 3rd parties would need to take account of
web-wide exceptions. If a WWE was in place would we let a first-party
override it? I think we would in order to be consistent with the idea that
responsibility (for getting consent) is with the first-party site. In that
case we would not change the value of the _dnt_ cookie in the third-party
domain, just temporarily stop its transmission in the cookies: header when
the request is for a third-party in the context of the responsible
first-party site.

The _dnt_ value could encode further qualifiers (like my f=toplevel.com, or
Thomas's WhoSetIt=<string> etc.) if we want.

I did not understand your last sentence. What did you mean by "regular reset
actions"?

Thanks

Mike

-----Original Message-----
From: Roy T. Fielding [mailto:fielding@gbiv.com]
Sent: 08 November 2012 19:39
To: Shane Wiley
Cc: Walter van Holst; public-tracking@w3.org
Subject: Re: ISSUE-187 - some thoughts on using javascript

I think you are both right, but talking past one another.

What we effectively have now is a javascript API that sets a special named
cookie that has no expiration date and a separate management interface.
That can be accomplished via a header field instead of (or in addition to)
javascript, and there are reasons to do so that mirror the Set-Cookie
abilities.
For example, the server could send

   Set-DNT: 0

to set an exception for its own domain, and perhaps include a list of
domains for the other cases.  This works because we are now assuming that
the server has performed the UI bit and the browser does not have a
meaningful error case (either it sets the flag or it doesn't, and we won't
know until the next applicable request).

Now, I look at that and wonder why we don't just use a standard cookie name
and be done, as I suggested in Santa Clara.

   Set-Cookie: _dnt_="0"

If we did, then a UGE request would be something like

   DNT: 1
   Cookie: _dnt_="0"

In other words, the DNT field would always reflect the global setting and
the cookie would override for the sake of exception/permissions.
If the cookie is deleted then it would have the same effect as the user
deciding to clear all exceptions.  We could also define a special API for
requesting that specific cookie be set for third-party domains, and UAs that
want to implement DNT exceptions can apply special UIs to their management
that would avoid the regular reset actions.

....Roy

On Nov 8, 2012, at 9:49 AM, Shane Wiley wrote:

> Walter,
> 
> The User Agent developers in the Working Group have already suggested 
> they
will not build a UI here and Industry has already suggested they would not
support DNT if they feel a UI does not provide a fair and balanced
experience to the user.  The proposal from Adrian (and to some degree I now
believe, Ian) has such strong support broadly across the Working Group due
to these issues.
> 
> I agree the user experience will be slightly different across Servers
(including the need to remain accessible) but I believe that is the RIGHT
outcome as each Server has a different value proposition, user experience,
and intake flow than other sites so it makes sense this be different.
> 
> - Shane
> 
> -----Original Message-----
> From: Walter van Holst [mailto:walter.van.holst@xs4all.nl]
> Sent: Thursday, November 08, 2012 9:59 AM
> To: public-tracking@w3.org
> Subject: ISSUE-187 - some thoughts on using javascript
> 
> During yesterday's call either my poor command of the English language 
> or
the equally poor service of Skype caused me not to make any sense on this
issue, so I'll do it by e-mail.
> 
> After having put some thought in it, I am not in favour of using
JavaScript for granting exceptions/permissions for overriding DNT:1 and for
several reasons:
> 
> Consistency:
> 
> - The general expression is already done through HTTP headers, so why 
> not
have specific expression through HTTP too?
> - Presentation to the user will be site-specific, which does not 
> provide a
consistent user experience.
> 
> Accessibility:
> 
> - It puts more of a burden for sites who implement DNT to retain
accessibility (e.g. ADA-requirements) while the UA can take care of this in
one go anyway. Smoothness of a few implemenations compared to thousands.
> 
> User control:
> 
> - It will be much harder for users to automate responses to requests 
> for
exceptions/permissions that use a Turing-complete language and will
therefore come in all forms and shapes.
> 
> So basically, I would prefer to have this done at the HTTP and not the
HTML level. If we insist on using JavaScript/ECMAscript then I would prefer
the standard to contain normative language for mandatory identifiers for
such requests that make them machine-recognisable (my use of the term
machine-readable during yesterday's call was in error and caused confusion)
and allow for automated responses.
> 
> Regards,
> 
>  Walter
> 
>

Received on Friday, 9 November 2012 10:58:51 UTC