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

Re: crypto-ISSUE-21: Requiring Content-Security-Policy [Web Cryptography API]

From: David Dahl <ddahl@mozilla.com>
Date: Mon, 20 Aug 2012 09:38:49 -0700 (PDT)
To: Ryan Sleevi <sleevi@google.com>
Cc: Web Cryptography Working Group <public-webcrypto@w3.org>
Message-ID: <834438794.4428715.1345480729794.JavaMail.root@mozilla.com>

----- Original Message -----
> From: "Ryan Sleevi" <sleevi@google.com>
> To: "Web Cryptography Working Group" <public-webcrypto@w3.org>
> Sent: Monday, August 20, 2012 9:32:51 AM
> Subject: Re: crypto-ISSUE-21: Requiring Content-Security-Policy [Web  Cryptography API]

> My vote: Prevent *any* of the Crypto interface from being exposed
> without there also being a super-locked-down CSP.

I think the only thing this will hamper is developers first foray into this API where they have no ability to enable CSP - in which case implementations can add a "cryptoAPI whitelist server" pref for development and testing 

> I'm not convinced there will be significant speed advantages by
> performing hashing in native code, as it's traditionally not big-num
> intensive. Rather, JS can do quite well for most common hash
> constructions - quite near native performance, particularly when
> using
> Typed Arrays. As such, trying to split the Crypto interface into a
> 'partial' interface that respects security boundaries such as this
> seems overly complex and with little benefit.

I don't see the harm in allowing a Hash operation regardless, but it may be confusing if we allow certain operations and not others in a non-CSP enviromnent.


Received on Monday, 20 August 2012 16:39:16 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:01:25 UTC