After a first look, it seems like this hack involves setting a custom cursor, which is defined as a canvas image that is 128 px tall. This 128px high image is mostly transparent, and has a fake "cursor" image at the top of it. The bottom of this image tracks your real cursor, and the fake cursor at the top of the image makes it seem like your real cursor is hovering over the browser chrome, when in fact it is ~128px lower than it appears. The rest of the effect is achieved via animating the canvas used for the custom cursor.
In terms of mitigation, it seems like at a minimum custom cursors should never be rendered outside the bounds of the page content.
Hello! Author here (along with my inspiration benjaminbenben). This explanation is perfect. And yes, I think the TODO is to not render the custom cursor outside the viewport.
At least on Windows, i'm reasonably sure all the API does is tell the OS which image to render as cursor and the cursor is rendered entirely by the OS; meaning there's no control over whether the cursor is being rendered partially outside the viewport or not.
Solutions where the browser would have enough control would likely require rendering the cursor by itself, which would impart it noticable input latency.
That would be very expensive computationally, and as seen in the padlock, accompanied by latency and jitter.
It would also break the case where pages have legit uses for crosshair style cursors, or cursors that are rotated 180° in order to not overlay contents.
On Chrome Windows 7 version I've got the window un-maximised and the pretend cursor escapes well onto the desktop and outside the bounds of the visible Chrome window itself.
So I thought this was just doing something on click (showing the fake HTTPS info), but that it maybe didn't work on newer or non-Chrome browsers, e.g. Chrome 52, Safari 9.1, and whatever bug was fixed there. But then I noticed that it causes really weird interactions at the top of the browser, at least on Mac; if you open the page in either Chrome or Safari and move your mouse towards the address bar, it jumps around on Safari and does a "double take" on Chrome. Really interesting!
The original linked hack is clever. But this page is just confusing (in Safari on OS X), for several reasons, not the least of which is the fact that the page is in fact served over https, and if I mouse over the padlock and click it, everything behaves correctly (and even if the page was specially designed for Safari and could figure out where the url bar was, it can't even replicate the behavior Safari has for clicking the padlock because web pages can't show sheet dialogs).
Part of the problem here is the fact that the fake cursor never actually escapes the page on this one. When my mouse is near the top of the page it reverts back to the system cursor instead of the fake one, before it even leaves the frame of the page. The original linked hack worked much better.
On both Firefox and Chromium on Linux the true place of the real cursor stay visible (Firefox displays a thin cross, and chromium a light blue star).
The menu position of course doesn't make sense in Firefox :)
Interesting... Can this 'hack' be used to convince people that, say, they're in a different/secure website when they're in a malicious website? I ask because since the 'fake' cursor is visible even on the address bar, the page must be able to overwrite the pixels there?
As this demo is now (and probably even with a lot of work) no due to the vast number of browser chrome (UI, not google chrome) configs. It's also very jittery in the demo. That said there is plenty of room for abuse in clicking things like like/tweet/etc buttons it would appear.
It isn't though. This merely changes the display of the cursor. Go to windowed mode (not fullscreen) and pull the cursor down into the address bar and tabs area to see that this does not prevent access to the address bar. It only changes how you perceive the position of the cursor.
https://github.com/benfoxall/cursory-hack