(For example, if you had some sort of "signed iframe", the page would probably find a way to show the part from twitter that says "verified" but cover up the part that it's supposed to be actually verifying with something else).
(For example, if you had some sort of "signed iframe", the page would probably find a way to show the part from twitter that says "verified" but cover up the part that it's supposed to be actually verifying with something else).
This is the part where I imagined having a custom client side image. That way the server doesn't know what the "verified" image actually looks like. Could be a picture of my face, for example.
Right, but it doesn't need to - it just has to construct a page that has the "verified" image on the left and the malicious URL on the right. Which is very difficult to rule out.
It discusses a fascinating point about browser UI: when the browser displays something inside its chrome, where a malicious page could render arbitrary pixels, it must establish a visual bridge back to the "trusted zone" (the chrome), providing proof that is in fact trusted content.
(The author points out that new APIs allowing writing to the entire screen means it's hopeless and we're all doomed though.)