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

Here's my understanding: The "new" approach, as articulated by many participants since Bellevue, emphasizes out-of-band exceptions.  The browser would merely be a repository for control links.  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?
-When can a browser refuse to store an exception?  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.  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.

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.
> 
> 
> 
>