canmove, Confirmed users, Bureaucrats and Sysops emeriti
2,776
edits
Security/AppsProject/Element.mozRequestFullscreenWithKeys: Difference between revisions
Security/AppsProject/Element.mozRequestFullscreenWithKeys (view source)
Revision as of 13:16, 24 April 2012
, 24 April 2012no edit summary
No edit summary |
No edit summary |
||
| Line 24: | Line 24: | ||
* 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. | * 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. | ||
|SecReview threats considered=* 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. | |SecReview threats considered=* 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 | * 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 | ||
|SecReview threat brainstorming=* Cross domain subdocs? Throw up the approval UI again? Are they actually a threat? | |SecReview 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? | ** 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? | ||
| Line 47: | Line 46: | ||
}} | }} | ||
Required Reading List: | Required Reading List: | ||
<ul> | |||
https://bugzilla.mozilla.org/attachment.cgi?id=616431 | <li>Screencast of current proposal, which enables keys in fullscreen mode, but requires explicit approval of all fullscreen requests the first time a domain enters fullscreen: | ||
<ul><li>https://bugzilla.mozilla.org/attachment.cgi?id=616431</ul> | |||
https://bugzilla.mozilla.org/attachment.cgi?id=613472 | <li>Screencast of previous proposed UI, which has separate fullscreen with and without keys modes: | ||
<ul><li>https://bugzilla.mozilla.org/attachment.cgi?id=613472</ul> | |||
https://bugzilla.mozilla.org/show_bug.cgi?id=746885 | <li>Impact of fullscreen approval UI on pointer-lock API: | ||
<ul><li>https://bugzilla.mozilla.org/show_bug.cgi?id=746885</li> | |||
https://wiki.mozilla.org/Security/Reviews/Firefox10/CodeEditor/FullScreenAPI | <li> Previous security review: | ||
Spec: http://dvcs.w3.org/hg/fullscreen/raw-file/tip/Overview.html | <ul><li>https://wiki.mozilla.org/Security/Reviews/Firefox10/CodeEditor/FullScreenAPI</ul> | ||
<li>Spec: | |||
<ul><li>http://dvcs.w3.org/hg/fullscreen/raw-file/tip/Overview.html</ul> | |||
</ul> | |||