Re: Require security review before FPWD

On 11/2/2014 5:20 AM, Anne van Kesteren wrote:
> On Sun, Nov 2, 2014 at 8:23 AM, Jeff Jaffe <jeff@w3.org> wrote:
>> This is a specific example of something more general.
> Any examples of non-security related requirements that we botched?
>
>

We are certainly not perfect!

For example, I've received considerable input that our standards get out 
of date quickly.  So much so, that we are looking at introducing a 
Living Standards-like capability [1]; at least to deal with Errata.

[1] http://lists.w3.org/Archives/Public/public-w3process/2014Nov/0004.html

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.

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

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).

Received on Sunday, 2 November 2014 14:22:49 UTC