5 ms·
That's exactly what youtube originally did - video id is just an encrypted (3DES, iirc) 64-bit sequential primary key straight from mysql database. You can conv
by tmpyt 6y ago
That's exactly what youtube originally did - video id is just an encrypted (3DES, iirc) 64-bit sequential primary key straight from mysql database. You can convert it back and forth. Problem: if you know the encryption key (it was sitting right there in the code for all devs to see, easy to steal) you could enumerate all the YT videos, including all unlisted videos. At least until a few years ago - they've since switched to random database keys instead of autoincrement to fix this exact hole.
Source: worked there.
- shawnz 6y agoMaybe you could split the ID into two parts: the first is an encrypted integer representing the DB row, the second is a "password" for the video. Then you get fast indexing but you still can't enumerate videos without the ID.
- firloop 6y agoIn this scheme, how do you look up a row in the DB by the resulting encrypted ID?
- shawnz 6y agoYou store the key in the source code as in the other poster's description of Youtube 1.0. So employees/contractors/etc could still see the number of total videos and sequential order of uploads, but at least they can't enumerate them. You could also maybe rotate the key once in a while, but only for videos created after the rotation, and indicate the "key version" with a third field in the video ID
- saurik 6y agoI would recommend a computed index (given that scheme, if you liked it; I don't, but it doesn't matter).
- zellyn 6y agoOne of my hobbies when working at YouTube was to periodically search the monorepo to find new copies of the key, and try to refactor code so there was just one implementation in each of C++, Java, Python, Go
- tehlike 6y agoYoutube and their python code :) keystore would have helped solve this.