- From: Matthias Schunter (Intel Corporation) <mts-std@schunter.org>
- Date: Wed, 20 Mar 2013 23:29:02 +0100
- To: public-tracking@w3.org
- Message-ID: <514A382E.2070508@schunter.org>
Hi Jonathan, you indicated that you are OK with the new approach if there is a standard how a site collects consent. The current language in the spec that tries to constitute such a standard is in Section 6.3.1: > "User Interaction > > The call to store an exception /MUST/ reflect the user's intention to > grant an exception, at the time of the call. This intention /MUST/ be > determined by the site prior to each call to store an exception, at > the time of the call. (This allows the user to change their mind, and > delete a stored exception, which might then trigger the site to > explain, and ask for, the exception again). It is the responsibility > solely of the site making the call to determine that a call to record > an exception reflects the user's informed consent at the time of the > call." > If you deem this language insufficient, could you come up with an alternative/extension that addresses your final remaining concern of a race to the bottom? Regards, matthias On 19/03/2013 22:46, David Singer wrote: > > On Mar 19, 2013, at 14:36 , Jonathan Mayer <jmayer@stanford.edu > <mailto: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 >>> <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. >>> >> > > David Singer > Multimedia and Software Standards, Apple Inc. >
Received on Wednesday, 20 March 2013 22:29:29 UTC