- From: David Singer <singer@apple.com>
- Date: Tue, 19 Mar 2013 13:58:31 -0700
- To: Jonathan Mayer <jmayer@stanford.edu>
- 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>
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