Hacker News new | comments | show | ask | jobs | submit login

Firefox has a big warning that asks permission and dims the background, making it difficult to use until you select allow or deny, so it won't work as well with Firefox.

Chrome 23 just makes it full screen with a small notice.

This is true, I saw it too. But a popup telling the user to 'Allow Fullscreen?' is semantically equivalent to "Click Yes If You Want To Log On To Your Bank" for most users.

The least savvy are UI-blind, a big portion won't realize a transition just occurred, and a great majority of them will not read the warning beyond the first line.

If that is the case, how is it a significantly worse problem than a regular link to a fake site?

Good question. The key difference is that using the Fullscreen API let's you fake the "green location bar" which, thanks to hundreds of PSAs from the tech community over the years, has become synonymous with "this site is safe and secure".

The problem is that for many years the browser's chrome/UI was in fact a place not hijackable by web sites. In contrast to things that appear within the normal client area as the often-spoofed yellowish notification bar of old Internet Explorer versions (the newer one at the bottom now sees this as well). I think Firefox opted for a very deliberate design in security-critical cases that will always appear from within the chrome and never overlay the page in a way that could be spoofed by clever CSS.

Of course, now with pages requesting to go fullscreen there isn't a browser UI anymore that could show things that cannot normally appear in the page content. Hitting F11 previously at least was something no web page could ever do by itself. On the other hand, having to wade through warnings like Firefox' SSL warnings probably scares away users from fullscreen games and developers from using the feature.

I wouldn't really have an answer to anything of that. I don't even know whether I embedded a question, I think it was just rambling :-)

Fake and malicious URLS can be filtered against and intercepted. This trick dodges those systems... but it still requires a malicious 'source' page to serve it up. Hrm.

I imagine all of the payload (save for the return trip) could be put into innocent looking client-side Javascript, but that doesn't get around the fact that someone's still got to serve the JS...

Yeah, that's all I've got. The only scenario protecting the unsophisticated here is that the malicious javascript (presumably) has to be delivered from some domain, and domain filtering is in full effect almost everywhere.

This API means that if a malicious JS can be executed, it's game over for a number of defenses that only communicate visually.

The domain where this is hosted would get added to the blacklist pretty quickly too.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact