Re: [Bug 19297] New: May user agents apply additional restrictions on entering pointer lock?

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