Re: issue-170

Mike, glad that we agree on the redundancy of the term “explicit” as it
relates to UGEs. I appreciate your point about its origin in the TCS, but
I think we should apply a grain a salt there. As we go through this
re-drafting exercise, we need to remember that most of the original TCS
draft language came from a much different working group (than today’s
subset), and is 2-3 years old. The privacy/regulatory/self-regulatory
landscape has also changed. So I’m not sure we should place too much
reliance on what that old draft says, and I believe we should certainly be
open to re-drafting the language when it doesn’t fit with the current
context (i.e. the new TPE public candidate).

On your second point, I’m not sure I see your argument about requirements
on UAs vs. servers. If DNT is going to be implemented, we’ll need to
strike a good balance on implementation requirements. I say, what’s good
for the goose (UAs), should be good for the gander (servers). So if you’re
willing to re-open discussions on UA UI requirements (ala mine and Alan’s
previous proposals in this area), let’s start there and see where it goes.
That may be a discussion that industry would be willing to entertain:
stricter requirements on setting DNT:1 for stricter requirements on
setting DNT:0?

Btw- I’m not sure how the # of either in the market really bears on this
discussion?

--
Chris Mejia





On 6/4/14, 12:00 PM, "Mike O'Neill" <michael.oneill@btinternet.com> wrote:

>Hi Chris, Bryan
>
>The explicitly-granted phrase came from the existing TCS (4.2 Third Party
>Compliance). I agree "explicit" seems redundant and we should use a
>consistent term but that is how the TCS talks about it, which is why I
>used
>it.
>
>The TCS is about compliance by servers not UAs, and here a lot more
>servers
>out there than there are UAs, so IMO it is appropriate to require clarity
>and completeness given the widespread current practice of bamboozling
>users
>with unreadable legalese in privacy policies. UAs do not do that in my
>experience and if any tried we would all be complaining about it.
>
>mike
>
>> -----Original Message-----
>> From: Chris Mejia [mailto:elementslifestylegroup@hotmail.com]
>> Sent: 04 June 2014 16:52
>> To: Ninja Marnau; Mike O'Neill; public-tracking@w3.org; 'Jack Hobaugh'
>> Subject: Re: issue-170
>> 
>> This group has been historically resistant to requirements on the UI of
>>a
>> UA. For example, Alan and I (and others) proposed a set of requirements
>>on
>> the UI for UAs setting/sending DNT:1. We had proposed that the user be
>> properly informed about the choice they were making before setting
>>DNT:1.
>> Essentially what we were proposing was the choice be ³clearly and
>> comprehensively explained² before the DNT:1 signal was set.  As I
>>recall,
>> our proposal was largely rejected. So now, as I understand it, folks who
>> rejected our similar proposal for the setting of DNT:1, want those rules
>> applied for the setting of DNT:0, to servers?
>> 
>> Also, it seems this proposal wants to change some long-standing
>> terminology. User-granted-exception (UGE) is now ³an explicitly-granted
>> exception²?  This semantic change seems unnecessary‹ the definition of
>>UGE
>> should suffice to inform the reader of this spec what it is, so if you
>> want it to include the word ³explicitly², then I think that word would
>>be
>> better incorporated in the definition itself (though I¹m not entirely
>> supportive of this move, personally). And by the way, what is an
>> non-explicitly-granted exception??  In my mind, a UGE is a UGE, per it¹s
>> definition.
>> 
>> Chris Mejia
>> 
>> 
>> 
>> 
>> On 6/4/14, 8:28 AM, "Ninja Marnau" <ninja@w3.org> wrote:
>> 
>> >Mike, I updated your proposal in the wiki.
>> >
>> >Jack, do you think the text proposal is now more balanced for DNT;0 and
>> >UGE?
>> >
>> >Ninja
>> >
>> >Am 04.06.14 14:38, schrieb Mike O'Neill:
>> >> If a 1st Party receives a request with DNT:0 set then data regarding
>> >>the user MAY be used or shared but, if the header signal resulted from
>> >>an explicitly-granted exception, only for the purposes that were
>>clearly
>> >>and comprehensively explained when the exception was granted.
>> >
>> >
>> 
>> 
>> 
>
>

Received on Wednesday, 4 June 2014 19:29:09 UTC