Security/AppsProject/Element.mozRequestFullscreenWithKeys

From MozillaWiki
Jump to: navigation, search
Please use "Edit with form" above to edit this page.

Item Reviewed

Element.mozRequestFullscreenWithKeys
Target bug 716107 - Better key input support in DOM full-screen mode - requestFullScreenWithKeys API


Introduce the Feature

Goal of Feature, what is trying to be achieved (problem solved, use cases, etc)

  • Enable keys to be used in fullscreen mode, for games and other immersive experiences.
  • Video also needs fullscreen, but only cares about the video controls' keys.
  • Any solution has to take into consideration how fullscreen approval UI interacts with pointer lock.

What solutions/approaches were considered other than the proposed solution?

  • Having separate Element.requestFullscreenWithKeys() method, but I think this:
    • Would lead to confusion by users as to why they have to grant permission for fullscreen in some cases (with keyboard input) but not others.
    • I doubt developers will care about the difference and just use requestFullscreenWithKeys() most of the time anyway. The bad guys definitely won't care (unless they are specifically interested in phishing passwords using the keyboard).
    • This doesn't match the current draft spec, which only has requestFullscreen(), and doesn't mention key input at all.
    • This won't match Chrome's behaviour (grant key access regardless whether it's requested or not).
    • What should we do on mobile when this is called?
    • "With keys" is meaningless on devices with soft keyboards
  • We could have the fullscreen API ask permission (rather than forgiveness) before entering fullscreen the first time, and automatically grant subsequent requests. Similar to how geolocation works. This has the disadvantage that there may not be an explicit "deny" action from the user to notify script that the fullscreen request failed; script could be left waiting for a "fullscreendenied" event that never comes.
  • We could require that pages use a "full-screen" button and icon built into Firefox, and apply light anti-clickjacking measures to that button. Provide various reasonable sizes and colors, so the button can be integrated into the site's set of video controls. By restricting full-screen requests to this special button, we'd be more confident that the user actually intended to go full-screen, and maybe we can avoid requiring a separate click to allow.
    • Won't cut down on extra actions when full-screening using the keyboard. You'll have to indicate which element you want full-screened, unless the site is clever.
  • We could have a "video only" mode that's even more restrictive -- not even mouse input -- but doesn't require as-explicit permission.
    • Doesn't really fit YouTube's use case, which includes ads and suggested-next-videos. Both of these things need to be clicked on.
  • Also considering blocking mouse events to page while showing the approval UI (and we should grey out the page if we do this I think), as we're thinking of doing this so if script requests pointer-lock when we enter fullscreen (but before it's been approved) we can pretend to be pointer-locked but still show the mouse in order to use the approval UI.
    • May instead just delay granting pointer lock until fullscreen is approved, still haven't reached consensus with Olli Petay on this.

Why was this solution chosen?

  • Balances convenience with awareness and security.
  • I would also like to remove the "dim <browser> for first 2 seconds when entering fullscreen". Seems to be unneccessary when we don't auto-hide the approval UI.

Any security threats already considered in the design and why?

  • Spoofing attacks; we show the domain name in the fullscreen approval UI, so user is aware they're in fullscreen mode, and what website is fullscreen. Appoval UI doesn't auto-hide (unless the site has been whitelisted), so user can't fail to notice they're in fullscreen.
  • Web page can put up lots of boxes styled similarly to the "you've entered fullscreen" approval UI, in order to overwhelm the user so they don't read the UI warning and don't realise what's going on. Since we don't dismiss the UI unless the user clicks on it, the user shouldn't

Threat Brainstorming

  • Cross domain subdocs? Throw up the approval UI again? Are they actually a threat?
    • When a youtube video is embedded in another site, which site gets whitelisted? Depends on whether it uses the youtube <iframe> embed or the other embed?
  • [Jesse] Whitelisting really worries me.
    • Most of these domains will be non-https. Adds MITM risk: once everyone whitelists youtube, an attacker at Starbucks can spoof your bank at any time.
      • There is a notification even on whitelisted sites. The only difference is that it goes away on its own (?).
      • There's still an animation to show that you're entering full-screen (on Lion) (the animation needs work).
    • Gives youtube an unfair advantage over other video sites / self-hosted videos.
    • Gives youtube more permissions than it really needs.
  • Privacy questions about the whitelist.
    • How does this interact with private browsing mode? Are permission grants done during private browsing mode persisted when PB mode is exited?
      • Firefox's standard "permission manager" takes care of this automatically, along with making "Clear recent history" work :)
  • Ensure the Esc key can't enter full-screen mode. (In case you're confused about whether you're in full-screen mode.)
  • Should we have a "remember my decision" checkbox? (Makes it clearer what's happening; gives users a way to choose.)
    • Checked by default?
    • cpearce filing a bug for this?
  • Property "SecReview feature goal" (as page type) with input value "* Enable keys to be used in fullscreen mode, for games and other immersive experiences.
    • Video also needs fullscreen, but only cares about the video controls' keys.
    • Any solution has to take into consideration how fullscreen approval UI interacts with pointer lock." contains invalid characters or is incomplete and therefore can cause unexpected results during a query or annotation process.
    • Property "SecReview alt solutions" (as page type) with input value "* Having separate Element.requestFullscreenWithKeys() method, but I think this:
      • Would lead to confusion by users as to why they have to grant permission for fullscreen in some cases (with keyboard input) but not others.
      • I doubt developers will care about the difference and just use requestFullscreenWithKeys() most of the time anyway. The bad guys definitely won't care (unless they are specifically interested in phishing passwords using the keyboard).
      • This doesn't match the current draft spec, which only has requestFullscreen(), and doesn't mention key input at all.
      • This won't match Chrome's behaviour (grant key access regardless whether it's requested or not).
      • What should we do on mobile when this is called?
      • "With keys" is meaningless on devices with soft keyboards
    • We could have the fullscreen API ask permission (rather than forgiveness) before entering fullscreen the first time, and automatically grant subsequent requests. Similar to how geolocation works. This has the disadvantage that there may not be an explicit "deny" action from the user to notify script that the fullscreen request failed; script could be left waiting for a "fullscreendenied" event that never comes.
    • We could require that pages use a "full-screen" button and icon built into Firefox, and apply light anti-clickjacking measures to that button. Provide various reasonable sizes and colors, so the button can be integrated into the site's set of video controls. By restricting full-screen requests to this special button, we'd be more confident that the user actually intended to go full-screen, and maybe we can avoid requiring a separate click to allow.
      • Won't cut down on extra actions when full-screening using the keyboard. You'll have to indicate which element you want full-screened, unless the site is clever.
    • We could have a "video only" mode that's even more restrictive -- not even mouse input -- but doesn't require as-explicit permission.
      • Doesn't really fit YouTube's use case, which includes ads and suggested-next-videos. Both of these things need to be clicked on.
    • Also considering blocking mouse events to page while showing the approval UI (and we should grey out the page if we do this I think), as we're thinking of doing this so if script requests pointer-lock when we enter fullscreen (but before it's been approved) we can pretend to be pointer-locked but still show the mouse in order to use the approval UI.
      • May instead just delay granting pointer lock until fullscreen is approved, still haven't reached consensus with Olli Petay on this." contains invalid characters or is incomplete and therefore can cause unexpected results during a query or annotation process.
      • Property "SecReview solution chosen" (as page type) with input value "* Balances convenience with awareness and security.
    • I would also like to remove the "dim for first 2 seconds when entering fullscreen". Seems to be unneccessary when we don't auto-hide the approval UI." contains invalid characters or is incomplete and therefore can cause unexpected results during a query or annotation process.
    • Property "SecReview threats considered" (as page type) with input value "* Spoofing attacks; we show the domain name in the fullscreen approval UI, so user is aware they're in fullscreen mode, and what website is fullscreen. Appoval UI doesn't auto-hide (unless the site has been whitelisted), so user can't fail to notice they're in fullscreen.
    • Web page can put up lots of boxes styled similarly to the "you've entered fullscreen" approval UI, in order to overwhelm the user so they don't read the UI warning and don't realise what's going on. Since we don't dismiss the UI unless the user clicks on it, the user shouldn't" contains invalid characters or is incomplete and therefore can cause unexpected results during a query or annotation process.
    • Property "SecReview threat brainstorming" (as page type) with input value "* Cross domain subdocs? Throw up the approval UI again? Are they actually a threat?
      • When a youtube video is embedded in another site, which site gets whitelisted? Depends on whether it uses the youtube embed or the other embed?
    • [Jesse] Whitelisting really worries me.
      • Most of these domains will be non-https. Adds MITM risk: once everyone whitelists youtube, an attacker at Starbucks can spoof your bank at any time.
        • There is a notification even on whitelisted sites. The only difference is that it goes away on its own (?).
        • There's still an animation to show that you're entering full-screen (on Lion) (the animation needs work).
      • Gives youtube an unfair advantage over other video sites / self-hosted videos.
      • Gives youtube more permissions than it really needs.
    • Privacy questions about the whitelist.
      • How does this interact with private browsing mode? Are permission grants done during private browsing mode persisted when PB mode is exited?
        • Firefox's standard "permission manager" takes care of this automatically, along with making "Clear recent history" work :)
    • Ensure the Esc key can't enter full-screen mode. (In case you're confused about whether you're in full-screen mode.)
    • Should we have a "remember my decision" checkbox? (Makes it clearer what's happening; gives users a way to choose.)
      • Checked by default?
      • cpearce filing a bug for this?" contains invalid characters or is incomplete and therefore can cause unexpected results during a query or annotation process.

Action Items

Action Item Status None
Release Target `
Action Items
'

Required Reading List:

Retrieved from "https://wiki.mozilla.org/index.php?title=Security/AppsProject/Element.mozRequestFullscreenWithKeys&oldid=423651"