W3C home > Mailing lists > Public > public-webcrypto-comments@w3.org > October 2012

security of a client-side JS API?

From: Arthur D. Edelstein <arthuredelstein@gmail.com>
Date: Tue, 30 Oct 2012 13:43:43 -0700
Message-ID: <CADHWJb5Pa-Ohnpj-duyWHyzK6-+3FTwB4Wi7JRHiJ8JsLaNTBA@mail.gmail.com>
To: public-webcrypto-comments@w3.org
Hi Everyone,

I've read through the WG and public comments list archives, and I am
concerned that an objection partially raised in the WG mailing list
("Is our deliverable doomed ?", 18 September) hasn't really been
clearly addressed.

The API is supposed to be used inside a web app's client-side JS
runtime. But the problem with client-side JS is that it is under the
full control of neither the user nor the web app provider. The app
provider (though she trusts her own web app JS code) doesn't know if
the WebCrypto API is running correctly and honestly on a particular
user agent instance, and the user (though he may trust the user agent)
can't know if the client-side web app is using the API correctly and
honestly. So in practice, neither side can have confidence in these
utility functions.

Numerous cryptographic solutions exist for the server side already, so
it seems to me that responsible web app providers are going to prefer
to do their cryptographic operations on the server, in an environment
they control, rather than use this API. Worse, people who do use this
API may have misplaced confidence in its security.

So I think it would be useful, in the specification, to clearly state
what security guarantees can and cannot be delivered by this API, and
when it is better (for web app developers) to use server-side crypto
libraries. Thanks in advance for considering my comment.

Sincerely,
Arthur Edelstein
UC San Francisco
Received on Wednesday, 31 October 2012 10:44:31 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 31 October 2012 10:44:31 GMT