3 ms·
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 swi
by quantumofalpha 5y ago
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.
- ktm8 5y agoJust for curiosity, how would YT deal with ID collision ? Edit: Before the scheme change I mean
- root_axis 5y agoTry again? Just a guess.
- remram 5y agoProbably they just roll again. You can even implement that in a stored procedure.
- quantumofalpha 5y agoNot sure about technical details for that but perhaps something like https://vitess.io/docs/reference/features/vitess-sequences/ 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.
- Thorrez 5y ago>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.