Re: Proposal: getRandomValues for Workers

No, it does not make it any easier or harder to do so.

Implementations can already do that today - getRandomValues is
declared as blocking - it's just an undesirable characteristic.
Despite the fact that "blocking" APIs are permitted on workers, the
availability of such APIs does not make it any better or desirable to
actually implement said APIs using blocking methods (blocking file
reads via FileAPI or via /dev/random).

Also, I suspect (but have not fully considered) that exposing such
blocking sources of randomness may be highly undesirable to expose to
web content (entropy drain). The previous specification (from WHATWG)
specifically stated that it was a value obtained from a *generator*
seeded with truly random values/high quality values.

On Wed, Oct 10, 2012 at 5:20 PM, Nadim Kobeissi <nadim@nadim.cc> wrote:
> 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:32:24 UTC