Not that slashdot has really been anything spectacular since 1998 or so, but they really are sinking quite low these days. They finally wrote up an article on the EU "browser selection" drama that has been going on for the past week -- see http://developers.slashdot.org/story/10/02/28/1837223/Schooling-Microsoft-On-Random-Browser-Selection A comment by "Lord Lode" suggests a very simple and practical solution that does away with reliance on pseudorandom number generators. I think the solution is quite clever, mostly because I presented it 4 days ago on http://motls.blogspot.com/2010/02/microsoft-browser-lottery-do-js-random.html. My solution is in the "comments" section linked to at the bottom of the article. I left another comment today about seconds vs milliseconds, but that has yet to be approved due to some dirty language directed at slashdot. :) So anyway, I left a comment on slashdot correcting the small error in Lord Lode's comment (e.g., 5! == 120 is not the same as 5 == 5), and included a link to my solution. It took less than 10 minutes for my comment to be deleted. You rock slashdot. Go screw yourselves.

It's not a good advice.

Timing is incredibly complex on PCs and absurdly inaccurate. time_in_ms() is almost certainly biased for various reasons, such as timer resolution, which might be more than 1 ms, depending on hardware.

This would result in something similar to: "Microsoft forces users of GHX-2000 chipset series into IE".

This problem occurs when seeding the random number as well.


Random numbers really are too important to be left to chance.

However, /. is reflection of a certain subculture, so the opinions there are heavily biased.

What is lame is EU, messing with MS 10 years after it ceased being relevant sorting out the issue which doesn't matter. EU has probably one of highest FF adoption rates, except in government-supervised IT - where they are forbidden from making a change due to security policies, which means that all the vendors catering to them (enough to support economies of many small countries) also don't have a choice.

gg - tax euros at work.

EU - where it was punishable by law for cucumbers to be curved, for bananas to be straight and for apples to not be red enough.

Oh well....

Yes, which is exactly why I suggest using seconds vs milliseconds, in the event that the millisecond timer is actually a 10 millisecond timer (or whatnot, like on my Win32 machine's millisecond timer).

This is what pisses me off the most. The person clearly doesn't understand the solution that they presented, which makes me wonder if they didn't just simply steal the idea in the first place.

Of course, the moderators at slashdot don't agree with either you or I, since they deleted my comment. slashdot should be a reflection of the development community, where the issue of timing precision is well known. It's obvious now that they're not quite familiar with this well known issue.

Nice fruit joke. :)

Quote:Original post by taby
Yes, which is exactly why I suggest using seconds vs milliseconds, in the event that the millisecond timer is actually a 10 millisecond timer (or whatnot, like on my Win32 machine's millisecond timer).

Which brings up the problem of when people do start up for the first time. In an IT setting, you might see hundreds of machines being powered up at the same time (T+45s till the selection app is started, give or take a few seconds), perhaps due to a patch or energy saving measure, which would mean they would be heavily biased towards one value.

It really is an annoying issue after real world is taken into account.

And still, this applies to seeding the RNG as well, so it is not a fool proof solution. If anything, multiple samples should be taken, and that mangled into the seed for the RNG, or perhaps used directly. Or, add the hardware-specific modifier, such as free disk space, free RAM, MAC, mangle all that together.

Cryptographic applications require user to wiggle the mouse or similar.

Quote:Original post by Antheus

Quote:Original post by taby
Yes, which is exactly why I suggest using seconds vs milliseconds, in the event that the millisecond timer is actually a 10 millisecond timer (or whatnot, like on my Win32 machine's millisecond timer).

Which brings up the problem of when people do start up for the first time. In an IT setting, you might see hundreds of machines being powered up at the same time (T+45s till the selection app is started, give or take a few seconds), perhaps due to a patch or energy saving measure, which would mean they would be heavily biased towards one value.

It really is an annoying issue after real world is taken into account.

I'm not so sure if the power up timing is really a super big issue. Considering that these computers are spread far and wide across the EU, I cannot see how the millions/billions of clocks could be correlated in any significant way. That is, the randomness of the power on times is effectively equivalent to the randomness of the visit times to the selection screen during the 5! == 120 second period.

Quote:Original post by taby
Nice fruit joke. :)

It's not a joke. There was a EU-wide law that required that, it was changed a few months ago.

Quote:far and wide across the EU

Same organization, all machines brought down for patch at 3am on saturday, all rebooted at same time, they take 45 +/- 10 seconds to boot. And there's the bias.

Quote:Original post by Antheus

Quote:Original post by taby
Nice fruit joke. :)

It's not a joke. There was a EU-wide law that required that, it was changed a few months ago.

Quote:far and wide across the EU

Same organization, all machines brought down for patch at 3am on saturday, all rebooted at same time, they take 45 +/- 10 seconds to boot. And there's the bias.

Oh man, I didn't realize that this was actually a law. :)

You make a great point about the reboot times, except until you point out that we're dealing with +/- seconds, not milliseconds. I think that this would pretty much wipe out all millisecond-level correlation, no?

Quote:Original post by taby

You make a great point about the reboot times, except until you point out that we're dealing with +/- seconds, not milliseconds. I think that this would pretty much wipe out all millisecond-level correlation, no?

It would reintroduce the timer accuracy bias, since % 5 would depend only on value in ms, which could perhaps be a multiple of 4, or multiple of 10 (!).

Which brings up back to the start.

Use this "unbiased" number to seed the proposed algorithm.

Quote:Original post by Antheus

Quote:Original post by taby

You make a great point about the reboot times, except until you point out that we're dealing with +/- seconds, not milliseconds. I think that this would pretty much wipe out all millisecond-level correlation, no?

It would reintroduce the timer accuracy bias, since % 5 would depend only on value in ms, which could perhaps be a multiple of 4, or multiple of 10 (!).

I don't think we're talking about the same thing. :) If there is a 4 or 9 or 10 millisecond timing interval, it shouldn't really pose a problem at all at the scale of seconds, and most definitely not at the scale of minutes or hours. Perhaps I'm mistaken in assuming that over a period of a day, the minute hand on the clock changes at roughly the same interval in the long run (some seconds may be short, some may be long, but it averages out). Either way, thanks for the conversation. I'm going to shut up now. I'm just pissed off at slashdot and I can't really reason sensibly at the moment. :)

[Edited by - taby on February 28, 2010 7:16:50 PM]

... the comment is now back on slashdot. :)