[whatwg] Cryptographically strong random numbers

David Bruant bruant at enseirb-matmeca.fr
Mon Feb 14 14:50:36 PST 2011

[adding Cameron McCormack, Web IDL editor, to the discussion]

Le 14/02/2011 22:29, Adam Barth a écrit :
> On Mon, Feb 14, 2011 at 12:49 PM, Brendan Eich <brendan at mozilla.org> wrote:
>> On Feb 14, 2011, at 12:26 PM, Adam Barth wrote:
>> On Mon, Feb 14, 2011 at 11:56 AM, Brendan Eich <brendan at mozilla.org>wrote:
>> Extending the old window.crypto object we added ages ago at Netscape may be
>> a good idea and a faster route to a high-quality cross-browser RBG. I won't
>> argue about that. My objection here is to your choice of words and the way
>> they might foreclose better cooperation among vendors: such an RBG API is
>> not done "today", and it needs more than just one implementation to be a
>> standard other browsers will implement
> I chose my words poorly.  What I was trying to communicate is that I'd love
> to see ECMAScript grow a beautiful crypto library that included lots of
> useful tools, including HMACs, stream ciphers, PRNGs, etc.  TC39 is in a
> massively better position to do that work than the whatwg.  However, at this
> point in time, adding a simple source of cryptographic random numbers to
> window.crypto is much simpler proposition (e.g., on the order of one day of
> work).
This last point is what worried me and encouraged me to question what
was the best place to discuss the addition of a strong RNG.

The WHATWG can indeed start a proposition which could be written in one
day. The ECMAScript can also decide to grow a "beautiful crypto
library". But when all of that will be standardized and implemented, web
developers will have 2 librairies to generate strong RNG. They need only
The problem here is that the main use case overlap in both
comitee/working group: "getting cryptographically strong random numbers".

This is actually the exact same situation that happens with concurrency.
WHATWG came out with WebWorkers and ECMA TC-39 is working on Vats. Once
again, overlapping of use cases. Fortunately, on the ECMA proposal
(http://wiki.ecmascript.org/doku.php?id=strawman:concurrency), is
written "We intend that WebWorkers can be implemented in terms of vats
and vice versa.". But if it wasn't the case, web developers would have
two different visions of concurrency (if Vats are standardized and
implemented, they are going to have two tools anyway).

I think I agree with earlier Brendan Eich's idea
"It seems to me we (whatwg members, w3c members; browser vendors in
general) need something more than IDL in the way of a spec."
(I understand "IDL" as "the WebIDL spec" (http://www.w3.org/TR/WebIDL/))
and I would even add the TC-39 comittee.

I'm not against innovation, prototyping. I do not really care if
standardization takes one day or ten years. However, as a web developer,
I do not need several tools to solve the exact same use case. We've seen
how hurtful to the web was the IE DOM (innerText VS W3C textContent) or
IE event model (attachEvent without control on bubbling/capture VS W3C
addEventListener). Let's not make the same mistake!

Each time the same use case is solved twice, people write JavaScript


More information about the es-discuss mailing list