- From: Charles McCathie Nevile <chaals@yandex-team.ru>
- Date: Tue, 09 Oct 2012 11:41:40 +0200
- To: bugzilla@jessica.w3.org, Florian Bösch <pyalot@gmail.com>
- Cc: public-webapps@w3.org
On Tue, 09 Oct 2012 08:43:13 +0200, Florian Bösch <pyalot@gmail.com> 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, <bugzilla@jessica.w3.org> 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: scheib@chromium.org
>>
>> ReportedBy: scheib@chromium.org
>>
>> QAContact: public-webapps-bugzilla@w3.org
>>
>> CC: mike@w3.org, public-webapps@w3.org
>>
>>
>>
>>
>>
>> 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
chaals@yandex-team.ru Find more at http://yandex.com
Received on Tuesday, 9 October 2012 09:42:19 UTC