issue-170

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

We should probably just change every reference to explicit-exception to UGE, though it is not a very elegant phrase. I liked "permission" (to avoid the ambiguity of "exception") as did Nick I believe, but it did not get much support.

The point I was making on numbers was that there are relatively few instances of UAs and they all appear to me to present clear and comprehensive text about the general preference. If any did not I expect there would be loud protest from the online advertising community etc. 

The UGE is site specific (or server specific for web-wide) and there are millions of them, so a single phrase calling for clarity and completeness is not much to ask. There is a whole paragraph in the TPE on how UAs should determine the general preference.

I take the point Brooks made about UA compliance with DNT1, but I think we have that covered already in the text, i.e. it applies to all Parties including the companies behind UAs and any component extensions.

mike


[Mike O'Neill] 

> From: Chris Mejia [mailto:elementslifestylegroup@hotmail.com]
> Sent: 04 June 2014 20:29
> To: Mike O'Neill; 'Ninja Marnau'; public-tracking@w3.org; 'Jack Hobaugh';
> SULLIVAN, BRYAN L
> Subject: 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.
> >> >
> >> >
> >>
> >>
> >>
> >
> >
> 
> 

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.13 (MingW32)
Comment: Using gpg4o v3.3.26.5094 - http://www.gpg4o.com/
Charset: utf-8

iQEcBAEBAgAGBQJTj4r8AAoJEHMxUy4uXm2JsDwH/0Is9KO62O6Dkfd1IF9fDyzR
DAfVcgq4fjhDXJowD3auHOUPAyURV3L6O7qUCfdSBWSxUEHwlWT+LoYSlQxZJehx
C4DDHNND9hgvzwdAFMBH/wYNDWkOd0OPy7/Cy9BZwQUraKhiM7+WzVSDzH7o+DBy
Uu/x4+7EIdkKJCz7cBET+wvGtnqq0slyaur3vNNE9nzPzBGbuedLCetW40y5mwmW
K25U088IPew365Krky+QdlsmqgjdeErIxzzjbaKePajsvuozPyQamcGxDvb0NGi9
uY8yC3IvMozgIVnv/yYC9jSRrBUcQNxzd1msmVtSRZsIKRRLe8yXnDHogXKzVHA=
=TqsG
-----END PGP SIGNATURE-----

Received on Wednesday, 4 June 2014 21:10:01 UTC