Re: ISSUE-187 - some thoughts on using javascript

Roy,

Doesn't this approach open up all sorts of questions about cookie
deletion, rights to the cookie jar etc?

Would it be fair that a 3rd party cookie deletion tool that deletes all
cookies every 72 hours deletes the "special" UGE cookies?  Should these be
stored separately in addition to being set differently?

-Brooks

-- 

Brooks Dobbs, CIPP | Chief Privacy Officer | KBM Group | Part of the
Wunderman Network
(Tel) 678 580 2683 | (Mob) 678 492 1662 | kbmg.com
brooks.dobbs@kbmg.com



This email ­ including attachments ­ may contain confidential information.
If you are not the intended recipient,
 do not copy, distribute or act on it. Instead, notify the sender
immediately and delete the message.



On 11/8/12 2:38 PM, "Roy T. Fielding" <fielding@gbiv.com> wrote:

>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 Thursday, 8 November 2012 19:48:12 UTC