On Feb 14, 2011, at 8:40 AM, Boris Zbarsky wrote: > On 2/14/11 11:31 AM, Mark S. Miller wrote: >> On Mon, Feb 14, 2011 at 2:47 AM, Adam Barth <w...@adambarth.com >> <mailto:w...@adambarth.com>> wrote: >> >> That's a pretty long time horizon. You're going to start discussing >> it in 2-4 months? That seems a bit overwrought for what amounts to >> four lines of code. > > For what it's worth, it's a lot more than 4 lines of code in Gecko, because > we don't have an existing source of strong randomness in Spidermonkey. It'd > be about that much code in the DOM, where we could pass the buck to NSS, but > for Spidermonkey it would take a good bit more work.
Not really. We use callback-style APIs to delegate such chores as l10n to the embedding, and the same can be done for randomness-hunting. It's just interfacing, or buck-passing -- but I'm still wondering what magical four lines of code provide useful lower bounds on bits of entropy in WebKit. Is this just non-interoperable delegation to the host OS? Adam, I like moving fast (but beware, that's how JS and the DOM were created), but we need a cross-browser spec of some kind, even if we all add crypto.getRandomValues quickly. The original y2k-buggy, cloned-from-java.util.Date JS Date object of 1995 required a lot of work for ES1 to remove OS dependencies that made for interop hell. For a core language standard, we would want some kind of minimum quality guarantee on the randomness. Quick thought on the name: to avoid vagueness and the "why not wider int or even float element type" questions that have already come up, call the method getRandomBytes. /be _______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
