Re: Require security review before FPWD

On Mon, Nov 3, 2014 at 5:41 AM, Jeff Jaffe <jeff@w3.org> wrote:
>
> On 11/2/2014 11:47 AM, Anne van Kesteren wrote:
>>>
>>> >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.
>
>
> From a pure technical specifications pov, if a WG decides that it wants to
> mandate TLS, I don't understand why it makes a difference whether it does it
> at FPWD or at CR.  In either case, TLS is mandated.

The problem to be solved is making sure that implementors don't ship
without an "https-only" restriction when APIs really needed such a
restriction for privacy. Since the notion that implementation starts
at CR is fiction, CR is too late.

> But I assume you are not talking about pure technical specifications.  You
> are talking about when implementers are implementing products without TLS.
> If the existing product implementations are a boat anchor which convinces a
> WG not to mandate TLS, there could be a problem.

Right.

> Surely we want the right architecture.  So if the WG wants to mandate TLS,
> they should.

I think there's also a need to deal with the case where the WG doesn't
really want to mandate TLS even when mandating TLS in needed. That is,
there's a need of *early* oversight for WGs that don't realize things
early on their own initiative.

> After all, there could be implementation baggage before even reaching FPWD,

That's possible, but that's not an argument for deferring review to
later than FPWD. It might be an argument for doing it earlier.

On Fri, Oct 31, 2014 at 8:28 PM, Philippe Le Hegaret <plh@w3.org> wrote:
> Finally, why stop at security (and privacy)? What about accessibility,
> i18n, device independence, performance, etc? We would effectively send a
> message that security/privacy is more important for early reviews than
> those other areas.

I think the difference is that of late, I don't recall there being
a11y, i18n or performance blunders that were terribly difficult to
address later.

However, considering geolocation, WebRTC, EME and Service Workers,
only Service Workers required https early enough and now it's hard to
change the https requirement status of the other three even when the
shipping implementations are supposedly experimental in the sense of
being prefixed. (Prefixed shipped features being experimental is
fiction, of course.)

It seems like a bad idea not to address the problem we have because
there are other areas that theoretically could benefit from similar
reviews but haven't show the same level of problem in practice.

-- 
Henri Sivonen
hsivonen@hsivonen.fi
https://hsivonen.fi/

Received on Monday, 3 November 2014 13:01:50 UTC