If it's a job to work on a haptic feedback system, they may very well want to plumb your understanding of when interrupts fire, without prompting for canned answers.
If you're interviewing for a front end position, you can make a nod to interrupts and continue on with BGP, ARP, DNS, TCP, IP, routers, etc. If you want to show your knowledge of security you could mention heartbleed, poodle, or even say why this isn't vulnerable to shellshock. An overview will take a minute, and the interviewer will follow up with more targeted questions if needed. It's a chance for the candidate to shine.
I think it's worth being aware that the more open-ended you make the question, the more you might freeze a less-practiced-at-interviewing candidate on not knowing where to start.
I'm always ready when asking something very open ended to follow up after 15 seconds or so to say "let's talk about [area X] first." For URLs, maybe this is "let's talk about what the actual network request, if you sniffed the traffic, looks like."
You deal with BGP and ARP as often in frontend as you do with hardware interrupts.
Heartbleed and co. may or may not be your concern depending how much that frontend is into devops.
Heartbleed should be understood by frontend devs. In 2017 there is a minimum set of knowledge that frontend devs really need to have. That includes pki, client and server certificates, routing, network caching, and a whole host of other topics. Layers of the stack interoperate, and lack of knowledge of the stack leads to security vulnerabilities.
If you're interviewing for a front end position, you can make a nod to interrupts and continue on with BGP, ARP, DNS, TCP, IP, routers, etc. If you want to show your knowledge of security you could mention heartbleed, poodle, or even say why this isn't vulnerable to shellshock. An overview will take a minute, and the interviewer will follow up with more targeted questions if needed. It's a chance for the candidate to shine.