[lmm]

I think it's difficult-to-impossible to do anything secure within a page, because a malicious page can emulate virtually any kind of behaviour within the page. https://textslashplain.com/2017/01/14/the-line-of-death/

(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).

[reginold]

> (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.

[lmm]

> That way the server doesn't know what the "verified" image actually looks like.

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.

[reginold]

How would it construct a page that has the verified image if it doesn't know what the image looks like?

[lmm]

It would construct a page that includes a part that's genuinely verified (so the browser displays the verified image) and a part that's malicious, but arrange it so that it looks like the verification goes with the malicious part.

[CodeIsTheEnd]

Wow, this is a really great article. Thank you for sharing!

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.)