- From: Roy T. Fielding <fielding@gbiv.com>
- Date: Tue, 7 Feb 2017 10:44:47 -0800
- To: Matthias Schunter <mts-std@schunter.org>
- Cc: "public-tracking@w3.org (public-tracking@w3.org)" <public-tracking@w3.org>
> On Feb 7, 2017, at 12:35 AM, Matthias Schunter (Intel Corporation) <mts-std@schunter.org> wrote: > > Hi Folks, > > > thanks a lot for the productive discussion during yesterday's call. > It is nice to actually start closing issues and progress towards our > goal of a stable final draft. Issues are usually closed after the work has been published. Can you just tag them as something like wg-consensus or editor-ready? Also, I don't see any minutes posted for the last two meetings. I don't think that is optional. I should be able to get to edit the draft next week, if David doesn't beat me to it. > What I realized (since time is short) is that we should constrain > ourselves on a minimal spec that is good enough. > > What this means: > - We should focus on helping EU compliance > - We should improve implementability > - We should try to abstain from fundamental redesigns and > substantial new features. > > What does this mean for the group? > > I suggest we focus only on substantial concerns backed by evidence. This > means that we should focus on issues that: > - Substantially simplify or improve implementation. > Evidence could be implementation experiences/reports. > (e.g. Mike stating that it is useful for a site to receive a call-back > is in this category). > - Substantially help EU enterprises to manage opt-in for compliance > Evidence could be enterprise/site feedback or regulator requirements. > (e.g. Rob saying that the Javascript exception API is > essential for managing opt-in and should be kept is in > this category). > - Are required by W3C to reach recommendation state > > As indicated, the goal is to deliver a "good enough" TPE in time and > ideally simple enough to be widely implemented. Ideally, I would hope > that no other changes are required at this point. > > Does everyone agree with this procedure? Any feeback or objections? I don't agree. Implementation of a consent framework requires near-universal deployment (sufficient to cover users that actually want to provide consent while using the browser of their choice). A plugin isn't even capable of approaching that level of deployment. We would be misleading the Web community if we claimed that a specification is ready for Recommendation when it depends on an API that nobody has deployed in shipping browsers. We have three choices here: 1) We keep the API and let the spec stay at WD/CR until there is sufficient deployment usage to justify recommending it as a standard; 2) We remove the parts that haven't been deployed and define workable solutions using existing deployments; or, 3) We change the spec to a Note and close the WG. I think industry has already moved on to (2), since the first option is outside their control and isn't going to happen before the GDPR deadline. I don't know what exactly Rob said about the consensus mechanisms, but the current API certainly isn't essential for managing opt-in. In fact, opt-in has to be managed by the server because only the server is compelled by regulation. Even if a DNT:0 is received, the server will need to remember what has been consented (it must be specific), so DNT:0 would have to be combined with cookies indicating to what and when the user agreed. My preference would be to make a few tweaks to the API and then do a survey of the browsers. Unless at least three of the currently shipping browsers have implemented the API within six months, we should remove it from the spec entirely and start a new CR (or just give up and republish as a Note). If anyone wants to work on deployable alternatives, they are welcome to do so as proposals outside of the WG specification. The chairs can decide when (or if) those proposals are worth discussing. They might be usable without being part of a standard, or we might consider making them a standard after other options have been exhausted. Cheers, Roy T. Fielding <http://roy.gbiv.com/> Senior Principal Scientist, Adobe <https://www.adobe.com/>
Received on Tuesday, 7 February 2017 18:45:17 UTC