Re: Require security review before FPWD

TL;DR: Noting what security review has been done is a good thing for any spec (including an editor's draft that is considered too immature for FPWD). A blanket rule like insisting on TLS for everything always, as if processing were free, is not a good idea.

02.11.2014, 17:47, "Anne van Kesteren" <annevk@annevk.nl>:
> On Sun, Nov 2, 2014 at 3:22 PM, Jeff Jaffe <jeff@w3.org> wrote:
...
>> š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).

Maybe, but given some resourcing and an ability to get the work done without too heavy a hand insisting on following process (e.g. blocking on publishing just because you have recognised areas that need further discussion) there were real opportunities to build on a lot of pre-existing work in accessibility that had been done in this space.

Ideally, without holding up the initial publication and implementation experience.

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

Which happened well after canvas had been shipping. What was necessary and present was the knowledge that there were potential issues, the will to change things in order to address them, and the work to figure out what that would mean.

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

Actually a lot of things in the Web have been shipped without TLS. Maybe a billion people had unsecured webmail before there was a serious push to change that. Fixing the problems that was deemed to have didn't rely on not shipping anything until we had made a decision that it would be better to require 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.

There are a range of alternatives. Being able to use TLS with WebRTC is not the same as not caring about privacy - it is equally feasible that I would opt to have an unsecured conversation with someone on a line I knew could be listened to, while at the same time waiting until I established a secure connection before I even considered calling someone else.

> The question is whether we want
> this to continue or make sure it cannot happen again.

Look at the issues in these cases:
- Someone eavesdropping might discover that I watch a particular pay-per-view news channel, or a rather silly movie
- I will need to have more power, or suffer an inferior experience, in order to use a secured connection. With my day-to-day network setup I use for working (the best connection I could get in my area) that is a trade-off I actively manage during the day.
- The increased requirements for hardware and electricity to serve the content will potentially have some noticeable environmental impact when scaled out to the world. I'm interested in understanding more about whether this is serious before I decide whether *everything always secure* is the best solution available.
- There is a risk that saying something is required will be ignoring reality of implementation.

Particularly if the latter happens, we may well find that we have introduced this gating process requirement without achieving the stated goal. That would be unfortunate.

So yes, I think it is reasonable to make it possible for technology to optionally run unsecured if doing so is a best fit for the use cases.

That said, describing within a spec the security questions that have been *considered* and pointing to the discussions and resolutions seems like an extremely good practice.

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

Received on Sunday, 2 November 2014 21:32:49 UTC