Re: TPE: Closing ISSUE-138 and implementing the change proposed by ACTION-179?

I am fine with beefing up the language.  The sentence after the one you quoted does put the onus on the site:

The call to store an exception must reflect the user's intention to grant an exception, at the time of the call. This intention must be determined by the site prior to each call to store an exception, at the time of the call. 

There is also a Note:
The requirement for the site to determine the user's intention is new; previously the site was required to inform, but the final determination of intention was the responsibility of the UA. This version removes that split of user-determination, and leaves it solely with the site.

And in 6.7 (informative):
This section is non-normative.
As described above, it is the responsibility solely of the site making the call to determine that an exception grant reflects the user's informed consent at the time of the call.

It is expected that the site will explain, in its online content, the need for an exception, and the consequences of granting or denying an exception, to the user.



But perhaps a clearer paragraph is warranted.  Perhaps after the paragraph above we could write something simpler than originally proposed here, like this?

It is the responsibility solely of the party requesting an exception to explain to the user the scope of the exception, the reason it is needed, and the consequences of granting or denying the request, including identifying the ownership of liability. The site MUST acquire the user's informed consent immediately prior to making the call.


On Jan 16, 2013, at 10:30 , Matthias Schunter (Intel Corporation) <mts-std@schunter.org> wrote:

> Hi Davids,
> 
> 
> thanks for the feedback.
> 
> I looked at the spec and I did not see language that requires the site to inform the user. The only requirement I saw was "The call to store an exception must reflect the user's intention to grant an exception, at the time of the call. "
> 
> Don't you think think that the need to inform the user is too implicit in this sentence and needs to be expanded?
> I believe that the user should learn the consequences of granting such an "exception thing"  (in some site specific way) 
> 
> IMHO asking the user "do you grant a site-wide exception" would not be sufficient to inform the user since an average user would not understand the consequences of saying "yes".
> 
> What alternative proposals to we have?
> 
> 
> Regards,
> matthias
> 
> 
> On 09/01/2013 17:40, David Singer wrote:
>> I think David's right; it would be better to make sure that the normative text is clear and has the right sense.  The proposed text contains words like 'should' and appears to be making requirements and so on, and I fear it's more confusing than helpful.
>> 
>> 
>> On Jan 8, 2013, at 16:58 , David Wainberg <david@networkadvertising.org> wrote:
>> 
>>> It sounds nice, but I don't see why it should be included. But, first, I don't think it belongs in the TPE, as it is not related to the technical implementation of the spec. And, second, we should not burden the specification with commentary and opinion that do not go directly to helping implementers understand what they need to do to implement. Really all this text is saying is take to care to fully inform the user before taking their consent. Isn't this already obvious? Or is the text trying to make a substantive point about who should be responsible, in which case it should make the point clearly and in normative text?
>>> 
>>> On 1/8/13 12:50 PM, David Singer wrote:
>>>> yes, some minor editorial work is needed.  I would also prefer to not casually split an infinitive. :-)
>>>> 
>>>> On Jan 8, 2013, at 9:45 , Kevin Kiley <kevin.kiley@3pmobile.com> wrote:
>>>> 
>>>>>  
>>>>> Should be 'utmost' instead of 'upmost' and I would drop the
>>>>> possessive contraction and use 'it is' instead of it's. The contraction
>>>>> doesn't make sense there amidst all the other exacting language.
>>>>>  
>>>>> Kevin Kiley
>>>>>  
>>>>>  
>>>>> Original posting…
>>>>>  
>>>>> Hi Team,
>>>>>  
>>>>> I would like to initiate a text change and close one issues that have 
>>>>> been pending review for a while.
>>>>> If I do not receive objections/feedback, I would ask our editors to 
>>>>> perform the corresponding updates
>>>>> and then close the corresponding issues.
>>>>>  
>>>>> Regards,
>>>>> matthias
>>>>>  
>>>>> -----------
>>>>> ACTION-179: Draft section on seriousness of the request for a 
>>>>> user-granted exception (with ninja)
>>>>> (http://www.w3.org/2011/tracking-protection/track/actions/179)
>>>>> (issue 129 is already closed).
>>>>> I would like to add this non-normative text to the TPE spec:
>>>>> "<Non-Normative> Requesting and having an exception granted by a user is 
>>>>> a significant event and should be treated as such. When requesting 
>>>>> site-wide or web-wide exceptions, the upmost care should be taken in 
>>>>> relaying to the user the breadth and expanse of the exception they are 
>>>>> granting. This is not to suggest the party requesting the exception 
>>>>> takes on direct liability for the parties the user is granting an 
>>>>> exception to but rather it's critical that requesters of user granted 
>>>>> exceptions take care to appropriately express the scope of that 
>>>>> exception such that liability is appropriately placed on the parties 
>>>>> benefiting from the exception."
>>>>>  
>>>>> -----------------
>>>>>  
>>>>> ISSUE-138: Web-Wide Exception Well Known URI
>>>>> http://www.w3.org/2011/tracking-protection/track/issues/138
>>>>> - Question was: What can third parties without JS real-estate do to 
>>>>> obtain an exception.
>>>>>  
>>>>> Action 319 (http://www.w3.org/2011/tracking-protection/track/actions/319)
>>>>> David Singer has proposed this text:
>>>>>   http://lists.w3.org/Archives/Public/public-tracking/2012Dec/0092.html
>>>>>  
>>>>> I suggest to introduce this text into the spec and close Action-319 and 
>>>>> ISSUE-138
>>>>>  
>>>> 
>>>> David Singer
>>>> Multimedia and Software Standards, Apple Inc.
>>>> 
>>> 
>> 
>> David Singer
>> Multimedia and Software Standards, Apple Inc.
>> 
> 

David Singer
Multimedia and Software Standards, Apple Inc.