W3C home > Mailing lists > Public > public-w3process@w3.org > November 2014

Re: Require security review before FPWD

From: David Singer <singer@apple.com>
Date: Mon, 3 Nov 2014 12:10:24 +0000
Cc: public-w3process <public-w3process@w3.org>
Message-Id: <5542E051-0807-409B-99A0-853AF15FC4FE@apple.com>
To: Anne van Kesteren <annevk@annevk.nl>

On Nov 3, 2014, at 11:30 , Anne van Kesteren <annevk@annevk.nl> wrote:

> On Mon, Nov 3, 2014 at 12:27 PM, David Singer <singer@apple.com> wrote:
>> By the time the w3c indicates that something is implementable, i.e. that implementations
>> start occurring and hence security/accessibility/privacy/i18nability issues actually hit people,
>> we should be clear that the appropriate reviews have been done, not that they were done
>> explicitly at FPWD or at any other particular named stage.
> The W3C hasn't even decided yet to my knowledge whether it wants to
> endorse DRM, yet various browsers implemented it. Again, this is not
> how things work.

Since I have no idea how we got from ‘when is it required that an XXX review be done?’ to ‘has the W3C endorsed DRM?’ I can only conclude that we’re seriously at cross purposes.

I don’t want the w3c to encourage people to implement specs that, if implemented would
* put systems at risk (security issue)
* put people’s privacy at risk
* have significant issues in deployment across some languages or scripts (i18n issue)
* have significant issues in accessibility

and all I am saying, my only point, is that I don’t care to put a specific timepoint on when these checks are done (e.g. “must be done on the FPWD candidate before FPWD FPWD publication”) as long as we don’t get to the point where the specs are implemented and deployed BEFORE we find significant issues.  That’s all.  Don’t encourage people to implement a spec. and then say ‘oops, it has a serious privacy problem’. That’s not responsible behavior.

David Singer
Manager, Software Standards, Apple Inc.
Received on Monday, 3 November 2014 12:11:03 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:51:22 UTC