

How serial #s on Nazi tanks gave the Allies a big strategic advantage - DanLivesHere
http://us1.campaign-archive.com/?u=2889002ad89d45ca21f50ba46&id=c6f4cf92c4

======
tptacek
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.

~~~
jasonkester
You can use it to your advantage too. Start your IDs off at a big number, and
your first few savvy customers that see their ID think you're a lot bigger
than you really are.

So instead of knowing they're user #8, they think they're user #14221, and are
a lot more likely to trust you with their money.

It works well for throwing off the competition too. "Holy Crap! They have 150k
users and they're only 3 months old! We're screwed!!!"

~~~
thibaut_barrere
When I started freelancing 5 years ago, my accountant advised me to start with
a large invoice number (eg: 20850) and increment for each new one :)

~~~
eru
Decrementing from there would be more fun.

~~~
thibaut_barrere
Fun indeed! Unfortunately illegal in France afaik.

------
RiderOfGiraffes
Title and timing are everything - two versions of this story submitted
previously, each to complete indifference:

<http://news.ycombinator.com/item?id=1814905>

<http://news.ycombinator.com/item?id=1810568>

Why has this story suddenly sprung to life in the media?

~~~
DanLivesHere
Because of me, accidentally.

I found out about the story via Twitter. Someone I follow (cited in the
original post here) mentioned it as an aside in a blog post of his.

I write a free daily email newsletter of interesting things I come across --
that's at <http://dlewis.net/nik>. The original post here is the issue from, I
believe, Tuesday, but it's been a long week :)

I submitted the link to reddit
([http://www.reddit.com/r/todayilearned/comments/dstpi/til_tha...](http://www.reddit.com/r/todayilearned/comments/dstpi/til_that_in_wwii_allied_forces_reverse_engineered/)
\-- please pardon my misuse of "reverse engineered") and it went over very
well, hitting either the front page or the second page. So a lot of people
noticed it. I'm not surprised there are other submissions. I've seen pickup
across a number of sites.

The title and timing?

Well, the title was straightforward -- I just took the one that worked so well
on reddit and whittled it down to 80 characters.

The timing was accidental. I was queuing up today's issue late last night my
time, and I was crediting the guy behind <http://hackernewsletter.com> for
tipping me off to the story. Then I had an "a ha" moment and figured, hey,
this would be welcome on HN, too. So I submitted it.

------
CountHackulus
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.

Had to look this up on Wikipedia for a more thorough explanation.

~~~
iuygthjkllkjnh
Knowing how many tanks the other guy has, and how quickly they can build more
new ones is generally of some interest if you are having a war with them

~~~
ramchip
My impression is that it is a strategic advantage of course, but not a "big
advantage". Knowing that the enemy is weaker then expected is good, but it's
not directly useful like decrypting Enigma communications or acquiring
research material. If it really affected the war, I would have liked to see
why.

~~~
csallen
Here are a few possibilities of the advantages afforded by _knowing_ an enemy
makes 255 tanks/month:

\- You may figure it's worth your time to go out of your way to bomb a few
extra tank factories, as the payoff will be 5.5x greater than it would if they
were making 1400 tanks/month.

\- You may save money on R&D. Instead of devoting tons of resources to anti-
tank weaponry, your more realistic estimate will lead you to spend money
countering more important threads.

\- You'll have more realistic estimates of the number and type of German
forces at each battle, and thus will be less likely to over (or under) commit
your own forces, and also less likely to bring ill-suited weaponry and tech.

\- You'll be less likely to avoid or back down from winnable battles you would
have previously considered to be un-winnable.

Etc. Fighting a war (or doing anything for that matter) without proper
intelligence turns it into a guessing game. It's always to your advantage to
know rather than guess :)

------
bl4k
auto increment considered harmful, from joshu:

<http://joshua.schachter.org/2007/01/autoincrement.html>

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).

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.

~~~
jasonlotito
The article linked here makes a bad case against auto incrementing. In fact,
I'm the opposite. Every field should have an ID that has nothing to do with
the data being stored. That, the record should not contain the (in the case of
MySQL) primary key.

Take the traditional users table.

username password email

You might suggest that username can be the key. And sure, it will be a unique
key. But, internally, I don't want to operate on the username. I'd rather
operate on an internal value that is not related to the rest of the record. So
I add an ID.

This ID doesn't have to be exposed to the user. However, should it ever pass
that I need to let users change their username, I can easily by editing a
single entries field.

Basically, your application logic shouldn't impact your business logic.
Referencing record 12345 should also reference the same record, regardless of
what else is changed.

~~~
thibaut_barrere
I believe the OP was suggesting using a non-business key that isn't an
incremented integer - typically some kind of guid.

This allows to shard the data across multiples machines more efficiently, too.

MongoDB (amongst others) use this by default.

~~~
jasonlotito
Maybe. If he was, it wasn't clear, especially with "Your tables almost always
have a better unique key." I took that as meaning using some element of the
record.

Regardless, you make a good point. =)

------
martey
This was linked in the article, but it has significantly more math and more
historical examples: <http://en.wikipedia.org/wiki/German_tank_problem>

------
jhferris3
"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. "

Obviously, we were counting from 0. Stupid off by one errors. :)

------
TGJ
I will now work snafu into all my conversations for the next week. Great
article.

