|
Whether or not this was built as a joke, there could be real benefit from a service like this. Imagine you need a UUID in JavaScript. Here's a function that does it: function UUID() {
return "4444-8888-FFFFFFFFFFFF";
}
What's that you say? You want a randomly generated UUID? Okay, here's a clever one taken from http://stackoverflow.com/questions/105034/how-to-create-a-gu... 'xxxxxxxx-xxxx-4xxx-yxxx-xxxxxxxxxxxx'.replace(/[xy]/g, function(c) {
var r = Math.random()*16|0, v = c == 'x' ? r : (r&0x3|0x8);
return v.toString(16);
});
That should be pretty good, right? Well, it's pretty good depending on your needs. If you need a UUID that is (practically) guaranteed to be unique within a single HTML document, and that UUID never leaves the scope of that page, then this function is a great solution. But if your client-side-generated UUID is sent to the server where it meets up with many other UUIDs generated from the same JavaScript code that ran in other browsers, then this function won't cut it. Why not? Because generating a random UUID in JavaScript relies on the use of Math.random(), which in most browsers uses the current datetime as a seed, and that's only a fine seed if you're building Tetris.Given enough time, two browsers will eventually generate a UUID at the same moment, meaning they both use the same seed and therefore generate the same UUID. So, why not seed a pseudo-random number generator in JavaScript yourself with something better than the current time? Because client-side JavaScript doesn't have access to good sources of entropy. Within the browser, your sources of entropy are limited to things like the current time, the window dimensions, the user agent string, the number of plugins installed, etc. You could capture mouse movements and keyboard clicks over time, but it would take a while to generate sufficient entropy for a cryptographically secure random number. Also, if you need to generate a UUID on page load you can't wait for the user to jiggle their mouse. Meanwhile, the server has access to better sources of entropy. For example, many /dev/random implementations use the time between hard drive seeks as a source of entropy. Of course this entropy pool would be exhausted quickly, but you could replenish the pool with outside sources of entropy such as white noise from a radio ( https://www.random.org/history/ ) or even radioactive decay ( http://www.fourmilab.ch/hotbits/ ). I don't know what sources of entropy http://uuid.me is using to generate random UUIDs, but it might be better than what JavaScript is capable of on its own. If uuid.me served its UUIDs in JSON, then you could make a JSONP call in JavaScript, providing you with a UUID that is much less likely to ever collide with another client's UUID. |
One can use http://uuid.me/v1.json or http://uuid.me/v4.json
At least v4 will use Java's SecureRandom, and my server is running a recent Oracle JVM7, so I would argue that the randomness should be decent enough. Maybe not perfect, but good enough to make collisions extremely unlikely.
That being said, this service really was written as joke. Particularly the JSON and XML outputs.
As to /dev/random, no, it's not simply derived from time between hard drive seeks (at least for the operating systems I care about).