Re: Require security review before FPWD

You're getting into the weeds of a specific example of why I think we should not be making a blanket policy that overly restricts us.

It also appears that you are trying to make a blanket policy to require a review, in order to enforce a single constraint (use TLS everywhere). That's the wrong way to do things - if you want to enforce that single constraint, it is a technical issue. You should for example convince the TAG that it is a hard requirement, which presumably means the cost is always outweighed by the benefits.

If you are trying to accomplish that technical goal, this isn't the place to do it. 

As I said, although I disagree with the specific blocks to progress you mooted in your process proposal, I do support clarifying the review status in a number of areas.

However we should be aware that security review (like internationalisation, accessibility, etc) isn't a boolean property, and the fact that somebody did one doesn't mean that no more is required. There is a risk that the labeling of "this had a security review" will give people a false sense of how likely it is that there are remaining issues…

cheers

03.11.2014, 13:40, "Anne van Kesteren" <annevk@annevk.nl>:
> On Sun, Nov 2, 2014 at 10:32 PM,  <chaals@yandex-team.ru> wrote:
>>  I will need to have more power, or suffer an inferior experience, in order to use a secured connection.
>
> Just to be clear, this is nonsense. TLS these days hardly has
> overhead. I recommend studying https://istlsfastyet.com/
>
> I also take issue with the argument that an average user can juggle
> these concerns adequately. They should not have to know about the
> difference between plain text and secure connections. That's too much
> of an implementation detail.
>
> (As for <canvas>, one implementation was shipping, not two, which made
> it possible to change the status quo.)
>
> --
> https://annevankesteren.nl/

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

Received on Tuesday, 4 November 2014 07:35:58 UTC