W3C home > Mailing lists > Public > public-tracking@w3.org > November 2012

Re: ISSUE-187 - some thoughts on using javascript

From: Dobbs, Brooks <Brooks.Dobbs@kbmg.com>
Date: Thu, 8 Nov 2012 19:47:42 +0000
To: "Roy T. Fielding" <fielding@gbiv.com>, Shane Wiley <wileys@yahoo-inc.com>
CC: Walter van Holst <walter.van.holst@xs4all.nl>, "public-tracking@w3.org" <public-tracking@w3.org>
Message-ID: <2B40EB3A3384EB4CB812241DDDC41D8707BFBA@KBMEXMBXPR01.kbm1.loc>
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

This archive was generated by hypermail 2.3.1 : Friday, 21 June 2013 10:11:38 UTC