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

On Mar 19, 2013, at 15:12 , Jonathan Mayer <jmayer@stanford.edu> wrote:

> I'll be brief for want of time.  Thanks to David for patiently explaining the current text.  Here are my concerns with the proposal:
> 
> 1) There is not a meaningful consent standard for a website's exception flow (either in-band or out-of-band).  I would alternatively approve of delegating the in-band exception flow to browsers and requiring use of the in-band API where available.

We use the phrase 'informed consent' pretty freely elsewhere, as here.  What is missing?

> 
> 2) We once again don't have clarity on permissible browser user interface and defaults.  Can a browser use accept/reject notices by default?  Can it reject all exceptions by default?  When a user dismisses a notice?  The normative text might be read to suggest a browser must always store exceptions, while the non-normative text allows for broad discretion.

If this is still unclear in the text, let's look at edits.  I thought I answered these questions below...

> 
> 3) There's a possibility that the API frustrates effective user interface design by requiring a synchronous response.  If the browser can "hold" an exception, as David and the non-normative text suggest, then I take no issue.  If the browser must store an exception, as the normative text suggests, then I believe there's a substantial risk.

Sounds like we need a minor edit.

> 
> #3 may be merely a matter of drafting.  I suspect we have disagreement on how to resolve #1 and #2.  At any rate, I think this discussion is more than adequate to demonstrate that ISSUE-187 should not be CLOSED.  Back to exams for real.
> 
> Jonathan
> 
> On Tuesday, March 19, 2013 at 2:46 PM, David Singer wrote:
> 
>> 
>> On Mar 19, 2013, at 14:36 , Jonathan Mayer <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> 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.
>> 
> 

David Singer
Multimedia and Software Standards, Apple Inc.