Love the story. That's quite interesting. Also, I wonder if this thing with hiding stuff in product to pre-selects possible candidate is something that HR does to improve recruitment or something that came from the devs.
Is it? I guess anyone that read the RFC or saw one implementation can easily reproduce it from the top of their head. Of course some details can be fuzzy and it's not that easy under stress but base64 is definitely not rocket science.
Pretty simple, easy to understand question. I wouldnt consider this hardcore - but over the phone it doesnt make much sense to ask such questions. Hope there was at least a Zoom or Skype meeting or something.
Hi Andrei, first of all, great story! Sorry about your Google interview (if I ran a tech company and interviewed you I'd have hired you in a heartbeat!). You apparently had to deal with a prima donna, egocentric, rank-and-file programmer/interviewer, whose opinions about your value as a potential hire can be summed up as "does the candidate know exactly the same things as me in the very narrow technical sub-niche area in which I work?". You do not want to work for such a person. You want to work with (not for) people with much broader minds (Paul Graham, Joel Spolsky, ?) than that.
Now, that aside, let's talk about what Google is probably doing.
The way to understand it is to understand a very significant problem.
Let's say that I am Netflix, for example. And my goal is to prevent people from pirating all of my great (and costly) video content.
If the content is unencrypted, then it's easy for people to pirate those streams.
But now, what if we encrypt the content using one globally-used encryption method?
Well, if we encrypt it that way, the decryption code must be part of whatever client program is being used... a smart pirate could potentially reverse engineer the client program, and extract (and use) the decryption code. Once that's done then "the cat's out of the bag" proverbially speaking, that is, the same code can be re-used, and all of Netflix's streams can now be pirated by whoever wants to pirate them.
We could encrypt each stream using a standard encryption algorithm, but with a different key each time. This is somewhat better, but that assumes that the key can't be recovered somehow, which is a terrible assumption.
So what's the best solution?
Why not use an obscure, unique encryption algorithm for each stream, and have the client download different decryption code each time, for each stream?
This way, if the code used to decrypt one stream gets leaked to everybody, everybody can't use it to decrypt their custom-encrypted streams!!!
How do you implement this?
On the client side, you implement a virtual machine which is going to do the decryption. Then you send the unique virtual machine code which implements the unique decryption algorithm for the one and only one stream you're going to send!
You do this each and every time, with a different, unique decryption algorithm for each stream.
This, or something like this, is what this code appears to be doing. (It might not be for a video stream, it might be for any data that Google might want to keep encrypted, for any reason... heck if someone really wanted to go crazy they could encrypt nested VM code inside of encrypted nested VM code -- and this could go on to N levels deep! <g>)
(You discovered this by disassembling the code; I figured this out years ago (because I might need this for a future business) by looking at the problem->solution->problem->etc. chain...)
Either way, you don't want to work for that guy at Google.
Take my word for it, you're Google-smart, even if Google doesn't think so.
Yeah, the main difference is that usually these vms can be deliberately written to be nonportable to things like emulators and headless browsers, making it a lot harder to just execute the same code at scale.
Side note to Andrei: If you care about keeping your email address hidden in the screenshot, don't just blur it. Blurring text is not sufficient for privacy. See for example https://news.ycombinator.com/item?id=8078747
11 comments
[ 3.0 ms ] story [ 24.8 ms ] threadNow, that aside, let's talk about what Google is probably doing.
The way to understand it is to understand a very significant problem.
Let's say that I am Netflix, for example. And my goal is to prevent people from pirating all of my great (and costly) video content.
If the content is unencrypted, then it's easy for people to pirate those streams.
But now, what if we encrypt the content using one globally-used encryption method?
Well, if we encrypt it that way, the decryption code must be part of whatever client program is being used... a smart pirate could potentially reverse engineer the client program, and extract (and use) the decryption code. Once that's done then "the cat's out of the bag" proverbially speaking, that is, the same code can be re-used, and all of Netflix's streams can now be pirated by whoever wants to pirate them.
We could encrypt each stream using a standard encryption algorithm, but with a different key each time. This is somewhat better, but that assumes that the key can't be recovered somehow, which is a terrible assumption.
So what's the best solution?
Why not use an obscure, unique encryption algorithm for each stream, and have the client download different decryption code each time, for each stream?
This way, if the code used to decrypt one stream gets leaked to everybody, everybody can't use it to decrypt their custom-encrypted streams!!!
How do you implement this?
On the client side, you implement a virtual machine which is going to do the decryption. Then you send the unique virtual machine code which implements the unique decryption algorithm for the one and only one stream you're going to send!
You do this each and every time, with a different, unique decryption algorithm for each stream.
This, or something like this, is what this code appears to be doing. (It might not be for a video stream, it might be for any data that Google might want to keep encrypted, for any reason... heck if someone really wanted to go crazy they could encrypt nested VM code inside of encrypted nested VM code -- and this could go on to N levels deep! <g>)
(You discovered this by disassembling the code; I figured this out years ago (because I might need this for a future business) by looking at the problem->solution->problem->etc. chain...)
Either way, you don't want to work for that guy at Google.
Take my word for it, you're Google-smart, even if Google doesn't think so.