RE: Goals and Procedures

Yes, the browsers have to implement the API, browser extension wont hack it,
though WebExtensions makes them more available on different browsers. Not on
mobile though, unfortunately.

Another possibility for the API is in a polyfill library. I know it cannot
generate the header, but a well-known named cookie could replace it, along
with clever JS (and being more brutal with subresources).

But still we have to have browser implementations. As GDPR gets closer we
might see more action, and an Opinion from WP29 might help., so let's see.

6 months might be a bit too short though.



> -----Original Message-----
> From: Roy T. Fielding [mailto:fielding@gbiv.com]
> Sent: 07 February 2017 18:45
> To: Matthias Schunter <mts-std@schunter.org>
> Cc: public-tracking@w3.org (public-tracking@w3.org) <public-
> tracking@w3.org>
> Subject: Re: Goals and Procedures
> 
> > 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 Wednesday, 8 February 2017 11:56:45 UTC