W3C home > Mailing lists > Public > public-w3process@w3.org > November 2014

Re: Require security review before FPWD

From: Anne van Kesteren <annevk@annevk.nl>
Date: Sun, 2 Nov 2014 17:47:07 +0100
Message-ID: <CADnb78iy1OPinCtf2NLRoY2eOrny8GnGaMmg3ZHnyrz8nFVBfA@mail.gmail.com>
To: Jeff Jaffe <jeff@w3.org>
Cc: Philippe Le Hegaret <plh@w3.org>, public-w3process <public-w3process@w3.org>
On Sun, Nov 2, 2014 at 3:22 PM, Jeff Jaffe <jeff@w3.org> wrote:
> For example, I've received considerable input that our standards get out of
> date quickly.

Well, if you declare a year old copy as Recommendation, that should
not come as a surprise.


> More to the point - about things that we botch where early attention would
> be useful - (while I'm not an expert in accessibility) I'm told that we need
> more attention on accessibility, and that web accessibility continues to be
> a challenge for people with disabilities.

I agree that new features we introduce should be accessible, though
for some things this is hard (e.g. WebGL, WebVR). When the WHATWG
worked out <canvas> it was initially a void element (could not have
descendants). I fought quite hard at the time to change its parsing
behavior so it could have some form of fallback. That's an example I
can think of and we ended up being able to change that around.


> Perhaps you argue, however, that for security (more than other areas) if we
> don't start with security retrofitting later is harder.

It is hard to require TLS for a feature later if you already allow it
to be used without TLS. This kind of baseline requirement is not
really in play for other aspects as much I think.


> This is certainly a plausible argument - but it still leaves open the
> question as to what is the best solution.  Oftentimes an FPWD is very
> minimal in completeness.  Fundamental changes in design; changes in author;
> new security exposures can easily creep in during the path from FPWD to REC.
> So a review before FPWD is not a panacea.
>
> Who is best to judge when is the best time for the security review? The
> current philosophy is to require that a set of things get done before CR -
> and leave it to the WG to determine the best timing. That is why I suggested
> requiring to do before CR and suggesting to do it early (and I might add
> early and often).

Well, we have WebRTC and EME as examples where deployed non-TLS
content seems to have considerable weight, more so than the security
and privacy concerns of end users. The question is whether we want
this to continue or make sure it cannot happen again.


-- 
https://annevankesteren.nl/
Received on Sunday, 2 November 2014 16:47:34 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:35:12 UTC