WebAPI Security Discussion: Resource Lock API

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

WebAPI Security Discussion: Resource Lock API

Lucas Adamski-2
Please reply-to [hidden email]

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:

_______________________________________________
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: Resource Lock API

Adrienne Porter Felt
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.

On Sun, Apr 15, 2012 at 11:18 PM, Lucas Adamski <[hidden email]>wrote:

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

Re: [b2g] WebAPI Security Discussion: Resource Lock API

Justin Lebar-3
> 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.

On Tue, Apr 17, 2012 at 12:26 AM, Adrienne Porter Felt <[hidden email]> wrote:

> 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.
>
> On Sun, Apr 15, 2012 at 11:18 PM, Lucas Adamski <[hidden email]>wrote:
>
>> Please reply-to [hidden email]
>>
>> 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:
>>
>> _______________________________________________
>> dev-security mailing list
>> [hidden email]
>> https://lists.mozilla.org/listinfo/dev-security
>>
> _______________________________________________
> dev-b2g mailing list
> [hidden email]
> https://lists.mozilla.org/listinfo/dev-b2g
_______________________________________________
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: Resource Lock API

Lucas Adamski-2
In reply to this post by Lucas Adamski-2
On Apr 17, 2012, at 6:02 AM, Benjamin Smedberg wrote:

> On 4/16/2012 2:18 AM, Lucas Adamski wrote:
> 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

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.


_______________________________________________
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: Resource Lock API

Lucas Adamski-2
In reply to this post by Lucas Adamski-2
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 [hidden email]
>
> 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:
>

_______________________________________________
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: Resource Lock API

Lucas Adamski-2
In reply to this post by Lucas Adamski-2
"Final" proposal.  Please reply-to [hidden email] 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]

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

> Please reply-to [hidden email]
>
> 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:

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