Re: security of a client-side JS API?

On Wed, Oct 31, 2012 at 4:34 AM, Arthur D. Edelstein
<arthuredelstein@gmail.com> wrote:
> Hi Ryan,
>
> Thanks for the reply. Sorry for not being clear. By "correct and honest" I
> meant code that doesn't leak data (through malice or incompetence) to
> parties that aren't supposed to have it.
>
> I don't think Content-Security-Policy protects either the users or the web
> app providers from leaky code. Users can be attacked by leaky JS code
> running in the user agent (CSP doesn't guarantee to the user that the web
> app isn't delivering JS code from the one of the permitted hosts to steal
> user data, a la Hushmail). 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?

>
> 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.

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.

>
> As far as I can tell, neither side can trust the cryptographic results,
> because neither side has control of both the Crypto API implementation and
> the code that is using it.
>
> So I feel that this standard doesn't provide any new security guarantees,
> either to the user or the web app provider. I am missing something? Thanks
> again.
>
> Best regards,
> Arthur

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.

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.

Received on Wednesday, 31 October 2012 12:45:25 UTC