Re: security of a client-side JS API?

On Tue, Oct 30, 2012 at 1:43 PM, Arthur D. Edelstein
<arthuredelstein@gmail.com> wrote:
> 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.

Perhaps I've misunderstood the concern, but could you elaborate on
"correctly and honestly"?

My initial reading is that "correctly and honestly" are something that
could be established through the use of Content-Security-Policy, so
I'd be curious to know under what situations that is not the case.

>
> 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:52:38 UTC