Re: security of a client-side JS API?

Hi Ryan,

Thanks for your very thorough and thoughtful response.

>> Users will need to trust the web app to properly

> > secure their data, which is the status quo.
>
> Is this different from native apps, which requires the user trust the
> application vendor?
>

Indeed I worry this is just as bad as most native apps, and just as bad as
the web currently is, for user data security.

>> Web app providers are also threatened by a leaky implementation of the
>> Crypto API in a web client (for example, a bot with a bad RNG or key
>> generator). So providers will prefer to use server side key generators,
etc.

 I don't think this is necessarily true - there are a host of reasons
> why providers are strongly incentivized not to do crypto on their end,
> most notably legal reasons.
>
> What sort of legal reasons do you have in mind? I think if legal
protection for providers is the most notable motivation for providing the
Crypto API, that should be explained in the draft, as well as any other
important motivations.

But I think it's also important to mention the issue of hostile web bots --
it's really impossible for the server to trust crypto results from the web
client.


> But even more broadly, how does this at all differ from native
> applications? They're just as dependent on the platforms cryptographic
> stack. Servers have no control over that end.
>

Yes, I agree. Which is why server-side crypto is necessary for the securing
the provider's data. Platform vulnerabilities are a problem, but that
doesn't excuse vulnerabilities in user agents.

Perhaps I'm mistaken, but we're not trying to necessarily provide new
> security guarantees over existing native applications - we're
> attempting to bring (some of) the same security model to the web -
> which suggests improving the web security model.
>

I'm arguing that you're not improving the web security model. Web browsers
already support secure communication between a provider and a user agent
(by TLS), but users are forced to trust the provider with their (user)
data. This API, even with CSP, similarly requires that the web app provider
be trusted by the user not to leak data.

So all the additional cryptographics primitives, because they are untrusted
by both users and providers, don't plug any holes that weren't already
plugged by TLS.

To put it differently, nothing of this API is trying to make the
> connection *more* trustworthy - that requires much more work across
> many different domains, and which have little-to-no reliance or need
> for cryptography to do that.


In my view, end-to-end encryption, implemented in the browser, would
provide a major, important upgrade to the web security model and make
communications (including most of the use cases presented in your draft)
much more trustworthy. End-to-end encryption necessarily means that
cryptographic operations would be controlled by the user, not by the web
app client-side JS, and that the JS code would only have access to the
encrypted material.

Browsers could provide a means for users to encrypt the text the wish to
enter in a TextArea, to display decrypted text, and to encrypt and decrypt
files, all safely outside the page's JS runtime. This enhancement would
give users of existing web services, such as web-based email, chat and file
storage a major security boost. PGP and OTR modes would both be useful.

Is there any chance the Web Crypto WG could recommend this kind of browser
end-to-end crypto design? I think this alternative offers huge advantages
over the proposed API for addressing the use cases you describe in the
draft.

Thanks again for so patiently hearing me out!

Best regards,
Arthur