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: David Singer <singer@apple.com>
Date: Tue, 19 Mar 2013 13:58:31 -0700
Cc: "Matthias Schunter (Intel Corporation)" <mts-std@schunter.org>, "public-tracking@w3.org (public-tracking@w3.org)" <public-tracking@w3.org>
Message-id: <F9BAC4A4-6D48-4779-821E-1699D794CAD4@apple.com>
To: Jonathan Mayer <jmayer@stanford.edu>

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.
Received on Tuesday, 19 March 2013 20:59:00 UTC

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