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

----- Original Message -----
> From: "Ryan Sleevi" <>
> To: "Web Cryptography Working Group" <>
> 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