Re: Require security review before FPWD

I think we can say in the process that by the time that formal approvals are happening, they may be held up or the document may be disapproved if there appear to be questions in any of these areas and no evidence of any systematic consideration of those questions.

Yes, I agree, by the time of (e.g.) CR transition, people may have started implementing, and it may be ‘late’, but late is better than never.

So, if you turn up at CR transition with a spec. that transmits passwords and personal data over unsecured channel, uses only the 0-0x7F range of Unicode and presents important information to the user using an audio signal only, well, expect eyebrows to go up and approval to be delayed or not occur. 

I have struggled with writing the ‘security considerations’ section of IETF RFCs for specifications that don’t appear to have any, and so I am not a fan of insisting on specific sections for these areas.  I am a fan of getting to the state where documents self-evidently don’t have issues or there is evidence that they have been considered and addressed.

On Nov 4, 2014, at 8:40 , GALINDO Virginie <> wrote:

> +1 for the guidelines, and security at early stage, w3c can not afford at the moment to have systematic security review, unless we recruit a larger security expert community.
> Virginie
> ---- Karl Dubost a écrit ----
> [....]
>> Do not make it part of the process.
>> On the other hand, publish a set of guidelines and how to implement them for reviewing security issues *when* editing a spec.
>> --
>> Karl Dubost 🐄
> ________________________________
> This message and any attachments are intended solely for the addressees and may contain confidential information. Any unauthorized use or disclosure, either whole or partial, is prohibited.
> E-mails are susceptible to alteration. Our company shall not be liable for the message if altered, changed or falsified. If you are not the intended recipient of this message, please delete it and notify the sender.
> Although all reasonable efforts have been made to keep this transmission free from viruses, the sender will not be liable for damages caused by a transmitted virus.

David Singer
Manager, Software Standards, Apple Inc.

Received on Tuesday, 4 November 2014 09:19:40 UTC