Re: [liberationtech] W3C WebCrypto Last Call for Comments *today*

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 2014.05.26 15.54, Anders Rundgren wrote:
> I guess the problem is that writing secure applications remain
> difficult.
> 
> The (in)famous "heartblead" bug is is a recent example of that. 
> Promising secure applications by using secure algorithms would be
> wrong because that is only a part of the problem.
> 
> Packaged solutions may provide solutions for people with limited 
> knowledge of secure applications.  Such packages can be written on 
> top of APIs such as WebCrypto.

This is a complete abdication of your duty to the community.  You are
suggesting that primitives intentionally enable dangerous features
because "security is hard" and "people could write bugs anyway".  This
is an utter joke and a direct sabotage of the security of the largest
computing platform we have right now.

FIX YOU BUGS IN THE PLATFORM OR DON'T PRETEND YOU'RE HELPING SECURITY
AT ALL.

This is *not* hard.

> We must not forget that the banks haven't managed creating secure 
> credit-card payments on the web although they have had 20 years to
> think about it :-)
> 
> Due to the latter no even the "secure" EMV-cards are more secure 
> than the non-secure dittos when used on the Internet.

Again, thank you for using the failures of other industries to excuse
your own.  Which side are you actually on?

> WebCrypto will hopefully spur further innovation in this field!

I look forward to putting your innovation in body bags.

E.

> On 2014-05-24 13:19, Eleanor Saitta wrote: On 2014.05.24 09.54,
> GALINDO Virginie wrote:
>>>> Anyway, thanks for taking the time to share your view with
>>>> us. You are pointing us to an interesting problem, that we
>>>> discussed intensively. We are currently trying to see how to
>>>> word warning to developers in the specification to encourage
>>>> them to understand the web security big picture. That task is
>>>> not easy due to the always-living side of the
>>>> security/cryptography science.
> 
> I find this approach a little worrying.  While clearly warning 
> developers is obviously preferable to *not* doing so, it's also
> been shown to be largely insufficient over the past 20-odd years.
> If the default behavior of a system is unsafe, developers will
> generally implement that behavior, regardless of what your
> documentation warns them to do.  It would be better for the state
> of web security to provide a significantly more limited but default
> safe API.
> 
> If there is no API, developers needing to solve related issues
> will roll their own and get it wrong -- the state we have now.  If
> there is a safe API, they're more likely to make architectural
> choices on the basis of that API, because you've shaped the level
> of effort from "either way I'm going to have to do everything" to
> "I can stay within this box that I recognize as being trustable, or
> I can do all the work myself".  Shipping an API that allows
> developers to be unsafe puts you right back in the position where
> they can choose to shoot themselves and their users in their
> respective heads with no extra effort.
> 
> Every time we see bug classes entirely eliminated at the platform 
> level, we see those bugs mostly go away in the wild.  Every time
> we see "guidance" provided, we see little or no impact in the
> incidence of those bugs.  The web crypto API will be used in
> life-safety critical code.  If you get this wrong, people will
> die.
> 
> Enjoy your guidance.
> 
> E.
> 
>> 
>> 

- -- 
Ideas are my favorite toys.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (MingW32)

iF4EAREIAAYFAlOFuxQACgkQQwkE2RkM0wpyHQD+IhNCV8FRsb7pUpm45weuZbxt
IJCzNXR4L1jSt0g9TMsA/Rea6H53yzBvYBzEg23epdup464t52k6pK4wTQOpauYw
=tOki
-----END PGP SIGNATURE-----

Received on Wednesday, 28 May 2014 10:33:35 UTC