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: Fri, 9 Nov 2012 17:15:14 +0000
To: Mike O'Neill <michael.oneill@baycloud.com>
CC: "public-tracking@w3.org" <public-tracking@w3.org>
Message-ID: <2B40EB3A3384EB4CB812241DDDC41D8707CD89@KBMEXMBXPR01.kbm1.loc>
>>>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."

Apologies, I must have confused "argument to support" with "arguing for" a
shorter expiry than DNT:1 - my bad.

With respect to how you handle unsets, I certainly hope this isn't a
problem; it is after all the default case.  If we have devised a spec
where the default case is unmanageable, we have a very serious problem.

With respect to the length consent should be maintained, I would say that
it applies both ways and if anything a more specific choice should be
afforded more, or at minimum as much, protections than a more general
choice.  Moving away from that principle is both illogical and not the way
the world generally works.


-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/9/12 11:46 AM, "Mike O'Neill" <michael.oneill@baycloud.com> wrote:

>Hi Brooks,
>
>I was not arguing for or against anything, I was just pointing out the
>Roy's
>idea of leveraging an existing spec. (RFC2965) to signal the exceptions
>also
>gave us the sunset ability for free. To keep a balance I suppose you could
>also time out the general preference, but how would you handle the unset
>case? 
>
>BTW I think there was a A29WP opinion that included a recommendation that
>there should be an expiry period for consent.
>
>Cheers
>
>Mike
>
>
>-----Original Message-----
>From: Dobbs, Brooks [mailto:Brooks.Dobbs@kbmg.com]
>Sent: 09 November 2012 16:24
>To: Mike O'Neill; 'Roy T. Fielding'; 'Shane Wiley'
>Cc: 'Walter van Holst'; public-tracking@w3.org
>Subject: Re: ISSUE-187 - some thoughts on using javascript
>
>Mike,
>
>You are losing me on the expiry argument.  Aren't we attaching a
>subjective
>value to a consumer's choice by saying that a choice to allow something
>should be subject to an expiry, whereas the choice to deny something
>should
>not?  Given that both conditions are subject to the same choice
>requirement
>(IE10 notwithstanding), why would one choice be less equal (deserving of
>less protection) than the other?  Isn't this just another way of saying,
>"I
>know you SAID you'd allow this, but trust me (I know better than you) you
>didn't really mean it, so I'll force you to rethink it after some period
>of
>time".
>
>I've always thought that the more specific a choice is, the more it
>deserves
>protection?
>
>Respecting a choice isn't always about agreeing with the choice right?  I
>seem to remember Chitika running into some hot water with the FTC when it
>choose to intentionally limit a choice to 10 days.  I don't think the
>decision was based around what the choice was; it was based on the notion
>that Chitika understood what consumers had asked for and intentionally
>shortened that choice's applicability.  It would seem that the same thing
>is
>proposed here!
>
>-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/9/12 5:58 AM, "Mike O'Neill" <michael.oneill@baycloud.com> wrote:
>
>>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 17:15:41 UTC

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