On May 13, 2011, at 12:46 AM, Henri Sivonen wrote: > On Thu, 2011-05-12 at 20:29 -0400, Aryeh Gregor wrote: >> In >> particular, Flash has allowed this for years, with 95%+ penetration >> rates, so we should already have a good idea of how this feature can >> be exploited in practice. > > I don't know of exploits in the wild, but I've read about > proof-of-concept exploits that overwhelmed the user's attention visually > so that the user didn't notice the "Press ESC to exit full screen" > message. This allowed subsequent UI spoofing. (I was unable to find the > citation for this.) > > Unfortunately, trying to mitigate this problem without explicit > per-origin permission management means that the browser would need to > take over the whole screen to show a warning for a few moments in such a > way that during that time the site has no way to show its own > distractions. That would be very annoying on legitimate sites. (With my > user hat on, I'm already annoyed by the "Press ESC to exit full screen" > in the Flash mode of YouTube.) Also, it would be less aesthetically > pleasing than having a part of the page animate to zoom to full screen. > > Limiting keyboard entry to arrow keys, space and such nontextual input > mitigates the impact of UI spoofing attacks somewhat. However, for > full-screen games, it might be useful to be able to request more > keyboard input (as mentioned in the proposal). It would be good to keep > in mind that the API needs to support requesting keyboard permissions, > and it might be considered odd to have totally different API flows for > the keyboard-enabled case and for the keyboard-limited case.
If full-screen is limited to being initiated by a user event, and has a visible transition, that significantly diminishes the possibility of effective spoofing. I would say it is better to entirely disallow non-user-initiated fullscreen than to prompt about it. Limited or no keyboard input also greatly mitigates the risk of a full OS UI spoofing attack. I think there are better ways to address this than prompting the user. For example, for apps requesting full keyboard access, there could be an always-visible onscreen indicator that is not easily covered up. This does not necessarily have to be ugly, or distracting in a game context. Another possibility is to have the indicator appear on mouse move. I think these are more sensible and pleasant mitigations than a user prompt. And possibly also more effective. If the user can be confused about what state the OS is in after clicking something and then seeing a visible transition (perhaps followed by a faked version of the browser crashing and the OS popping up some password dialog), then they could quite possibly also be fooled if they first clicked on a "cancel or allow" prompt. Note that for the non-keyboard / limited keyboard case (likely the common case for video players), the full-OS spoof phishing attack is not even much of a threat in the first place, so prompting in that case just promotes confirmation fatigue with no real benefit. If we could take prompting the user off the table in the range of UIs we are considering, it would allow us to significantly simplify both the API and the user interface for this feature. So I hope we can consider this. I'm not sure extensions like NoScript alone are sufficient reason to impose the additional complexity required by a user prompting model. After all, the API for running a script doesn't involve an asynchronous request model, yet NoScript somehow manages to do its thing. Regards, Maciej
