- From: Tom Mitchell <mitch@niftyegg.com>
- Date: Wed, 16 Feb 2011 17:15:43 -0800
On Wed, Feb 16, 2011 at 4:29 PM, Allen Wirfs-Brock <allen at wirfs-brock.com> wrote: > So, let's get back to the design of an actual ECMAScript API. > > I'll repeat a couple of initial points: > We are now talking about a pure JavaScript API,.... .... Good stuff. Recall that part of what started this is that folks asked for improvements to math.random but math.random had become a key function in many benchmarks. Improving math.random would have the side effect of slowing down benchmark results so some felt touching is was problematic. Then there were some discussions regarding security hacks where guessing or inserting well guessed or spoofed results could compromise business or privacy. One post had a good yet short list of links that made it clear that Math.random as it is, is fragile. Rather than define a full and new API, an alternate tactic might be to code up some "quality" benchmarks metrics where Math.random would be improved because the benchmarks that identified the quality of the random numbers and gave better random tools more weighted value than just wall clock speed. The other issue that surfaced was a lack of rand-seed management policy. If corrected that would effectively make it nearly impossible for one script to guess anything that might go on in another connection. It is important for the old Math.random and any new API that rand-seed management policy be well addressed. I only intend to make the point that a new API will not repair Math.random as used now by numerous sites. Adding a new API will give sites new ways to get it wrong. -- ? ? ? ? ? ? ? ? ? ? ? T o m?? M i t c h e l l ? ? ? ? ? ? ? ? ? ? mitch-at-niftyegg-dot-com "My lifetime goal is to be the kind of person my dogs think I am."
Received on Wednesday, 16 February 2011 17:15:43 UTC