Live data from Hacker News

Things you should do now (2011)

secure.phabricator.com

1–10 of 115 posts

Re: Things you should do now (2011)

#4

That start ids at a gigantic number idea is great, even though I've never encountered a bug caused by not doing it.

I literally came here to comment that the very first bug I had to chase down in a production system in my first job was caused by this! There was a 'fuzzy' search field available to users and when one input a client's ID number (formatted as NNNNNNN) it was showing results for a different client because NNNNNNN was also the format of the unique ID for records in the database.

Re: Things you should do now (2011)

#5
"As of 2011 Facebook is in the second group, and spends several milliseconds of CPU time sanitizing every display string on its way to the browser, which multiplies out to hundreds of servers worth of CPUs sitting in a datacenter paying the price for the invalid UTF-8 in the databases."

I can imagine how companies will be taxed extra for this somewhere in the (probably not so near) future.

Re: Things you should do now (2011)

#6

That start ids at a gigantic number idea is great, even though I've never encountered a bug caused by not doing it.

A better tip would be to use something like time-ordered uuids: You can‘t misuse them for something different and the added bonus is that no one can iterate your db records by just incrementing the url.

Re: Things you should do now (2011)

#7
post #6

That start ids at a gigantic number idea is great, even though I've never encountered a bug caused by not doing it.

A better tip would be to use something like time-ordered uuids: You can‘t misuse them for something different and the added bonus is that no one can iterate your db records by just incrementing the url.

My main gripe with UUIDs at the moment is that they look ugly in urls :/

Re: Things you should do now (2011)

#8

"As of 2011 Facebook is in the second group, and spends several milliseconds of CPU time sanitizing every display string on its way to the browser, which multiplies out to hundreds of servers worth of CPUs sitting in a datacenter paying the price for the invalid UTF-8 in the databases." I can imagine how companies will be taxed extra for this somewhere in the (probably not so near) future.

Why not sanitize it once when accessed, write the sanitized result back to the database and set a flag on the record. Use only presanitized strings if the flag is set. After some time, when enough of your strings are flagged, run a sanitizer over the rest that hasn't been touched. That way you don't waste those milliseconds. However, I can imagine that this would waste quite some storage bandwidth because such a read is now a write as well.

Re: Things you should do now (2011)

#9
post #8

"As of 2011 Facebook is in the second group, and spends several milliseconds of CPU time sanitizing every display string on its way to the browser, which multiplies out to hundreds of servers worth of CPUs sitting in a datacenter paying the price for the invalid UTF-8 in the databases." I can imagine how companies will be taxed extra for this somewhere in the (probably not so near) future.

Why not sanitize it once when accessed, write the sanitized result back to the database and set a flag on the record. Use only presanitized strings if the flag is set. After some time, when enough of your strings are flagged, run a sanitizer over the rest that hasn't been touched. That way you don't waste those milliseconds. However, I can imagine that this would waste quite some storage bandwidth because such a read…

Doing that at the scale of facebook does not seem like a problem you can solve in a paragraph of explanations, which is the point of the blog:

The longer you wait, the more difficult it is to solve.

Post reply on HN