On Tue, 09 Oct 2012 08:43:13 +0200, Florian Bösch <[email protected]> wrote:
Cheer up everyone, we've got somebody dedicated to writing fullscreen
exploits now :) http://feross.org/html5-fullscreen-api->attack/
Summary: Change blindness may make phishing attacks feasible (displaying
a mock browser/page in fullscreen)
Cause: Switch to fullscreen before user consent.
Fix: Switch to fullscreen after user consent.
Questions:
- Is this a problem?
The blog shows why it is a problem? It matches a very well-known class of
problem. So I would say "Yes, there is a problem here".
- Does the proposed fix address the problem?
The question of "what gets tp go fullscreen" matters. Getting user consent
to go fullscreen, but then making something else the actual thing that
takes the screen, may not solve the problem because it still enables the
attack to be developed.
- What is the reasoning to switch before user consent?
It allows developers to control more of the experience (which they
generally want). Given the price in security for the user, I would say the
end is not justified.
cheers
Chaals
On Fri, Oct 5, 2012 at 6:45 PM, <[email protected]> wrote:
https://www.w3.org/Bugs/Public/show_bug.cgi?id=19297
Summary: May user agents apply additional restrictions on
entering pointer lock?
Product: WebAppsWG
Version: unspecified
Platform: All
OS/Version: All
Status: NEW
Severity: normal
Priority: P2
Component: Pointer Lock
AssignedTo: [email protected]
ReportedBy: [email protected]
QAContact: [email protected]
CC: [email protected], [email protected]
The pointer lock spec Working Draft 29 May 2012 is written specifying
several
requirements to enter mouse lock, and leaving user agents to add
additional
constraints to prevent nuisance and enforce security policies.
Specifically
the Element requestPointerLock method section [1] states "The user agent
determines if pointer lock state will be entered" and the Security
section [2]
includes varying policies including 'A conservative approach' requiring
user
gestures and 'A full screen approach' requiring full screen.
Initial implementations have added additional constraints beyond those
explicitly listed in [1]. Firefox 14 introduced pointer lock requiring
that
fullscreen be entered and confirmed and that the pointer lock target
match the
fullscreen element. Chrome 22 introduced pointer lock with a more
permissive
policy, allowing pointer lock of any element after fullscreen has been
confirmed. Chrome also permitted pointer lock outside of fullscreen if
it was
requested via a user gesture.
Concern was raised in public-webapps discussion [3] that all user
agents should
use the same policy and that be incorporated into the specification.
[1] http://www.w3.org/TR/2012/WD-pointerlock-20120529/#methods
[2] http://www.w3.org/TR/2012/WD-pointerlock-20120529/#security
[3]
http://lists.w3.org/Archives/Public/public-webapps/2012OctDec/0010.html
--
Configure bugmail:
https://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
--
Charles McCathie Nevile - Consultant (web standards) CTO Office, Yandex
[email protected] Find more at http://yandex.com
