This is a really common web app flaw as well; there's almost always something your app does that reveals how many customers you have (or how much business you're doing) to any stranger with an account.
Title and timing are everything - two versions of this story submitted previously, each to complete indifference:<p><a href="http://news.ycombinator.com/item?id=1814905" rel="nofollow">http://news.ycombinator.com/item?id=1814905</a><p><a href="http://news.ycombinator.com/item?id=1810568" rel="nofollow">http://news.ycombinator.com/item?id=1810568</a><p>Why has this story suddenly sprung to life in the media?
Just a nitpick, but the article didn't explain how this piece of intel gave them a big strategic advantage, it just explained that they got this piece of intel.<p>Had to look this up on Wikipedia for a more thorough explanation.
"the Germans produced 255 tanks per month -- a fraction of the 1,400 estimate produced by conventional intelligence. (Want to see the math? Click here.) And it turns out, this method worked best: after the War, internal German data put the number at 256 tanks per month. "<p>Obviously, we were counting from 0. Stupid off by one errors. :)
auto increment considered harmful, from joshu:<p><a href="http://joshua.schachter.org/2007/01/autoincrement.html" rel="nofollow">http://joshua.schachter.org/2007/01/autoincrement.html</a><p>Your tables almost always have a better unique key to use as a primary key other than auto increment (which sorts your table by the order they were inserted in - almost always useless outside of a blog).<p>Getting out of the habit of beginning the design of your tables with ID int autoincrement is a good thing. Even better if web frameworks stopped depending on it and setting it as the default primary key and ID used in views/routes.
This was linked in the article, but it has significantly more math and more historical examples: <a href="http://en.wikipedia.org/wiki/German_tank_problem" rel="nofollow">http://en.wikipedia.org/wiki/German_tank_problem</a>