On Oct 13, 2012, at 4:58 AM, Florian Bösch <pya...@gmail.com> wrote:
> On Sat, Oct 13, 2012 at 1:49 PM, Maciej Stachowiak <m...@apple.com> wrote: > I think the most effective defense against phishing via fullscreen is to > prevent keyboard access. The original design for requestFullscreen had an > optional argument for requesting keyboard access, which led to a warning in > some browsers and which for Safari we chose to ignore as the risk outweighed > the benefit. The new spec does not have this parameter and makes no mention > of keyboard access. It is not even clear if refusing to send key events or > grant keyboard focus in fullscreen would be conforming. I think this should > be fixed. I think the spec should at minimum explicitly allow browsers to > block delivery of key events (or at least key events for alphanumeric keys). > Regrettably, this defense would not be very effective on pure touchscreen > devices, since there is no physical keyboard and the soft keyboard can likely > be convincingly faked with HTML. > I've got no objection against a user poll for things like keyboard > interactions in fullscreen as long as the implemention honors the intent to > show this once for a session or remembered state and not all the time when > going back and forth. Our current intended behavior in Safari is to never allow alphanumeric keyboard access in fullscreen. No cancel/allow prompt. Did you read the part where I explained why such prompts are useless for security? > > The second most effective defense that I can think of is a distinctive > visible indicator that prevents convincingly faking the system UI. The common > notification to press escape to exit partly serves that purpose. A > potentially more effective version would be to show a noticeable visible > indicator every time the user moves the mouse, presses a key, or registers a > tap on a touchscreen. Ideally this would cover key areas needed to fake a > real browser UI such as where the toolbar and address bar would go, and would > indicate what site is showing the fullscreen UI. However, while such an > effect is reasonable for fullscreen video (where the user will mostly watch > without interacting), it might be distracting for fullscreen games, or the > fullscreen mode of a presentation program, or a fullscreen editor > Such a scheme would render fullscreen virtually useless for most of its > intended purpose. That depends on what you think "most of its intended purpose" is. Many native video fullscreen implementations already have behavior somewhat like this, because they expect that the user is not producing UI events most of the time while watching the video. It may be annoying in the context of a game or slideshow. So far I have encountered such uses much less often than video. Regards, Maciej
