WebAPI Security Discussion: Resource Lock API

Lucas Adamski

unread,

Apr 16, 2012, 2:18:16 AM4/16/12

to dev-w...@lists.mozilla.org, dev-w...@lists.mozilla.org, dev-b2g mailing list, dev-se...@lists.mozilla.org

Please reply-to dev-w...@lists.mozilla.org

Name of API: Resource Lock API
Reference: https://bugzilla.mozilla.org/show_bug.cgi?id=697132

Brief purpose of API: Prevent the screen from being dimmed or switched off
General Use Cases: Request a lock to stop the screen from being dimmed, even if the user is idle (eg. watching a movie)

Inherent threats: Drain power, annoyances

Threat severity: Low

== Regular web content (unauthenticated) ==
Use cases for unauthenticated code: Same as General
Authorization model for normal content: Explicit
Authorization model for installed content:Implicit
Potential mitigations:

== Trusted (authenticated by publisher) ==
Use cases for authenticated code: Same as General
Authorization model:
Potential mitigations:

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

Adrienne Porter Felt

unread,

Apr 16, 2012, 10:26:32 AM4/16/12

to dev-w...@lists.mozilla.org, dev-w...@lists.mozilla.org, dev-se...@lists.mozilla.org, dev-b2g mailing list

It would be great if the spec also specified that the phone needs to
provide a resource consumption manager. That way concerned users could see
which trusted/certified apps are responsible for a short battery life, if
the phone is being drained too fast.

> _______________________________________________
> dev-security mailing list
> dev-se...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security
>

Justin Lebar

unread,

Apr 16, 2012, 7:22:21 PM4/16/12

to Adrienne Porter Felt, dev-w...@lists.mozilla.org, dev-w...@lists.mozilla.org, dev-se...@lists.mozilla.org, dev-b2g mailing list

> It would be great if the spec also specified that the phone needs to
> provide a resource consumption manager.

Perhaps "should" rather than "needs to". This is a non-trivial thing
to do, in general. Not that we shouldn't do it, but I don't think we
should say that we're in violation of the spec if we don't.

> _______________________________________________
> dev-b2g mailing list
> dev...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-b2g

Benjamin Smedberg

unread,

Apr 17, 2012, 9:02:26 AM4/17/12

to dev-w...@lists.mozilla.org

On 4/16/2012 2:18 AM, Lucas Adamski wrote:
> Please reply-to dev-w...@lists.mozilla.org
>
> Name of API: Resource Lock API
> Reference: https://bugzilla.mozilla.org/show_bug.cgi?id=697132
>
> Brief purpose of API: Prevent the screen from being dimmed or switched off
> General Use Cases: Request a lock to stop the screen from being dimmed, even if the user is idle (eg. watching a movie)
>
> Inherent threats: Drain power, annoyances
>
> Threat severity: Low
>
> == Regular web content (unauthenticated) ==
> Use cases for unauthenticated code: Same as General
> Authorization model for normal content: Explicit
> Authorization model for installed content:Implicit
> Potential mitigations:

Why can't we just let all content have access to this API by default, at
least when it is in the foreground? I really don't think we need to make
users choose whether websites can turn off their screen saver.

--BDS

Lucas Adamski

unread,

Apr 18, 2012, 8:43:47 PM4/18/12

to Benjamin Smedberg, dev-w...@lists.mozilla.org, dev-se...@lists.mozilla.org

It'd be weird for a random website to affect my chosen system settings (including screen dimming and lock/sleep). However if that content is full-screen then I think that's pretty reasonable (i.e. likely you are watching a video or otherwise more intently engaged with the content).
Lucas.

Lucas Adamski

unread,

Apr 26, 2012, 10:56:12 AM4/26/12

to dev-w...@lists.mozilla.org, dev-w...@lists.mozilla.org, dev-se...@lists.mozilla.org, dev-b2g mailing list

I haven't seen any comments on this for a while so I'll be closing this out and posting on Friday. Please send any last comments before noon PDT. Thanks!
Lucas.

On Apr 15, 2012, at 11:18 PM, Lucas Adamski wrote:

> Please reply-to dev-w...@lists.mozilla.org
>
> Name of API: Resource Lock API
> Reference: https://bugzilla.mozilla.org/show_bug.cgi?id=697132
>
> Brief purpose of API: Prevent the screen from being dimmed or switched off
> General Use Cases: Request a lock to stop the screen from being dimmed, even if the user is idle (eg. watching a movie)
>
> Inherent threats: Drain power, annoyances
>
> Threat severity: Low
>
> == Regular web content (unauthenticated) ==
> Use cases for unauthenticated code: Same as General
> Authorization model for normal content: Explicit
> Authorization model for installed content:Implicit
> Potential mitigations:
>

> == Trusted (authenticated by publisher) ==
> Use cases for authenticated code: Same as General
> Authorization model:
> Potential mitigations:
>
> == Certified (vouched for by trusted 3rd party) ==

> Use cases for certified code: Same as General
> Authorization model:
> Potential mitigations:
>

Lucas Adamski

unread,

Apr 30, 2012, 12:25:42 AM4/30/12

to dev-w...@lists.mozilla.org, dev-w...@lists.mozilla.org, dev-se...@lists.mozilla.org, dev-b2g mailing list

"Final" proposal. Please reply-to dev-w...@lists.mozilla.org with any major issues.

Name of API: Resource Lock API
Reference: https://bugzilla.mozilla.org/show_bug.cgi?id=697132

Brief purpose of API: Prevent the screen from being dimmed or switched off
General Use Cases: Request a lock to stop the screen from being dimmed, even if the user is idle (eg. watching a movie)

Inherent threats: Drain power, annoyances

Threat severity: Low

== Regular web content (unauthenticated) ==
Use cases for unauthenticated code: Same as General

Authorization model for normal content: Implicit for fullscreen only, explicit otherwise

Authorization model for installed content: Implicit
Potential mitigations:

== Trusted (authenticated by publisher) ==
Use cases for authenticated code: Same as General

Authorization model: Implicit

Potential mitigations:

== Certified (vouched for by trusted 3rd party) ==
Use cases for certified code: Same as General

Authorization model: Implicit
Potential mitigations:

Notes: It would be great if the spec also specified that the phone /needs to/should/

provide a resource consumption manager. That way concerned users could see
which trusted/certified apps are responsible for a short battery life, if

the phone is being drained too fast. [apf]

Benjamin Smedberg

unread,

May 10, 2012, 1:46:30 PM5/10/12

to dev-w...@lists.mozilla.org

On 4/30/2012 12:25 AM, Lucas Adamski wrote:
> "Final" proposal. Please reply-to dev-w...@lists.mozilla.org with any major issues.
>
> Name of API: Resource Lock API
> Reference: https://bugzilla.mozilla.org/show_bug.cgi?id=697132
>
> Brief purpose of API: Prevent the screen from being dimmed or switched off
> General Use Cases: Request a lock to stop the screen from being dimmed, even if the user is idle (eg. watching a movie)
>
> Inherent threats: Drain power, annoyances
>
> Threat severity: Low
>
> == Regular web content (unauthenticated) ==
> Use cases for unauthenticated code: Same as General
> Authorization model for normal content: Implicit for fullscreen only, explicit otherwise
> Authorization model for installed content: Implicit
> Potential mitigations:

I still believe that we should implicitly allow web content to disable
the screen saver while it is in the foreground. I'm pretty sure Flash
content is allowed to do this (I believe the netflix viewer disables the
screen saver).

--BDS

Jonas Sicking

unread,

May 10, 2012, 3:04:29 PM5/10/12

to Benjamin Smedberg, dev-w...@lists.mozilla.org

It doesn't and that's something that has annoyed me.

I agree that allowing focused pages to do this seems reasonable, but
I'm also ok with this being a prompt for now (which I believe is what
"explicit" means), it's something we can always relax in the future.

/ Jonas

Reply all

Reply to author

Forward