Re: Require security review before FPWD

On Nov 14, 2014, at 7:31 , chaals@yandex-team.ru wrote:

> 
> 
> 14.11.2014, 13:59, "Henri Sivonen" <hsivonen@hsivonen.fi>:
>> On Tue, Nov 4, 2014 at 12:14 AM, Jeff Jaffe <jeff@w3.org> wrote:
>>>  On 11/3/2014 8:01 AM, Henri Sivonen wrote:
>>>>  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.
>>> 
>>>  An interesting question is to understand how far you want to take this.
>>>  There is a range.  At the "lightest" end of the spectrum these reviews are
>>>  to provide advice.  At the "heaviest" end of the spectrum, failure to
>>>  achieve a certain level of security could be a reason for a REC to be
>>>  blocked.  In that interpretation, EME and WebRTC could potentially still be
>>>  blocked.
>>> 
>>>  When you say "deal with the case where the WG doesn't want to mandate TLS
>>>  even when it is needed" - I hear you on the more intrusive side of the
>>>  spectrum.  Is that a correct interpretation?
>> 
>> While I'm generally not a fan of some oversight group that hasn't
>> looked deeply into a particular issue exercising high-level oversight
>> (e.g. "must be more XML-y" attitude of the yesteryer) with less domain
>> knowledge than a group working on a particular spec, in this case, I
>> think in this case there's a need for oversight on the more intrusive
>> side. Specifically, it seems to me that each group wants their thing
>> to be popular among authors, sees a restriction to https as hindering
>> popularity among authors and will, therefore, come up with excuses why
>> their stuff shouldn't be restricted to https. Once restriction to
>> https for privacy-sensitive stuff comes as naturally to groups as the
>> notion that textual data should be Unicode comes today, oversight will
>> be less necessary.
> 
> The initially stated request was "let's have a security review requirement”.

well, perhaps more “evidence that an adequate consideration has been given to XXX” where XXX is security, privacy, accessibility, etc.

> While people may or may not be happy gating e.g. First Public Working  Draft on doing that "adequately", it seems clear that there is overwhelming support for the idea of getting better technical review for security. 

yes, we cannot issue specs without thinking about security and privacy and …

> 
> But from this exchange and others like it, that it isn't what is being asked for. Instead, the thread seems to be "can we have a process requirement to enforce TLS-everywhere"?
> 
> That  is not a sensible process question, but a technical one. It should be followed up through e.g. the Security group and the TAG - if you build a strong technical consensus that TLS-everywhere is essential, *then* it might be something that the process requires, or (as is more common for technical dependencies) charters won't get through without addressing it.
> 
> But trying to push a particular technical barrow by manipulating the governance documents into enforcing it isn't the way that W3C works.
> 
> (And as noted above, if you build a strong technical consensus that TLS-everywhere is needed, I would expect that to stop specs going to Rec - same as if you build a strong consensus around any other issue).

Yes.  Persuade people that there are security or privacy issues even for the most benign of interactions unless TLS is involved. But do that by (perhaps) issuing a thought-paper outlining why, gettng the TAG to recommend it, and doing review on specs that lack it and pointing out what might go wrong.

David Singer
Manager, Software Standards, Apple Inc.

Received on Friday, 14 November 2014 16:56:47 UTC