Re: ISSUE-187 - some thoughts on using javascript

>>>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