WebAPI Security Discussion: Screen Orientation

[Lucas Adamski]

Here's the first API up for discussion. This should be pretty straightforward so I hope to close out this discussion by
end of day Thursday (PDT).

I'd like to keep this discussion on mozilla.dev.webapps, but I'll take responses on other lists over silence. :)

Name of API: Screen Orientation
Reference: bug 720794 bug 673922

Brief purpose of API: Get notification when screen orientation changes as well as lock the screen orientation

Inherent threats: minor information leakage (device orientation), minor user inconvenience (lock device orientation)

Threat severity: low per https://wiki.mozilla.org/Security_Severity_Ratings

== Regular web content (unauthenticated) ==
Use cases for unauthenticated code: Prevent screen orientation from changing when playing a game utilizing device motion
Authorization model for normal content: implicit for detecting orientation, explicit runtime for locking orientation
Authorization model for installed content: implicit for both
Potential mitigations: Orientation should remained locked only while focused.

== Trusted (authenticated by publisher) ==
Use cases for authenticated code: Same as unauthenticated
Authorization model: implicit
Potential mitigations: Orientation should remained locked only while focused.

== Certified (vouched for by trusted 3rd party) ==
Use cases for certified code: Same as above
Authorization model: implicit
Potential mitigations: none

[Jonas Sicking]

On Tue, Apr 10, 2012 at 4:59 PM, Lucas Adamski <lada...@mozilla.com> wrote:
> Here's the first API up for discussion.  This should be pretty straightforward so I hope to close out this discussion by
> end of day Thursday (PDT).
>
> I'd like to keep this discussion on mozilla.dev.webapps, but I'll take responses on other lists over silence. :)
>
> Name of API: Screen Orientation
> Reference: bug 720794 bug 673922
>
> Brief purpose of API: Get notification when screen orientation changes as well as lock the screen orientation
>
> Inherent threats: minor information leakage (device orientation), minor user inconvenience (lock device orientation)
>
> Threat severity: low per https://wiki.mozilla.org/Security_Severity_Ratings
>
> == Regular web content (unauthenticated) ==
> Use cases for unauthenticated code: Prevent screen orientation from changing when playing a game utilizing device motion

I'd also add: Switch screen orientation when switching between
different parts of an app. For example when switching from UI to
browse lists of videos, to UI which plays a specific video. Or
switching orientation between people facing one another playing a game
on the device.

> Authorization model for normal content: implicit for detecting orientation, explicit runtime for locking orientation

I'm not sure what "explicit runtime for locking" entails here. I don't
think we want an explicit prompt when the page requests that the
orientation be locked in a particular direction. Basically it seems to
me that prompting the user for something as "trivial" as screen
orientation (which you can basically do by simply rendering your text
sideways anyway) would just lead to "prompt fatigue" with users.

> Authorization model for installed content: implicit for both

Agreed. For an installed application you can always exit the
application by closing it (this should be true on both mobile and
desktop). So the page can't really DoS the user by continuously
switching the screen orientation.

> Potential mitigations: Orientation should remained locked only while focused.

I think we might need more than that, especially since I'd prefer to
not have an explicit ask-for-permission prompt for screen locks, even
for uninstalled apps. What I propose is this:

1. Orientation locks only affect the locked app/page. If the user
switches tab or app, the other pages aren't affected.
2. If the page is installed content, always allow the orientation lock.
3. If the page is in fullscreen mode, always allow the orientation
lock. There is no browser UI being displayed anyway and so the page
could cause the same behavior by simply rendering text sideways. Need
to verify that this will work on mobile.
4. If the page isn't in fullscreen mode, and is contained in an
<iframe> (or <frame>) never allow the lock request.
4. If the call to lock the screen orientation happens in response to a
user action, always allow the orientation lock.
5. If the call to lock the screen orientation doesn't actually require
the screen to be immediately re-orientated, always allow the
orientation lock.
6. If no other calls to change the lock orientation has happened in
the last X (say 5) seconds, allow the orientation lock. This is mostly
to cover the case of the page setting its lock during initial page
setup.

We could potentially skip rule 5 since it doesn't actually solve any
real problems, and might just be confusing to developers. The other
rules should be enough to allow all sanely written code to "just
work".

> == Trusted (authenticated by publisher) ==

> == Certified (vouched for by trusted 3rd party) ==

For the sake of simplicity for page authors, I think I would prefer to
keep these two the same as the unauthenticated. I agree that we could
relax constraints here, but I think that would cause more confusion
than it would add value. And for now these two groups consist of
installed content only, which basically means full rights to the API.

/ Jonas

[JOSE MANUEL CANTERA FONSECA]

El 11/04/12 06:07, "Jonas Sicking" <jo...@sicking.cc> escribió:

>
>4. If the page isn't in fullscreen mode, and is contained in an
><iframe> (or <frame>) never allow the lock request.

Currently Gaia and OWD Apps run in independent iframes which are children
of the top level browsing context ... Thus I think here we have a problem
...

>


Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nuestra política de envío y recepción de correo electrónico en el enlace situado más abajo.
This message is intended exclusively for its addressee. We only send and receive email on the basis of the terms set out at
http://www.tid.es/ES/PAGINAS/disclaimer.aspx

[Jonas Sicking]

On Wed, Apr 11, 2012 at 1:35 AM, JOSE MANUEL CANTERA FONSECA
<jm...@tid.es> wrote:
> El 11/04/12 06:07, "Jonas Sicking" <jo...@sicking.cc> escribió:
>
>>
>>4. If the page isn't in fullscreen mode, and is contained in an
>><iframe> (or <frame>) never allow the lock request.
>
> Currently Gaia and OWD Apps run in independent iframes which are children
> of the top level browsing context ... Thus I think here we have a problem
> ...

>From an API point of view that's basically an implementation detail.
Basically any frame marked with the mozbrowser/mozapp attribute won't
be considered a "real" iframe, and so any page inside it is considered
to be the toplevel frame.

/ Jonas

[Lucas Adamski]

On Apr 10, 2012, at 9:07 PM, Jonas Sicking wrote:

> On Tue, Apr 10, 2012 at 4:59 PM, Lucas Adamski <lada...@mozilla.com> wrote:
>>
>> == Regular web content (unauthenticated) ==
>> Use cases for unauthenticated code: Prevent screen orientation from changing when playing a game utilizing device motion
>
> I'd also add: Switch screen orientation when switching between
> different parts of an app. For example when switching from UI to
> browse lists of videos, to UI which plays a specific video. Or
> switching orientation between people facing one another playing a game
> on the device.

Ah ok, so the ability of the app to specify a specific orientation.

>> Authorization model for normal content: implicit for detecting orientation, explicit runtime for locking orientation
>
> I'm not sure what "explicit runtime for locking" entails here. I don't
> think we want an explicit prompt when the page requests that the
> orientation be locked in a particular direction. Basically it seems to
> me that prompting the user for something as "trivial" as screen
> orientation (which you can basically do by simply rendering your text
> sideways anyway) would just lead to "prompt fatigue" with users.

I think I had confused orientation of the content with orientation of its container/app. Disregard, I agree that it doesn't need any explicit authorization.

>
>> Potential mitigations: Orientation should remained locked only while focused.
>
> I think we might need more than that, especially since I'd prefer to
> not have an explicit ask-for-permission prompt for screen locks, even
> for uninstalled apps. What I propose is this:
>
> 1. Orientation locks only affect the locked app/page. If the user
> switches tab or app, the other pages aren't affected.
> 2. If the page is installed content, always allow the orientation lock.
> 3. If the page is in fullscreen mode, always allow the orientation
> lock. There is no browser UI being displayed anyway and so the page
> could cause the same behavior by simply rendering text sideways. Need
> to verify that this will work on mobile.

> 4. If the page isn't in fullscreen mode, and is contained in an
> <iframe> (or <frame>) never allow the lock request.

> 4. If the call to lock the screen orientation happens in response to a
> user action, always allow the orientation lock.
> 5. If the call to lock the screen orientation doesn't actually require
> the screen to be immediately re-orientated, always allow the
> orientation lock.
> 6. If no other calls to change the lock orientation has happened in
> the last X (say 5) seconds, allow the orientation lock. This is mostly
> to cover the case of the page setting its lock during initial page
> setup.
>
> We could potentially skip rule 5 since it doesn't actually solve any
> real problems, and might just be confusing to developers. The other
> rules should be enough to allow all sanely written code to "just
> work".

I'm having a hard time keeping this all in my brain. :) If I were to condense this into a set of simpler rules would it still meet the behavior as described above?
a) Orientation locks only affect the locked app/page. If the user switches tab or app, the other pages aren't affected.
b) Only top level or full-screen content can set the lock

You have two #4s in that list, so regarding #4b I'm not sure why we need a special exception to user initiated locks if they are generally permitted. Is that just for iframes or frames? Same for 5 or 6 I guess. Fundamentally if this lock only affects the content requesting the lock, then I agree there's no reason to restrict its behavior (content can always choose to annoy the user).

One thing that doesn't seem to have been discussed is whether a change to the top-level orientation also changes the orientation for embedded iframes and other content?

>
>> == Trusted (authenticated by publisher) ==
>> == Certified (vouched for by trusted 3rd party) ==
>
> For the sake of simplicity for page authors, I think I would prefer to
> keep these two the same as the unauthenticated. I agree that we could
> relax constraints here, but I think that would cause more confusion
> than it would add value. And for now these two groups consist of
> installed content only, which basically means full rights to the API.

Makes sense (modulo finalizing discussion above).
Lucas.

[Jonas Sicking]

On Wed, Apr 11, 2012 at 3:33 PM, Lucas Adamski <lada...@mozilla.com> wrote:
> On Apr 10, 2012, at 9:07 PM, Jonas Sicking wrote:
>
>> On Tue, Apr 10, 2012 at 4:59 PM, Lucas Adamski <lada...@mozilla.com> wrote:
>>>
>>> == Regular web content (unauthenticated) ==
>>> Use cases for unauthenticated code: Prevent screen orientation from changing when playing a game utilizing device motion
>>
>> I'd also add: Switch screen orientation when switching between
>> different parts of an app. For example when switching from UI to
>> browse lists of videos, to UI which plays a specific video. Or
>> switching orientation between people facing one another playing a game
>> on the device.
>
> Ah ok, so the ability of the app to specify a specific orientation.

Yes. Or a restricted set of orientations (like only the two portrait modes).

>>> Authorization model for normal content: implicit for detecting orientation, explicit runtime for locking orientation
>>
>> I'm not sure what "explicit runtime for locking" entails here. I don't
>> think we want an explicit prompt when the page requests that the
>> orientation be locked in a particular direction. Basically it seems to
>> me that prompting the user for something as "trivial" as screen
>> orientation (which you can basically do by simply rendering your text
>> sideways anyway) would just lead to "prompt fatigue" with users.
>
> I think I had confused orientation of the content with orientation of its container/app.  Disregard, I agree that it doesn't need any explicit authorization.

Well.. inside a browser app I think a page setting its orientation
will also affect the where the browser UI goes.

Some people have said that they don't want in-browser-pages to be able
to affect the orientation of themselves+browserUI at all. Only if a
page is fullscreened should it be able to set its orientation since
then it isn't messing with the browser UI (since there is none).

Yes! With the one exception mentioned above.

> You have two #4s in that list, so regarding #4b I'm not sure why we need a special exception to user initiated locks if they are generally permitted.  Is that just for iframes or frames?  Same for 5 or 6 I guess.  Fundamentally if this lock only affects the content requesting the lock, then I agree there's no reason to restrict its behavior (content can always choose to annoy the user).

Doh! I was referring to the second 4.

The restrictions would only be there in order to prevent
pages-in-a-browser from messing with the browser UI since the browser
UI moves when the page changes orientation.

> One thing that doesn't seem to have been discussed is whether a change to the top-level orientation also changes the orientation for embedded iframes and other content?

IMO it should. I think we generally want all content on the screen to
have the same orientation.

/ Jonas

[Mounir Lamouri]

On 04/11/2012 06:07 AM, Jonas Sicking wrote:
> 4. If the page isn't in fullscreen mode, and is contained in an
> <iframe> (or <frame>) never allow the lock request.

Currently, our implementation allow an iframe to request to lock
orientation if the fullscreen has been requested by the iframe itself or
an iframe's document child. IOW, an iframe can't lock the screen if the
fullscreen request has been made by a parent.

> 4. If the call to lock the screen orientation happens in response to a
> user action, always allow the orientation lock.

Would that apply to non-installed content?

> 5. If the call to lock the screen orientation doesn't actually require
> the screen to be immediately re-orientated, always allow the
> orientation lock.

Would that also apply to non-installed content? I'm afraid this could
lead to very add UX.

> 6. If no other calls to change the lock orientation has happened in
> the last X (say 5) seconds, allow the orientation lock. This is mostly
> to cover the case of the page setting its lock during initial page
> setup.

I'm assuming that would apply to non-installed content but I wonder why
that would be useful. I mean, if we follow the previous rules, why
should we prevent a change more often? Or is that for pages that would
lock on each click? Doesn't seem really serious.

--
Mounir

[Lucas Adamski]

Updated proposal per comments. I ended up trying to reconcile the various points more than simply documenting them so please review carefully as I likely missed something. :)

Name of API: Screen Orientation
Reference: bug 720794 bug 673922

Brief purpose of API: Get notification when screen orientation changes as well as lock the screen orientation

Inherent threats: minor information leakage (device orientation), minor user inconvenience (lock device orientation)

Threat severity: low per https://wiki.mozilla.org/Security_Severity_Ratings

== Regular web content (unauthenticated) ==

Use cases for unauthenticated code: Prevent screen orientation from changing when playing a game utilizing device motion. Switch screen orientation when switching between
different parts of an app (i.e. from playlist to video playback). API wise, this means detecting orientation and setting/locking orientation.
Authorization model for normal content: implicit for detecting orientation, implicit for locking/setting orientation in fullscreen only

Authorization model for installed content: implicit for both

Potential mitigations: As mentioned, normal content can only set/lock orientation in fullscreen. Only top-level content can set/lock.

== Trusted (authenticated by publisher) ==

Use cases for authenticated code: Same as unauthenticated
Authorization model: implicit

Potential mitigations: None

== Certified (vouched for by trusted 3rd party) ==

Use cases for certified code: Same as above

Authorization model: Same as above
Potential mitigations: None

On Apr 10, 2012, at 4:59 PM, Lucas Adamski wrote:

> Here's the first API up for discussion. This should be pretty straightforward so I hope to close out this discussion by
> end of day Thursday (PDT).
>
> I'd like to keep this discussion on mozilla.dev.webapps, but I'll take responses on other lists over silence. :)
>
> Name of API: Screen Orientation
> Reference: bug 720794 bug 673922
>
> Brief purpose of API: Get notification when screen orientation changes as well as lock the screen orientation
>
> Inherent threats: minor information leakage (device orientation), minor user inconvenience (lock device orientation)
>
> Threat severity: low per https://wiki.mozilla.org/Security_Severity_Ratings
>

> == Regular web content (unauthenticated) ==
> Use cases for unauthenticated code: Prevent screen orientation from changing when playing a game utilizing device motion

> Authorization model for normal content: implicit for detecting orientation, explicit runtime for locking orientation

> Authorization model for installed content: implicit for both

> Potential mitigations: Orientation should remained locked only while focused.
>

> == Trusted (authenticated by publisher) ==

> Use cases for authenticated code: Same as unauthenticated
> Authorization model: implicit

> Potential mitigations: Orientation should remained locked only while focused.
>

> == Certified (vouched for by trusted 3rd party) ==

[Mounir Lamouri]

On 04/19/2012 03:37 AM, Lucas Adamski wrote:
> Potential mitigations: As mentioned, normal content can only set/lock orientation in fullscreen. Only top-level content can set/lock.

What do you mean by "top-level" content?

--
Mounir

[Lucas Adamski]

I mean the root level content; not in a sub frame/iframe.
Lucas.

[Jonas Sicking]

On Fri, Apr 13, 2012 at 2:28 AM, Mounir Lamouri <mou...@lamouri.fr> wrote:
> On 04/11/2012 06:07 AM, Jonas Sicking wrote:
>> 4. If the page isn't in fullscreen mode, and is contained in an
>> <iframe> (or <frame>) never allow the lock request.
>
> Currently, our implementation allow an iframe to request to lock
> orientation if the fullscreen has been requested by the iframe itself or
> an iframe's document child. IOW, an iframe can't lock the screen if the
> fullscreen request has been made by a parent.

Right, that matches what I intended to say.

>> 4. If the call to lock the screen orientation happens in response to a
>> user action, always allow the orientation lock.
>
> Would that apply to non-installed content?

Yes, but only after the previous rule has been applied. I.e. if the
page is inside an <iframe> and isn't fullscreened then it wouldn't be
allowed.

I would be ok with also saying that non-installed content can't ever
set the screen orientation unless it's in fullscreen mode if we think
it's too annoying to have pages in a browser rotate the browser UI.

>> 5. If the call to lock the screen orientation doesn't actually require
>> the screen to be immediately re-orientated, always allow the
>> orientation lock.
>
> Would that also apply to non-installed content? I'm afraid this could
> lead to very add UX.

I agree that if we generally don't allow non-fullscreened
non-installed content to set the orientation, we shouldn't allow it
here either.

>> 6. If no other calls to change the lock orientation has happened in
>> the last X (say 5) seconds, allow the orientation lock. This is mostly
>> to cover the case of the page setting its lock during initial page
>> setup.
>
> I'm assuming that would apply to non-installed content but I wonder why
> that would be useful. I mean, if we follow the previous rules, why
> should we prevent a change more often? Or is that for pages that would
> lock on each click? Doesn't seem really serious.

The intent was to prevent pages to change the screen orientation 10
times per second, thus making the browser UI unusable since it's
constantly moving around.

/ Jonas