When the standard was being ratified, this came up on the mailing list (I can't find the link right now, I am on my cell).
The solution was that to recommend vendors print warning labels across the top or add a layer of permissions around the feature - which Chrome and Safari have done.
for eg. when I open it I get a message saying 'Chrome is currently in fullscreen mode'. They will likely both also add permission boxes similar to when the browser requests your location.
It is good for developers to understand this, though, but I wouldn't say that the spec is broken, or that this is a bad feature, it can be implemented securely and with warnings. Anti-phishing education for users should involve primarily talking about not trusting links anywhere and typing in the address directly.
> User agents should ensure, e.g. by means of an overlay, that the end user is aware something is displayed fullscreen. User agents should provide a means of exiting fullscreen that always works and advertise this to the user. This is to prevent a site from spoofing the end user by recreating the user agent or even operating system environment when fullscreen. See also the definition of requestFullscreen().
> To prevent embedded content from going fullscreen only embedded content specifically allowed via the allowfullscreen attribute of the HTML iframe element will be able to go fullscreen. This prevents untrusted content from going fullscreen.
I am most familiar with Safari and Chrome (have been meaning to get up-to-date with Firefox, which has had a lot of good work put into it) but all of the major browser vendors have done something around this in their own way with both desktop and mobile releases.
It is at the discretion of each vendor how they implement security warnings or settings around full screen mode. They all have slightly different implementations but the end result is that they go some way towards preventing a phishing attack using Fullscreen.
That said, it was a good idea to bring this issue to the attention of developers and users as a potential attack vector and as a demonstration of why the security dialogs are important.
Edit II: The whatwg thread where the security considerations are discussed begins here:
Firefox does it too, and in a much more obvious way than either Chrome or Safari. Here are all the latest browsers on Mac compared: http://imgur.com/a/jdcI7 (Sorry Opera; I haven't re-installed you yet.)
I actually didn't get any permissions dialog or warning label in Safari 6; maybe I ok'd it for another site at some point in the past, but I definitely didn't whitelist this domain.
Dear customer, in order to improve the security of your account we have implemented a new on-screen keyboard. Please use the mouse to enter your account number and PIN in order to access online banking.
The fact that this is a real technology being deployed right now doesn't hurt.
>The first post rightly points out that Flash had the feature implemented in a non-secure manner for a long time.
Flash disabled all "printing" keys in full-screen mode, and disabled a warning label when entered into the mode. FS could only be entered from user action. So Flash's full-screen mode was limited but fairly secure.
Why do we need a JavaScript based API for this anyway? Wouldn't it be MUCH better to allow websites detect when user presses F11 instead? It's not just about security, it's about managing expectations and familiar UI.
However, most users (even experienced users) don't look at the url when visiting information-sensitive websites and www.bankofamerica.fsh4.com would still not alarm them. They don't understand the SSL icon either.
There was an interesting research a few years ago regarding the SSL icon. Since in many users the idea is actually finely-ingrained that a padlock means security on a website they just made the favicon into a lock. A surprisingly large number of users was fooled by that.
I guess the "padlock means secure" has been superceded a little by "address bar is green somewhere" by now, but the problem remains the same.
That's not what's happening here though. The JS in the demo doesn't change the href attribute of the link, it just adds an event handler that prevents the real link from loading using e.preventDefault() and then triggers full screen.
Sorry, I wasn't very clear; I'm just saying that both this and Google Search spoofs the status bar by obscuring what a link will do until it's clicked.
This was really annoying for me because somehow the google redirect link took a lot longer to load than the ultimate destination would, or even regular google pages.
The demo you've put together is very nice. It even accounts for the different UI styling of individual browsers. However in all cases that the link worked, I received a very large warning that has to be manually dismissed.
This is not a rhetorical question; do you think people would ignore the warning and continue to use the site?
An easier phishing technique would be to manipulate the address to appear legitimate using pushState.
"do you think people would ignore the warning and continue to use the site?"
I actually made this demo back in April but just got around to posting about it now. In the meantime, Firefox and Chrome have made their warning messages more prominent. Still, I think it's a pretty major issue.
Experienced web users won't be fooled by something like this. But, even if 1% of users are fooled by this technique, that's still potentially thousands of innocent web users, which I think is unacceptable.
The words 'dumb' and 'smart' are inflammatory and useless in this context. A substantial portion of desktop Internet users will click anything that comes up in order to get to their destination.
This attack triggers no 'warning' that would cause the user unease. The most obnoxious case is Firefox presenting "Allow or Deny Fullscreen?" a question that doesn't imply any danger or downside. A number of victims might even see it as a new kind of convenience, since their phone and tablet already do everything in fullscreen.
To corroborate your point, one of the Chromium developers spoke about this sort of problem, but in the context of invalid SSL certificates and the associated warning that Chrome displays. A ridiculous percentage of users ignored the warning that the site they were visiting wasn't verified and simply clicked 'Visit this site anyway.' Most users don't understand that there are potentially serious costs to ignoring security warnings.
"Get me out of here!" is the only visible button and the obvious action. To override the SSL check, you have to click "I Understand the Risks" to expand the page, revealing both an "Add Exception..." button and a further warning (in bold). "Add Exception..." brings up a dialog which again warns you in bold: "Legitimate banks, stores, and other public sites will not ask you to do this." And finally "Confirm Security Exception".
Firefox steers you toward the safe choice and makes you very, very aware of the gravity of the situation before doing something dangerous. That's good UI.
Chrome on the other hand has a "Proceed anyway" button right there that within less than a second you've clicked on and now the warning is gone. Developers who would blame dumb users for this are mistaken. People are busy, they're distracted, and Chrome makes it way too easy to do the wrong thing while Firefox gets this right.
I also prefer Firefox's handling of SSL issues. Allowing permanent whitelisting of sites reduces the number of times a user will see the warning, reducing the muscle memory around clicking proceed anyway.
I agree that Firefox's certificate warning page is much better designed. I'm not blaming 'dumb' users for anything, I was providing supporting evidence of the fact that when browsers make warnings easy to bypass, users will simply click right through them.
Absolutely. If I took issue with anything in your post specifically it was "Most users don't understand that there are potentially serious costs". This to me seems to implicitly blame the users for not understanding, whereas I'd blame Chrome for a UI that makes it easy for a distracted user not to understand. As developers we have a responsibility not to lead users into doing something dangerous just because we don't have their full, undivided attention.
I was mostly disagreeing with the general "blame the users" mentality apparent upthread and among developers in general, not with you specifically. I've edited my post to make that clearer.
do you think people would ignore the warning and continue to use the site?
Absolutely. My eyes were opened to that when I was troubleshooting my father's webcam over the phone. It kept not working when everything looked like it should. He just failed to let me know about the alert that kept popping up that said "camera is locked by <foo>". Instead, without reading, he just hit the "X", even though I was asking for every step he was performing. Closing a rogue alert isn't even a "step" to most people.
If you are relying on dialogs to keep your users safe, you are doing it wrong. Unfortunately, I don't know what the right answer here is.
I worked in tech support for a few years, this stuff is very common when doing things over the phone. "A box popped up saying X" , "OK click on Y" , "Oh , I just clicked on Z", "why did you click on Z?" , "I always click on Z".
Indeed. Since message boxes and confirmations are used so frequently and often unnecessary users have trained themselves to just click on the far left or far right button to get rid of it. They don't read it, they don't want to understand what happened, it just interrrupted their flow and they want it to be gone. Pushing decisions to the user in form of confirmations won't ever really work probably due to a Pavlovian urge to close such things as fast as possible.
That's clever. It was pretty obvious to me, since I run Chrome in presentation mode (no UI elements visible) and Chrome popped up a dialog box telling me about the switch to full-screen mode. Still, I can see how a lot of people could be tricked by this. I can't think of a better solution than extant phishing site blacklists.
Full-screen mode can be useful, but it and other HTML5 features can be used for phishing or to generally annoy users. I'm wondering how soon it will be before someone makes the HTML5-equivalent of ClickToFlash.
NoScript already inherently blocks this, and even if you allow the domain that provides the script that tries to go full-screen, and allow the full-screen transition, the web page pretending to be a desktop doesn't cover the NoScript toolbar that's still prompting for permissions on the other domains. I suspect the anti-clickjacking measures would kick in if the phishing site tried to incorporate the real site as a base layer.
NoScript does not seem to have any features targeted directly at HTML5 fullscreen, though.
It's increasingly difficult to browse websites with NoScript and Request Policy add-ons. There are websites that download JS from more than a dozen different domains. Moreover, it seems that a lot of web developers (including some here) simply dismiss NoScript users "not our target audience". Emerging "HTML" standards don't make this situation any better, since they are pretty much aimed at developing websites in JavaScript, not HTML.
This is why I want to fork Chrome and create a secure and privacy-aware browser.
* Take out everything Google-related, including safebrowsing
* Rip out Flash and Java
* Integrate NoScript
* Integrate an alternate html5/canvas based video player
* Integrate third-party request blocking
* No cookies by default
* Strip out all the tracking id's in URLs (eg. Google search results pages, back to just plain old ?s=search+query)
* Automatically clear cookies such as the __ut* cookies from analytics
* Incognito by default
* Introduce a concept of 'installing' trusted sites that would be allowed to run scripts, etc. not too dissimilar to how desktop computing works
I have had this idea for over a year now, but haven't gone far in implementing it other than doing a test build of chromium with incognito by default and some default extensions.
It came about because my dad and other family members have each had spyware or rootkits installed on their machines. 99.99% of drive-by exploits can be stopped by simply not running IE and switching off Flash and Java.
It would be a browser where you don't have to explain everything, just marketed/renown as being a browser focused on privacy and security features for everyday users.
When I get a chance, I am contemplating putting a team together and forking this as an open source project. If such a project is of interest to anybody else, get in touch (via email in profile).
the idea is that you have a button next to the URL to install it, from where it just runs as normal (albeit still without third-party cookies, as with fb buttons)
it could also do something smart with the type of javascript being executed. for eg. the concern with javascript is dyn generating forms or iframes and auto-submitting. etc. something that you can't do with extensions but you can do with a separate browser.
Firefox extensions can certainly do that. For example NoScript has IFrame blocking built-in, it's just disabled by default. More importantly, its ClearClick feature prevents clickjacking even with IFrames enabled.
You're right that Chrome extensions can't do that, though.
I don't have a Windows machine or VM, but it looks like full-screen mode on Linux is the same as presentation mode on OS X: the UI is completely hidden unless you move the mouse to the top of the screen. In addition to presentation mode, Chrome for OS X has a separate full-screen mode that always shows the tabs and buttons.
In OS X, "Full screen" triggers the Lion native full screen mechanism. In this mode Chrome is full-screen but you still see the toolbar. "Presentation mode" is more like what "Full screen" did before Lion, or how full screen behaves on other OSes: no toolbar.
IMO this is why the constant pushing of the browser as a platform is more trouble than it's worth. Everything that your OS does now will be re-invented (badly, several times) in one or more of the different web-browsers, lost, found, queried in triplicate, standardised before finally being recycled as firelighter when the next "paradigm shift" takes over.
You're being a bit disingenuous by not mentioning the inbuilt protections that the HTML5 Fullscreen API offers.
"Also, any alphanumeric keyboard input while in full-screen mode causes a warning message to appear; this is done to help guard against phishing attacks. The following keys are the only ones that don't cause this warning message to appear (...)"
That documentation is out-of-date. There were no warnings on keyboard input in Firefox or Chrome. I went fullscreen on a Facebook photo and was able to leave a comment without any issues.
Safari, on the other hand, appears to prevent keyboard input, which I just recently found out.
Its really annoying and alarming to hear technical people rebut this with "Well I could tell the difference because I noticed my browser changed and my super customized desktop settings weren't reproduced, and plus it says "now in full screen mode", etc.". Its alarming because this type of response just goes to show that the people creating things for the web are so completely out of touch with real users. There's this weird idea among developers that users know how to use technology just like we do when in fact they don't even know which website handles their email half the time, think Google is the internet, use the browser search bar to type full URLs even though the actual address bar is 10 pixels to the left, and will blame you for giving them a virus because you changed their desktop wallpaper and not because of all those shady links to foreign lotteries they were clicking in their email which they were lucky to find in the first place.
Yeah, you can tell the difference. I could tell the difference. Yes it was very obvious even though the demo was very accurate in reproducing my browser's chrome. But the rest of the world is nothing like us. Feross says 10% will be tricked. I think that's a very conservative estimate. I wouldn't be surprised is the numbers went above 50%. If this sort of attack becomes common then I bet you anything that the majority of users will be tricked just because full screen is not very common. You'll say full screen is common but again, you're thinking of people just like you who are in the minority. Most people have never seen a website in full screen mode. Even with Facebook's full screen option it doesn't mean your parents are clicking that option or have even noticed it yet.
I'm actually building an app currently that greatly benefits from the full screen API and I really hope vendors don't start putting more restrictions on it. Instead I'm hoping there's a way to make full screen more common in legitimate ways, get users used to full screen mode so they are aware of it and know what the little "Now in full screen mode" dialog means. Sure, people will still get tricked but I'd bet it would be in far less numbers and that 10% figure Feross throws out there might become more realistic.
A similar issue was shown when Adobe Flash fullscreen was first introduced (I think it was just Macromedia at the time, but anyway).
When you went to fullscreen in flash, it printed a giant "you are now in fullscreen mode" in the middle of the screen, but somebody showed that simply by printing similar text all over your screen, it hid that warning very well.
I think the "Door Study" [1] was the best part! It's hilarious, and horrible that the guy didn't notice the swap. Maybe I've just lived in a big city long enough that I'm not surprised by the World Famous Bushman [2] or people's swindling.
I was thinking the door-guy-swap footage where the victim noticed the swap must be perfect material for "Just for Laughs" [1]. Inversely, the "failed" Just for Laughs-material where the victims don't react must be perfect research material.
Great job! But originally, I opened that link in a new tab while I was still reading the article. It obviously did not work :P I've this habit of opening most links in a new tab!
Same here. I have an addiction to opening everything remotely interesting in a new tab, and my initial reaction was "I don't think this worked?"
Otherwise, it's pretty frightening, because I can imagine that in spite of the browser warnings, there are many non-savvy users who probably wouldn't give it a second thought.
As a KDE user, the blatant Gnome UI was kind of glaring but otherwise well done. ;)
haha, this indeed is frightening, and intelligent designers will push this to do something really neat. Let's hope it's a POC and not a real attack. Let us not forget that there are far more dumb people than smart people on our planet! ;)
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.
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 latest version of Safari shows no warning on fullscreen, making users very vulnerable. The only indication is a short, half-second animation (it's much shorter than the usual OS X fullscreen animation). After that, there's no indication that you're in fullscreen mode.
Does it also disable using any kind of keyboard event? Because if so, that cuts out a ton of legitimate use cases for full screen. If not, it just makes the vulnerability slightly more of a pain to exploit.
There will always be ways of exploiting things like this.
Perhaps the solution could be to handle this at the network level. In other words create what is effectively a "personal information firewall" built into the browser.
Have the browser detect when certain information is about to be send over the network, it would need to be checked prior to being passed to SSL. Things that fit formats like CC numbers or authorisation codes for banks. There could then be a prompt appear on top of all active windows saying "A CC number is about to be sent to xxx" Allow/Deny.
I suppose this would be difficult because phishers could re-encode data using JS into some other format before it is sent. So you would need some of mapping keyboard inputs to networking events.
Wow Feross. Another sweet demo. I still feel like there is so much to learn about security, but what I am always amazed at is that the "social engineering" attacks seem to be the problems that we can never solve. Yes, there is a technical component (HTML5 full screen api), but at its core this is a phishing attack, a "fool the user" attack, and not an actual technical security flaw.
Basically, if I wasn't paying attention, I feel like this was good enough to fool me. What can be done to save the casual, but maybe unfortunately inept internet user?
I once sent a letter to Steve Jobs saying that the MacOS (and other operating systems) were susceptible to phishing by applications, which would simply present a dialog that looks very much like the System Security dialog, and thereby gain the user's root password.
The solution is to have an area where only the operating system can draw (and which cannot be screen-captured, the same way Apple currently does with DRM movies). In this area, the system would present to the user a phrase which the user selected when setting up their account. This would prevent phishing, as users would be trained to look for the phrase (and / or icon ... the reason you can't have an icon alone is because the phisher could get it right 1 out of N times).
Now, on the web there is a similar thing you can do! When someone places KEYBOARD FOCUS in your password box, and starts typing the correct password, you display the icon + phrase that you previously selected when setting up your account. If the phrase doesn't pop up or is different, you know you're being phished.
THIS is a great way to stop phishing on the web. Anyone impersonating you will not know what phrase to display. Only by starting to type the correct pass phrase will they get this information. On the other hand, they won't be able to place anything fake over the password input box and capture your input, because the phrase only appears when you type IN the password input box, which the attacker can't get to, thanks to the cross-domain security in browsers!
The only thing is, if you don't wait until the user starts entering the password, the attacker can theoretically scrape the page with your username and find out the per-user image.
You don't get the image based on the username, the image is stored as a cookie, so it's showing you that the Yahoo you logged in to this time is the one that new your cookie details before. Even if an attack-site can read your cookie they don't know which image to pair it with (though maybe it can be taken from a local cache somehow?). The image is a per-device (or per browser?) security indication.
Oh! Well that's a smart idea... that's kind of like showing you your private "profile picture" when you are logged in.
But if you have a session cookie, then you hardly need a password. Unless we are talking about a public computer where you need to enter your password.
I am talking about the times when you DON'T have a session cookie, and you are prompted to sign in with a password. That's the thing that could be spoofed.
On linux it tries to emulate Ubuntu with default settings, while I have Cinnamon and different theme and fonts, different user name. Didn't terrify me.
I am not sure why this is on Github? Typically, I applaud when anything is shared on Github. But why this? What positive value is it to anyone other then script kiddies?
(Certainly, most any adequate web developer with nefarious intensions would be able to reproduce this quite easily. But why make it point-and-click easy for them?)
Imagine you opened new fresh HTML5-based game. It requested fullscreen, you allowed. You finished game and clicked on "Exit fullscreen" button. Then, instead of canceling fullscreen mode, you got just perfect illusion of it. Site author created almost complete replacement of your browser or ever your OS UI. So when you created new tab and entered news.ycombinator.com address it was loaded via proxy.
May be it's already happened in this demo. Wake up, Neo, and press Esc to exit from Matrix, ...sorry, from Fullscreen Mode.
> It’s important that the fake OS and browser UI match the user’s system.
Actually, it isn't, at least for some users. More than one member of my family has fallen for the "your computer has a virus" scams, which use Windows chrome, on Ubuntu machines.
Ultimately I think this can only be solved with an out of band security state indicator. Otherwise you can never quite believe what you see onscreen. Plenty of smartphones already have LEDs. Most keyboards don't use the scroll-lock led.
It does not work when you open the link in a new tab. The font on the screenshot is not the same that I have when I go to their website, so that would alarm me. Otherwise it's pretty clever.
High DPI users may detect something isn't right, since the technique doesn't take into account DPI setting (the fake firefox bar presented to me was much smaller than what I'm used to)
Are you, by chance, using HTTPS Everywhere? I think they have an erroneous rule about my site which redirects you to https:// which I no longer provide.
The solution was that to recommend vendors print warning labels across the top or add a layer of permissions around the feature - which Chrome and Safari have done.
for eg. when I open it I get a message saying 'Chrome is currently in fullscreen mode'. They will likely both also add permission boxes similar to when the browser requests your location.
It is good for developers to understand this, though, but I wouldn't say that the spec is broken, or that this is a bad feature, it can be implemented securely and with warnings. Anti-phishing education for users should involve primarily talking about not trusting links anywhere and typing in the address directly.
Edit: Here it is from the Spec:
http://dvcs.w3.org/hg/fullscreen/raw-file/tip/Overview.html#...
> 7. Security and Privacy Considerations
> User agents should ensure, e.g. by means of an overlay, that the end user is aware something is displayed fullscreen. User agents should provide a means of exiting fullscreen that always works and advertise this to the user. This is to prevent a site from spoofing the end user by recreating the user agent or even operating system environment when fullscreen. See also the definition of requestFullscreen().
> To prevent embedded content from going fullscreen only embedded content specifically allowed via the allowfullscreen attribute of the HTML iframe element will be able to go fullscreen. This prevents untrusted content from going fullscreen.
I am most familiar with Safari and Chrome (have been meaning to get up-to-date with Firefox, which has had a lot of good work put into it) but all of the major browser vendors have done something around this in their own way with both desktop and mobile releases.
It is at the discretion of each vendor how they implement security warnings or settings around full screen mode. They all have slightly different implementations but the end result is that they go some way towards preventing a phishing attack using Fullscreen.
That said, it was a good idea to bring this issue to the attention of developers and users as a potential attack vector and as a demonstration of why the security dialogs are important.
Edit II: The whatwg thread where the security considerations are discussed begins here:
http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2009-Dec...
The first post rightly points out that Flash had the feature implemented in a non-secure manner for a long time.