WebAPI Security Discussion: Screen Orientation

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

WebAPI Security Discussion: Screen Orientation

Lucas Adamski-2
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
_______________________________________________
dev-security mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-security
Reply | Threaded
Open this post in threaded view
|

Re: WebAPI Security Discussion: Screen Orientation

Jonas Sicking-2
On Tue, Apr 10, 2012 at 4:59 PM, Lucas Adamski <[hidden email]> 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
_______________________________________________
dev-security mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-security
Reply | Threaded
Open this post in threaded view
|

Re: WebAPI Security Discussion: Screen Orientation

JOSE MANUEL CANTERA FONSECA
El 11/04/12 06:07, "Jonas Sicking" <[hidden email]> 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
_______________________________________________
dev-security mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-security
Reply | Threaded
Open this post in threaded view
|

Re: WebAPI Security Discussion: Screen Orientation

Jonas Sicking-2
On Wed, Apr 11, 2012 at 1:35 AM, JOSE MANUEL CANTERA FONSECA
<[hidden email]> wrote:
> El 11/04/12 06:07, "Jonas Sicking" <[hidden email]> 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
_______________________________________________
dev-security mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-security
Reply | Threaded
Open this post in threaded view
|

Re: WebAPI Security Discussion: Screen Orientation

Adrienne Porter Felt
In reply to this post by Jonas Sicking-2
On Tue, Apr 10, 2012 at 9:07 PM, Jonas Sicking <[hidden email]> wrote:

> On Tue, Apr 10, 2012 at 4:59 PM, Lucas Adamski <[hidden email]>
> wrote:
>


> > 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 strongly agree with Jonas -- I don't think screen orientation merits any
kind of dialog.
_______________________________________________
dev-security mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-security
Reply | Threaded
Open this post in threaded view
|

Re: WebAPI Security Discussion: Screen Orientation

Lucas Adamski-2
In reply to this post by Jonas Sicking-2
On Apr 10, 2012, at 9:07 PM, Jonas Sicking wrote:

> On Tue, Apr 10, 2012 at 4:59 PM, Lucas Adamski <[hidden email]> 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.

_______________________________________________
dev-security mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-security
Reply | Threaded
Open this post in threaded view
|

Re: WebAPI Security Discussion: Screen Orientation

Jonas Sicking-2
On Wed, Apr 11, 2012 at 3:33 PM, Lucas Adamski <[hidden email]> wrote:

> On Apr 10, 2012, at 9:07 PM, Jonas Sicking wrote:
>
>> On Tue, Apr 10, 2012 at 4:59 PM, Lucas Adamski <[hidden email]> 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).

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

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
_______________________________________________
dev-security mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-security
Reply | Threaded
Open this post in threaded view
|

Re: WebAPI Security Discussion: Screen Orientation

Lucas Adamski-2
In reply to this post by Lucas Adamski-2
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) ==
> Use cases for certified code: Same as above
> Authorization model: implicit
> Potential mitigations: none

_______________________________________________
dev-security mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-security