Re: Require security review before FPWD

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

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

cheers

--
Charles McCathie Nevile - web standards - CTO Office, Yandex
chaals@yandex-team.ru - - - Find more at http://yandex.com

Received on Friday, 14 November 2014 15:32:02 UTC