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

TL;DR: We might be in violent agreement here. There are variations  
possible in UX that follow the principle described for the fix.

On Tue, 09 Oct 2012 12:09:34 +0200, Florian Bösch <pyalot@gmail.com> wrote:
> <chaals@yandex-team.ru> wrote:
>> On Tue, 09 Oct 2012 08:43:13 +0200, Florian Bösch <pyalot@gmail.com>

>>> 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.
>
> I think the reasoning to allow for elements to be fullscreened is pretty  
> solid

I agree.

> You ultimately cannot prevent the page showing something else entirely  
> upon entering fullscreen, but you can make it much more tedious for  
> legitimate uses by removing the element fullscreen functionality. To  
> that end, there wouldn't be a point not to do the element fullscreen  
> capability.

Right.

The issue is how far we can mitigate the problem.

> The reasoning to allow for javascript polled fullscreen is also pretty  
> solid. The use-case for element fullscreen is evident and desired.  
> Absent any means to target what element, a fullscreen menu/shortcut  
> won't be able to do it right.

Agreed.

> Short of actually removing JS polled fullscreen you cannot address the  
> issue on the basis of "whenever something goes fullscreen it can be  
> something else".

I agree that we can't stop the content changing.

Thinking aloud, the browser can control the transition to fullscreen, e.g.  
zooming the element there over half a second. Without some kind of  
indicator like the little browser-imposed stripe across the top that is  
used in some "fullscreens", you may not be able to make the transition  
 from fullscreen unspoofable - and this is an obvious place to implement  
the attack. It is possible that having a tabbed browser is sufficiently  
hard to copy that the attack is mitigated, but mobile browsers suggest  
that might not always be true.

> Yet, the case for fullscreen altogether is also pretty evident. This  
> would come down to a choice between having fullscreen and not having  
> fullscreen at all, which I think, is not a choice anybody would be  
> >happy with.

I think very few people are happy with the consequences of same-origin  
restrictions (which is why we developed CORS), but they are there, because  
people were even more unhappy with the alternative. Security matters.  
Throwing it out because we want to make something look better is an option  
that at least some browsers will probably reject outright, judging from  
history...

> The fix proposed works on the principle that the message to enter  
> fullscreen disconnects the immediate display of the phish (the change  
> blindness) from the actual action with the expected result (clicking  
> link) by layering a dialog/indefinite delay until clicked between a link  
> and a display, thereby removing the "blindness" almost entirely (you  
> have to look at the screen to click a confirmation dialog, upon clicking  
> the dialog, the screen will change a lot). I would propose making this  
> confirmation fairly obstrusive/centered (like in firefox, chrome uses a  
> very easily ignored dialog).

I think we are in violent agreement here...

> Ultimately you have to accept that if you want fullscreen, and if you  
> asked the user, and the user clicked yes, then this is all you can do.

Sure.

> The only other choice is not to do fullscreen which would in my opinion  
> exceed the remit of a reasonable security measure by far.

I would not prescribe what might be a reasonable security measure so  
tightly. What is reasonable depends IMHO on the risk more directly than on  
the desirability of the feature that creates that risk. But it might not  
be an important question in this case.

>>> - 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.

> I don't understand how it gives more control over the experience.

If the developer doesn't have to wait for user consent, there is one less  
constraint imposed on their control of the experience. They could ask for  
the consent themselves. Or provide a transition effect that they think  
shows the user what is happening, since good UX generally avoids change  
blindness without specifically caring about the security that provides.

cheers

chaals

-- 
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 10:42:20 UTC