Re: [whatwg] api for fullscreen() - security issues
On Jan 31, 2010, at 05:08, Simon Fraser wrote: * disallow enterFullscreen() from a frame or iframe This might be a problem if video sites transition their embedding boilerplate to an iframe in order to be able to be able to serve HTML5, Flash, ActiveX, etc. depending on UA without requiring the embedders to copy and paste anything fancy. * show an hard-to-spoof overlay with some text that tells the user that they can use the Escape key to exit fullscreen, and prevent the page from capturing this keypress. IIRC, it has been shown that at least as implemented in Flash Player, it is possible to draw enough distractions to make the users unable to read this message. Also, when the site is legitimate, it's quite annoying to have the overlay there. Personally, I'd rather have to click through a once per-Origin authorization bar (like geolocation in Firefox) than watch the press esc overlay every time. * make the location field available to the user so that they can see the URL even when in fullscreen This defeats the point of full screen. If I want a 16:9 video to go full screen on a 16:9 display, I want all screen pixels to be used for the video. * drop out of fullscreen if navigating to another page This would constrain slide shows do be unnecessarily Ajaxy and less linkable with per-slide JavaScriptless URLs. -- Henri Sivonen hsivo...@iki.fi http://hsivonen.iki.fi/
Re: [whatwg] api for fullscreen() - security issues
On Feb 1, 2010, at 1:14 AM, Henri Sivonen wrote: On Jan 31, 2010, at 05:08, Simon Fraser wrote: * disallow enterFullscreen() from a frame or iframe This might be a problem if video sites transition their embedding boilerplate to an iframe in order to be able to be able to serve HTML5, Flash, ActiveX, etc. depending on UA without requiring the embedders to copy and paste anything fancy. Perhaps we'd enforce a same-origin rule where the iframe contents have to be from the same domain as the main page, then? * show an hard-to-spoof overlay with some text that tells the user that they can use the Escape key to exit fullscreen, and prevent the page from capturing this keypress. IIRC, it has been shown that at least as implemented in Flash Player, it is possible to draw enough distractions to make the users unable to read this message. That's why I said hard to spoof. The Flash overlay makes the mistake of not being contrasty enough. An improvement would be to dim out the rest of the content while showing this overlay. Also, when the site is legitimate, it's quite annoying to have the overlay there. Personally, I'd rather have to click through a once per-Origin authorization bar (like geolocation in Firefox) than watch the press esc overlay every time. That's a possibility, yes. * make the location field available to the user so that they can see the URL even when in fullscreen This defeats the point of full screen. If I want a 16:9 video to go full screen on a 16:9 display, I want all screen pixels to be used for the video. I said make available, not should be visible at all times. I was thinking of a behavior where it shows up at the top of the screen if the user moves the mouse close to the top. * drop out of fullscreen if navigating to another page This would constrain slide shows do be unnecessarily Ajaxy and less linkable with per-slide JavaScriptless URLs. Maybe a same-origin test could be used here too? But personally I think it's OK to force a fullscreen application to rely on AJAX and twiddling location.hash, rather than loading new pages. Simon
Re: [whatwg] api for fullscreen() - security issues
On Tue, Feb 2, 2010 at 5:00 AM, Simon Fraser s...@me.com wrote: On Feb 1, 2010, at 1:14 AM, Henri Sivonen wrote: On Jan 31, 2010, at 05:08, Simon Fraser wrote: * disallow enterFullscreen() from a frame or iframe This might be a problem if video sites transition their embedding boilerplate to an iframe in order to be able to be able to serve HTML5, Flash, ActiveX, etc. depending on UA without requiring the embedders to copy and paste anything fancy. Perhaps we'd enforce a same-origin rule where the iframe contents have to be from the same domain as the main page, then? I think that wouldn't work because people will want to serve the IFRAME document from the video site. However, I'd very very reluctant to allow subframes to go fullscreen by default. I haven't got any specific attack scenarios in mind, but it seems to add to the power of clickjacking, which is the last thing we need. How about denying fullscreen from subdocuments by default, and allow opt-in with an attribute on iframe, say allowfullscreen? Note that same-origin IFRAMEs can reach into their parent document and make it fullscreen, and make the IFRAME position:fixed etc, to effectively make themselves fullscreen (albeit not very conveniently). Rob -- He was pierced for our transgressions, he was crushed for our iniquities; the punishment that brought us peace was upon him, and by his wounds we are healed. We all, like sheep, have gone astray, each of us has turned to his own way; and the LORD has laid on him the iniquity of us all. [Isaiah 53:5-6]
Re: [whatwg] api for fullscreen() - security issues
On 1/31/10 6:38 AM, Tab Atkins Jr. wrote: This one seems kind of weird. Does the spec currently distinguish significantly between a user-initiated click and a script-initiated one? DOM 3 Events draft does have the concept of trusted events; UA/user generated events are trusted, script generated aren't. -Olli
Re: [whatwg] api for fullscreen() - security issues
On Jan 28, 2010, at 6:42 pm, Robert O'Callahan wrote: On Fri, Jan 29, 2010 at 12:51 PM, Simon Fraser s...@me.com wrote: We have been discussing a more general fullscreen API that lets you take the page fullscreen (perhaps with the ability to focus on a single element), as Maciej mentions. We have not decided on a final form for this API, nor have we resolved whether it's possible to do some nice transition between the two modes. We have talked at some length about the security issues. Input on what people would like from this API is welcome, as are ideas on how the transitions should work. 1) Should be convenient for authors to make any element in a page display fullscreen 2) Should support in-page activation UI for discoverability 3) Should support changing the layout of the element when you enter/exit fullscreen mode. For example, authors probably want some controls to be fixed size while other content fills the screen. 4) Should accommodate potential UA security concerns, e.g. by allowing the transition to fullscreen mode to happen asynchronously after the user has confirmed permission *** WARNING: totally half-baked proposal ahead! *** New API for all elements: void enterFullscreen(optional boolean enableKeys); void exitFullscreen(); boolean attribute supportsFullscreen; boolean attribute displayingFullscreen; beginfullscreen and endfullscreen events The enableKeys parameter to enterFullscreen is a hint to the UA that the application would like to be able to receive arbitrary keyboard input. Otherwise the UA is likely to disable alphanumeric keyboard input. If enableKeys is specified, the UA might require more severe confirmation UI. I'd like to start a discussion on steps that the UA may take to mitigate the risks of using the fullscreen API for phishing attacks. I'm not sure how much should be required of UAs in the spec, but I could imagine that steps that the UA could take may include some or all of the following: * require that enterFullscreen() is being called inside a user-event handler (e.g. click or keypress) to avoid drive-by fullscreen annoyances. * disallow enterFullscreen() from a frame or iframe * show an animation as the window enters fullscreen so the user can see the transition taking place * show an hard-to-spoof overlay with some text that tells the user that they can use the Escape key to exit fullscreen, and prevent the page from capturing this keypress. * show an affordance to allow the user to exit fullscreen (e.g. a close button) when the user moves the mouse * make the location field available to the user so that they can see the URL even when in fullscreen * drop out of fullscreen if navigating to another page * if focussed on an element, drop out of fullscreen if that element is removed from the DOM * limit arbitrary keyboard input unless 'enableKeys' is true * disallow window.open etc. while in fullscreen I'm just not sure which of these would be requirements in the spec. Simon
Re: [whatwg] api for fullscreen() - security issues
On Sat, Jan 30, 2010 at 9:08 PM, Simon Fraser s...@me.com wrote: * require that enterFullscreen() is being called inside a user-event handler (e.g. click or keypress) to avoid drive-by fullscreen annoyances. This one seems kind of weird. Does the spec currently distinguish significantly between a user-initiated click and a script-initiated one? * disallow enterFullscreen() from a frame or iframe Makes sense, though consider its interaction with sandboxed iframes (that is, you may actually *want* the ability to turn on fullscreen-ability for an iframe). * show an animation as the window enters fullscreen so the user can see the transition taking place How would this interact with an author hooking CSS Transitions to the element keyed on the :fullscreen pseudoclass? If we implement the actual fullscreen effect essentially purely in CSS, I'd prefer the minimum amount of magic here. * show an hard-to-spoof overlay with some text that tells the user that they can use the Escape key to exit fullscreen, and prevent the page from capturing this keypress. * show an affordance to allow the user to exit fullscreen (e.g. a close button) when the user moves the mouse Both of these make a lot of sense to me, and match the way fullscreen effects work today, so users will understand it. * make the location field available to the user so that they can see the URL even when in fullscreen This partially defeats the purpose of fullscreen. ^_^ Though, it may be worthwhile to do so anyway, as it would be a major indicator that something is being spoofed. * drop out of fullscreen if navigating to another page Sounds very reasonable. * if focussed on an element, drop out of fullscreen if that element is removed from the DOM Definitely a good idea. * limit arbitrary keyboard input unless 'enableKeys' is true Already has some history, so would probably be a decent idea. * disallow window.open etc. while in fullscreen I don't fully understand this restriction's justification. ~TJ
Re: [whatwg] api for fullscreen() - security issues
On 1/30/10 11:38 PM, Tab Atkins Jr. wrote: On Sat, Jan 30, 2010 at 9:08 PM, Simon Frasers...@me.com wrote: * require that enterFullscreen() is being called inside a user-event handler (e.g. click or keypress) to avoid drive-by fullscreen annoyances. This one seems kind of weird. Does the spec currently distinguish significantly between a user-initiated click and a script-initiated one? Not sure about the spec, but popup blockers sure do. -Boris
