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

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.

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.

WebCrypto will hopefully spur further innovation in this field!

Anders

On 2014-05-24 13:19, Eleanor Saitta wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> 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)
>
> iF4EAREIAAYFAlOAgCQACgkQQwkE2RkM0wpFxgD/QhvqIBmveR+H29P7dV76c9fC
> GZPvyZtFvSxvaZM++pcA/jftFah8wVbjsUz13A8kWl+Acd/ZSyZZCZQATPQAKJaX
> =SanX
> -----END PGP SIGNATURE-----
>
>

Received on Monday, 26 May 2014 14:55:31 UTC