W3C home > Mailing lists > Public > public-tracking@w3.org > March 2013

Re: Batch closing of issues (ISSUE-144, ISSUE-187) [pls Respond by Mar 22]

From: Matthias Schunter (Intel Corporation) <mts-std@schunter.org>
Date: Wed, 20 Mar 2013 23:29:02 +0100
Message-ID: <514A382E.2070508@schunter.org>
To: public-tracking@w3.org
Hi Jonathan,

you indicated that you are OK with the new approach if there is a 
standard how a site collects consent.
The current language in the spec that tries to constitute such a 
standard is in Section 6.3.1:

> "User Interaction
>
> 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. (This allows the user to change their mind, and 
> delete a stored exception, which might then trigger the site to 
> explain, and ask for, the exception again). It is the responsibility 
> solely of the site making the call to determine that a call to record 
> an exception reflects the user's informed consent at the time of the 
> call."
>

If you deem this language insufficient, could you come up with an 
alternative/extension that addresses your final remaining concern of a 
race to the bottom?


Regards,
matthias



On 19/03/2013 22:46, David Singer wrote:
>
> On Mar 19, 2013, at 14:36 , Jonathan Mayer <jmayer@stanford.edu 
> <mailto:jmayer@stanford.edu>> wrote:
>
>> Here's my understanding: The "new" approach, as articulated by many 
>> participants since Bellevue, emphasizes out-of-band exceptions.
>
> No, not at all.  They both existed before, and OOB has not changed. 
>  The new approach makes it clear that it is the sole responsibility of 
> the site to get the user's informed consent at the time of the call, 
> whereas in the old approach it was sort-of split between the site and 
> the UA, without clear final responsibility.  That's all that changed.
>
>
>> The browser would merely be a repository for control links.
>
> No 'merely'.  It holds the database, can expose it to the user for 
> editor, and can work with the user to control admission as well, if it 
> likes.
>
>> The "old" approach consisted of a JavaScript API linked to the "DNT: 
>> 0" header and centralized in-browser management (including links for 
>> learning more or expressing further control).  I am comfortable with 
>> the "old" approach and have serious concerns with the "new" approach. 
>>  If I read the current TPE draft correctly, it's essentially the 
>> "old" approach, with a few ambiguities:
>>
>> -Can a website use an out-of-band exception when the API is available?
>
> Yes.  That hasn't changed.  OOB may be appropriate under some 
> circumstances not connected with this API change.
>
>> -When can a browser refuse to store an exception?
>
> * The user may have told it 'I never want exceptions, don't even ask me'
> * The user may have told it 'Please ask me each time before storing'
> * The user may have told it 'Please alert me an exception was 
> recorded, but record it and carry on in the meantime'
> * The user may come back later and edit the exception database]
> * 
>
>> When a user clicks reject?  When a user dismisses a notice?  By 
>> default?  When the user has previously rejected the exception?
>>
>> I'm also concerned about making the API synchronous, since the design 
>> necessarily constrains browser user interface.  Unless websites are 
>> smart about putting their exception calls into a different execution 
>> context, browsers will be forced to choose whether to give realtime 
>> user choice or continue the execution flow of a website.
>
> They are allowed to 'hold' the exception pending approval, if that's 
> their flow.  The return does not indicate 'it has been stored' it 
> indicates 'OK, we hear you'.  Call the confirm API if you want to know 
> what's excepted.
>
> I hope I made this clear in the non-normative text.
>
>>  In other words, providing a meaningful exception user experience 
>> might involve breaking web content.  Retaining an asynchronous API 
>> seems a very small price to protect against this risk.
>
> I don't think there is a risk.
>
>
>>
>> Jonathan
>>
>> On Tuesday, March 19, 2013 at 1:58 PM, David Singer wrote:
>>
>>>
>>> On Mar 19, 2013, at 10:46 , Jonathan Mayer <jmayer@stanford.edu 
>>> <mailto:jmayer@stanford.edu>> wrote:
>>>
>>>> I don't think everyone's on the same page here.  Some participants 
>>>> have suggested that the following hold true in the new model:
>>>>
>>>> -A website MUST call the exception API.
>>>
>>> When?  Please be specific.
>>>
>>>> -A website MUST honor the result of the exception API.
>>>
>>> It does not return a result, there is nothing to honor.
>>>
>>>> -A browser MAY present a UI before an exception is allowed.
>>>
>>> Before it's recorded, yes.
>>>
>>>> -A browser has discretion over its exception UI (e.g. MAY reject an 
>>>> exception if the user dismisses a balloon).
>>>
>>> If the UA asks and the the user says "no, I didn't grant an 
>>> exception" then indeed the UA may refuse to record it.
>>>
>>>> If that's the case, then I'm totally onboard.  But that would mean 
>>>> the new model is essentially the same as the old model, with a tiny 
>>>> change to the API structure.  Other participants have suggested the 
>>>> new model is something like:
>>>>
>>>> -A website MAY call the exception API.
>>>
>>> Again, when?  This API is about UA-recorded and in-line signalled 
>>> exceptions (so called 'in band').  There is a separate model for 
>>> out-of-band consent.
>>>
>>>> -There is no result for the API, it merely stores a control link. 
>>>>  The user would have to visit the control link to reject the exception.
>>>
>>> This seems confused;  return results would have gone to the caller, 
>>> not the user, yet then you talk about the user.
>>>
>>>> -A browser MAY present a UI after an exception is stored.
>>>
>>> Before or after, yes.
>>>
>>>> -A browser has limited discretion over its exception UI (e.g. it 
>>>> cannot reject an exception if the user dismisses a balloon).
>>>
>>> Balloon?
>>>
>>>>
>>>> I would not be comfortable with any of these provisions.
>>>>
>>>> At any rate, no point in debating this in the abstract.  It's a 
>>>> technical proposal.  Where's the latest text,
>>>
>>> In the current editor's draft.
>>>
>>>> and how does it line up against the two sets of views?  In the 
>>>> interim, ISSUE-187 should not be CLOSED.
>>>>
>>>> Back to studying,
>>>> Jonathan
>>>>
>>>> On Tuesday, March 19, 2013 at 4:30 AM, Matthias Schunter (Intel 
>>>> Corporation) wrote:
>>>>
>>>>> Hi Jonathan,
>>>>>
>>>>>
>>>>> I believe that we reached agreement during our last F2F 
>>>>> (naturally, only among the people in the room).
>>>>>
>>>>> As far as I recall, Nick was OK with the new approach since he 
>>>>> believed that it now (after his revisions) provides sufficient 
>>>>> protection against such a race to the bottom.
>>>>> The argument that he used was that the browsers are still free to 
>>>>> validate exceptions with the users before storing them.
>>>>> If we assume that browsers will do what is best for their users, 
>>>>> they will start implementing additional safeguards in case sites start
>>>>> storing exceptions without sufficient user interaction. This may 
>>>>> mean that a browser can display baloons when an exception is 
>>>>> stored or may also just
>>>>> mean that they implement a confirmation UI envisioned in the 
>>>>> alternative approach.
>>>>>
>>>>> Nick has clarified these possibilities and seems to be OK (in the 
>>>>> "can live with" sense) with the new approach towards exceptions.
>>>>>
>>>>>
>>>>> Regards,
>>>>>  matthias
>>>>>
>>>>>
>>>>> On 19/03/2013 06:16, Jonathan Mayer wrote:
>>>>>> On ISSUE-187, have we reached agreement on a consent standard for 
>>>>>> exceptions under the new model?  If not, I don't believe we've 
>>>>>> resolved the concerns about a race to the bottom that Nick, I, 
>>>>>> and others have raised.
>>>>>>
>>>>>> On Monday, March 18, 2013 at 8:38 AM, Matthias Schunter (Intel 
>>>>>> Corporation) wrote:
>>>>>>
>>>>>>> Hi Team,
>>>>>>>
>>>>>>> based on our discussion at the Cambridge F2F and exchanges by 
>>>>>>> email, I
>>>>>>> suggest to close the following issues.
>>>>>>>
>>>>>>> Please respond if you disagree with closing one of those issues 
>>>>>>> while
>>>>>>> substantiating your concerns.
>>>>>>>
>>>>>>> Regards,
>>>>>>> matthias
>>>>>>>
>>>>>>> --------------------------------
>>>>>>> ISSUE-144: User-granted Exceptions: Constraints on user agent 
>>>>>>> behavior
>>>>>>> while granting and for future requests?
>>>>>>> http://www.w3.org/2011/tracking-protection/track/issues/144
>>>>>>>
>>>>>>> The new approach to exceptions has removed those requirements on 
>>>>>>> the
>>>>>>> user agent. As a consequence, I believe we can close this issue.
>>>>>>>
>>>>>>> Note: The related question whether a user agent MUST/SHOULD/MAY
>>>>>>> implement the exception API is still under discussion as ISSUE-151.
>>>>>>>
>>>>>>> --------------------------------
>>>>>>> ISSUE-187: What is the right approach to exception handling?
>>>>>>> http://www.w3.org/2011/tracking-protection/track/issues/187
>>>>>>>
>>>>>>> During the F2F, we reconfirmed that the recent improvements
>>>>>>> (e.g., proposed by Nick and Jonathan) improved the new exception
>>>>>>> approach sufficiently such that it seems likely that the whole
>>>>>>> group can now live with it. I suggest to close ISSUE-187.
>>>>>>> ----------------------------------
>>>>>>
>>>>>
>>>>
>>>
>>> David Singer
>>> Multimedia and Software Standards, Apple Inc.
>>>
>>
>
> David Singer
> Multimedia and Software Standards, Apple Inc.
>
Received on Wednesday, 20 March 2013 22:29:29 UTC

This archive was generated by hypermail 2.3.1 : Friday, 3 November 2017 21:45:07 UTC