Re: Proposal: getRandomValues for Workers

This would totally pave the way for being able to use blocking sources
of randomness as well, like /dev/random

NK

On 10/10/2012 8:13 PM, Ryan Sleevi wrote:
> The current Editor's Draft, as well as the FPWD, do not currently
> specify which objects implement the "Crypto" interface. As previously
> discussed, the intent was that there would be normative text to the
> effect of
> 
> partial interface Window {
>   readonly attribute Crypto crypto
> };
> 
> which enables window.crypto.* to actually work. This was previously
> included in the WHATWG work -
> http://wiki.whatwg.org/index.php?title=Crypto&oldid=8471
> 
> While we still need to resolve issues regarding the synchronous API (
> ISSUE 24 ), I'd like to propose that crypto.getRandomValues be exposed
> via WorkerGlobalScope
> 
> partial interface WorkerCrypto {
>    ArrayBufferView getRandomValues(ArrayBufferView array);
> };
> 
> partial interface WorkerGlobalScope {
>   readonly attribute WorkerCrypto crypto;
> };
> 
> 
> Note that I'm not (yet) proposing exposing the entire Crypto interface
> - I think there's a lot of unspecified behaviour regarding multiple
> 'threads' (let alone browsing contexts) performing operations with
> Keys that will need to be carefully thought through, but it seems
> reasonable to propose that this specific method be made available to
> workers as well.
> 
> Mozilla has currently implemented window.crypto.getRandomValues (
> https://bugzilla.mozilla.org/show_bug.cgi?id=440046 ), and it has also
> been implemented in WebKit (as used by Safari and Chromium/Chrome -
> https://bugs.webkit.org/show_bug.cgi?id=22049 )
> 
> It's not clear to me whether it's necessary to specify a WorkerCrypto
> object, but since I imagine that there will be methods (or
> constructors) that are specific to Workers (since synchronous APIs on
> the global Window object are wholly undesirable), it seems like the
> good first start.
>

Received on Thursday, 11 October 2012 00:20:31 UTC