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

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.
-A website MUST honor the result of the exception API.
-A browser MAY present a UI before an exception is allowed.
-A browser has discretion over its exception UI (e.g. MAY reject an exception if the user dismisses a balloon).

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.
-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.
-A browser MAY present a UI after an exception is stored.
-A browser has limited discretion over its exception UI (e.g. it cannot reject an exception if the user dismisses a 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, 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.
> > > ----------------------------------
> > > 
> > > 
> > > 
> > 
> > 
>