Yes, exactly. Video ID is just a base64'ed DES-encrypted primary int64 video key from MySQL. It used to be sequentially incremented until at some point they switched to randomly generated primary keys. Any (ex-) engineer who snapped a copy of the encryption key (it used to sit right in the code for anyone to see) can enumerate all videos from YT until that moment, including unlisted - which are only protected by secrecy of that one key. If the key leaks, then also anyone in the world can. That's what they are afraid of here. Source: worked for YT.

Just for curiosity, how would YT deal with ID collision ?

Edit: Before the scheme change I mean

>base64'ed DES-encrypted primary int64

Block ciphers (such as DES) don't collide. If they did there would be no way to decrypt them because a block could be decrypted into multiple valid plaintexts.

Not sure about technical details for that but perhaps something like https://vitess.io/docs/reference/features/vitess-sequences/. Vitess itself is a project that grew out of YouTube's needs to scale and shard their MySQL DB.

Probably they just roll again. You can even implement that in a stored procedure.

Try again? Just a guess.

Maybe their old scheme, when divided by the number of videos, was getting to the point where it was feasible you could brute force finding unlisted videos.

The old scheme had 7.3 x 10^19 ids (11 chars, base 64, thanks Tom Scott!). Suspiciously close to the max value of a 64-bit int, hmmm …

Assume a billion videos and you’re down to 10^10 - a one in a 10 billion chance isn’t much chance, but it’s far from secure.

(I’m ignoring the fact that only a small %age of videos are unlisted I guess, but I think the point still stands.)