822654 - SecReview: Extend Pointer Lock (Mouse Lock) for non-fullscreen elements

Status: RESOLVED FIXED

(mozilla.org :: Security Assurance: Review Request, task)

Description

[Curtis Koenig [:curtisk-use curtis.koenig+bzATgmail.com]]]

1) Who is/are the point of contact(s) for this review?
2) Please provide a short description of the feature / application (e.g. problem solved, use cases, etc.):
3) Please provide links to additional information (e.g. feature page, wiki) if available and not yet included in feature description:
4) Does this request block another bug? If so, please indicate the bug number
5) This review will be scheduled amongst other requested reviews. What is the urgency or needed completion date of this review?
6) To help prioritize this work request, does this project support a goal specifically listed on this quarter's goal list?  If so, which goal?
7) Please answer the following few questions: (Note: If you are asked to describe anything, 1-2 sentences shall suffice.)
7a) Does this feature or code change affect Firefox, Thunderbird or any product or service the Mozilla ships to end users?
7b) Are there any portions of the project that interact with 3rd party services?
7c) Will your application/service collect user data? If so, please describe
8) If you feel something is missing here or you would like to provide other kind of feedback, feel free to do so here (no limits on size):
9) Desired Date of review (if known from https://mail.mozilla.com/home/[e-mail]/Security%20Review.html) and whom to invite.

Comment 1

[Ian Melven :imelven]

https://www.w3.org/Bugs/Public/show_bug.cgi?id=19297 looks to be blocked on this review.

Comment 2

[Ian Melven :imelven]

(In reply to Ian Melven :imelven from comment #1)
> https://www.w3.org/Bugs/Public/show_bug.cgi?id=19297 looks to be blocked on
> this review.

see https://www.w3.org/Bugs/Public/show_bug.cgi?id=19297#c3

Comment 3

[Curtis Koenig [:curtisk-use curtis.koenig+bzATgmail.com]]]

this bug is flagged needs-info before we can do a review

Comment 4

[Ian Melven :imelven]

(In reply to Curtis Koenig [:curtisk] from comment #3)
> this bug is flagged needs-info before we can do a review

Looking at the w3c bug and the discussion in the bug for the actual work here, it seems like there's a disconnect between what the spec says, what FF does, and what Chrome does.

Maybe providing security input there or for the spec (or in the w3c bug) might be more useful than a review per se at this point ? It seems like we're more at the point where we want to figure out what to do, than reviewing what we've done.

Comment 5

[Curtis Koenig [:curtisk-use curtis.koenig+bzATgmail.com]]]

I am going to take this one and try to find a date for a team review

Comment 6

[Chris Pearce [:cpearce (Not reading bugmail)]]

(In reply to Curtis Koenig [:curtisk] from comment #0)
> 1) Who is/are the point of contact(s) for this review?

Me: Chris Pearce.

> 2) Please provide a short description of the feature / application (e.g.
> problem solved, use cases, etc.):

Allow the pointer (mouse cursor) to be "locked" inside an HTML element. While a element locks the pointer, the pointer is hidden, and movement of the mouse is always reported to that element, i.e. since the mouse cursor can't (logically) move outside of the element, the element receives all movement.

This facilitates non-fullscreen games locking the pointer, for example a non-fullscreen FPS game would want to lock the pointer so that the user could still control their character without the mouse leaving the canvas.

> 3) Please provide links to additional information (e.g. feature page, wiki)
> if available and not yet included in feature description:

Specification: http://www.w3.org/TR/pointerlock/

> 4) Does this request block another bug? If so, please indicate the bug number

Bug 737100 - "Extend Pointer Lock (Mouse Lock) for non-fullscreen elements"

> 5) This review will be scheduled amongst other requested reviews. What is
> the urgency or needed completion date of this review?

Not super urgent, but needs to be done before it's worth starting work on this.

> 6) To help prioritize this work request, does this project support a goal
> specifically listed on this quarter's goal list?  If so, which goal?

Supporting games in HTML5 is a goal, see:
https://wiki.mozilla.org/Platform/2013-Goals
"Enable three application types across the platform: Games..."


> 7) Please answer the following few questions: (Note: If you are asked to
> describe anything, 1-2 sentences shall suffice.)
> 7a) Does this feature or code change affect Firefox, Thunderbird or any
> product or service the Mozilla ships to end users?

Anything that uses Gecko. In practice, only Firefox and maybe Thunderbird, since mobile doesn't have a mouse pointer.

> 7b) Are there any portions of the project that interact with 3rd party
> services?

No.

> 7c) Will your application/service collect user data? If so, please describe

No.

> 8) If you feel something is missing here or you would like to provide other
> kind of feedback, feel free to do so here (no limits on size):

I think that's it.

> 9) Desired Date of review (if known from
> https://mail.mozilla.com/home/[e-mail]/Security%20Review.html)
> and whom to invite.

A 1pm Pacific Time slot, on Monday-Thursday is fine. Please invite at least me. On or after 21 January please.

Comment 7

[Chris Pearce [:cpearce (Not reading bugmail)]]

(In reply to Ian Melven :imelven from comment #4)
> (In reply to Curtis Koenig [:curtisk] from comment #3)
> > this bug is flagged needs-info before we can do a review
> 
> Looking at the w3c bug and the discussion in the bug for the actual work
> here, it seems like there's a disconnect between what the spec says, what FF
> does, and what Chrome does.

Right, we decided to have the pointer lock spec piggy-back on the security model of the fullscreen API, and only work in fullscreen mode. This simplified what kind of security discussions we needed to have at the time.

> Maybe providing security input there or for the spec (or in the w3c bug)
> might be more useful than a review per se at this point ? It seems like
> we're more at the point where we want to figure out what to do, than
> reviewing what we've done.

Yes, we're at the point where we want to figure out what to do, i.e. how can we implement this in a safe-enough fashion.

Comment 8

[Curtis Koenig [:curtisk-use curtis.koenig+bzATgmail.com]]]

How about Mon 25-Feb 1pm PST? 
Sorry for dropping the ball on this one.

Comment 9

[Chris Pearce [:cpearce (Not reading bugmail)]]

(In reply to Curtis Koenig [:curtisk] from comment #8)
> How about Mon 25-Feb 1pm PST? 
> Sorry for dropping the ball on this one.

Mon 25-Feb 1pm PST would be good.

Comment 10

[Curtis Koenig [:curtisk-use curtis.koenig+bzATgmail.com]]]

Meeting Details: 
* Mon 25-Feb-2013, 1300 PST 
* Where: 
- MTV - 3v Very Good Very Mighty 
- SFO - 319- Golden Gate Bridge 
- Vidyo(9710) secreview [https://v.mozilla.com/flex.html?roomdirect.html&key=EEtiuXn8C5EP] 

* IRC Channel: #security 
* Etherpad: http://etherpad.mozilla.com/secreview 

* Dial-in Info (phone): 
- In office or soft phone: extension 92 
- US/INTL: 650-903-0800 or 650-215-1282 then extension 92 
- Toronto: 416-848-3114 then extension 92 
- Toll-free: 800-707-2533 then password 369 
- Conference num 99710 
Items to be reviewed: 
https://bugzilla.mozilla.org/show_bug.cgi?id=822654 

Agenda: 
* Introduce Feature (5-10 minutes) [can be answered ahead of time to save meeting time] 
- Goal of Feature, what is trying to be achieved (problem solved, use cases, etc) 
- What solutions/approaches were considered other than the proposed solution? 
- Why was this solution chosen? 
- Any security threats already considered in the design and why? 
* Threat Brainstorming (30-40 minutes) 
* Conclusions / Action Items (10-20 minutes)

Comment 11

[Chris Pearce [:cpearce (Not reading bugmail)]]

Attachment: Sec review notes.

Notes from security review conducted 25 Feb 2013 PST.

We also covered the issue of having multiple fullscreen windows open on multiple monitors, and allowing fullscreen windows to be blured without them exiting fullscreen (bug 805613 and bug 724554).

Comment 12

[Curtis Koenig [:curtisk-use curtis.koenig+bzATgmail.com]]]

https://wiki.mozilla.org/Security/Reviews/Mouse-Pointer_Lock