WebAPI Security Discussion: Vibration API

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

WebAPI Security Discussion: Vibration API

Lucas Adamski-2
Name of API: Vibration
Reference: http://dev.w3.org/2009/dap/vibration/

Brief purpose of API: Let content activate the vibration motor

Inherent threats: Obnoxious if mis-used, consume extra battery
Threat severity: low

== Regular web content (unauthenticated) ==
Use cases for unauthenticated code: Vibrate when hit in a game
Authorization model for uninstalled web content: Explicit
Authorization model for installed web content: Implicit
Potential mitigations: Limit how long vibrations can run

== Trusted (authenticated by publisher) ==
Use cases for authenticated code:[Same]
Authorization model: Implicit
Potential mitigations:

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

Notes:  This API may be implicitly granted.  User can deny from Permission Manager to over-ride an abusive app.

_______________________________________________
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: Vibration API

Lucas Adamski-2
Last call for comments!  So far the only feedback I have received is that it would be good to have a UI mechanism for determine which app is triggering the vibration, which sounds like a reasonable idea to me.  Thanks!
  Lucas.

On Apr 11, 2012, at 10:36 PM, Lucas Adamski wrote:

> Name of API: Vibration
> Reference: http://dev.w3.org/2009/dap/vibration/
>
> Brief purpose of API: Let content activate the vibration motor
>
> Inherent threats: Obnoxious if mis-used, consume extra battery
> Threat severity: low
>
> == Regular web content (unauthenticated) ==
> Use cases for unauthenticated code: Vibrate when hit in a game
> Authorization model for uninstalled web content: Explicit
> Authorization model for installed web content: Implicit
> Potential mitigations: Limit how long vibrations can run
>
> == Trusted (authenticated by publisher) ==
> Use cases for authenticated code:[Same]
> Authorization model: Implicit
> Potential mitigations:
>
> == Certified (vouched for by trusted 3rd party) ==
> Use cases for certified code:
> Authorization model: implicit
> Potential mitigations:
>
> Notes:  This API may be implicitly granted.  User can deny from Permission Manager to over-ride an abusive app.
>

_______________________________________________
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: Vibration API

Justin Lebar-3
> So far the only feedback I have received is that it would be good to have a UI mechanism for determine which app is triggering the vibration, which sounds like a reasonable idea to me.  Thanks!

Only foreground pages / apps can trigger vibrations via the vibrator
API.  So there is no need to expose in the UI which app is responsible
for a vibration.

Background apps will have to go through a separate notifications API
in order to frob the vibrator.

On Mon, Apr 16, 2012 at 3:55 PM, Lucas Adamski <[hidden email]> wrote:

> Last call for comments!  So far the only feedback I have received is that it would be good to have a UI mechanism for determine which app is triggering the vibration, which sounds like a reasonable idea to me.  Thanks!
>  Lucas.
>
> On Apr 11, 2012, at 10:36 PM, Lucas Adamski wrote:
>
>> Name of API: Vibration
>> Reference: http://dev.w3.org/2009/dap/vibration/
>>
>> Brief purpose of API: Let content activate the vibration motor
>>
>> Inherent threats: Obnoxious if mis-used, consume extra battery
>> Threat severity: low
>>
>> == Regular web content (unauthenticated) ==
>> Use cases for unauthenticated code: Vibrate when hit in a game
>> Authorization model for uninstalled web content: Explicit
>> Authorization model for installed web content: Implicit
>> Potential mitigations: Limit how long vibrations can run
>>
>> == Trusted (authenticated by publisher) ==
>> Use cases for authenticated code:[Same]
>> Authorization model: Implicit
>> Potential mitigations:
>>
>> == Certified (vouched for by trusted 3rd party) ==
>> Use cases for certified code:
>> Authorization model: implicit
>> Potential mitigations:
>>
>> Notes:  This API may be implicitly granted.  User can deny from Permission Manager to over-ride an abusive app.
>>
>
> _______________________________________________
> 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: [b2g] WebAPI Security Discussion: Vibration API

Devdatta Akhawe
> Background apps will have to go through a separate notifications API
> in order to frob the vibrator.

And for those, a UI mechanism for determining which app is causing the
vibration would be useful.

-dev

On 16 April 2012 00:05, Justin Lebar <[hidden email]> wrote:

> > So far the only feedback I have received is that it would be good to
> have a UI mechanism for determine which app is triggering the vibration,
> which sounds like a reasonable idea to me.  Thanks!
>
> Only foreground pages / apps can trigger vibrations via the vibrator
> API.  So there is no need to expose in the UI which app is responsible
> for a vibration.
>
> Background apps will have to go through a separate notifications API
> in order to frob the vibrator.
>
> On Mon, Apr 16, 2012 at 3:55 PM, Lucas Adamski <[hidden email]>
> wrote:
> > Last call for comments!  So far the only feedback I have received is
> that it would be good to have a UI mechanism for determine which app is
> triggering the vibration, which sounds like a reasonable idea to me.
>  Thanks!
> >  Lucas.
> >
> > On Apr 11, 2012, at 10:36 PM, Lucas Adamski wrote:
> >
> >> Name of API: Vibration
> >> Reference: http://dev.w3.org/2009/dap/vibration/
> >>
> >> Brief purpose of API: Let content activate the vibration motor
> >>
> >> Inherent threats: Obnoxious if mis-used, consume extra battery
> >> Threat severity: low
> >>
> >> == Regular web content (unauthenticated) ==
> >> Use cases for unauthenticated code: Vibrate when hit in a game
> >> Authorization model for uninstalled web content: Explicit
> >> Authorization model for installed web content: Implicit
> >> Potential mitigations: Limit how long vibrations can run
> >>
> >> == Trusted (authenticated by publisher) ==
> >> Use cases for authenticated code:[Same]
> >> Authorization model: Implicit
> >> Potential mitigations:
> >>
> >> == Certified (vouched for by trusted 3rd party) ==
> >> Use cases for certified code:
> >> Authorization model: implicit
> >> Potential mitigations:
> >>
> >> Notes:  This API may be implicitly granted.  User can deny from
> Permission Manager to over-ride an abusive app.
> >>
> >
> > _______________________________________________
> > 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
>
_______________________________________________
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: Vibration API

Mike Habicher

----- Original Message -----

> From: "Devdatta Akhawe" <[hidden email]>
> To: "Justin Lebar" <[hidden email]>
> Cc: [hidden email], [hidden email], [hidden email], "Lucas Adamski"
> <[hidden email]>, "dev-b2g mailing list" <[hidden email]>
> Sent: Monday, 16 April, 2012 10:36:52 AM
> Subject: Re: [b2g] WebAPI Security Discussion: Vibration API
>
> > Background apps will have to go through a separate notifications
> > API
> > in order to frob the vibrator.
>
> And for those, a UI mechanism for determining which app is causing
> the
> vibration would be useful.

And whenever the notifications API comes up for discussion, it would be good to keep in mind that just because an app requests a notification doesn't mean it will get it.  The user preference (audible, vibrate, none) should (must?) always take precedence.  Note that 'vibrate' is not the opposite of 'audible'--sometimes you want no notifications at all.

--m.


> -dev
>
> On 16 April 2012 00:05, Justin Lebar <[hidden email]> wrote:
>
> > > So far the only feedback I have received is that it would be good
> > > to
> > have a UI mechanism for determine which app is triggering the
> > vibration,
> > which sounds like a reasonable idea to me.  Thanks!
> >
> > Only foreground pages / apps can trigger vibrations via the
> > vibrator
> > API.  So there is no need to expose in the UI which app is
> > responsible
> > for a vibration.
> >
> > Background apps will have to go through a separate notifications
> > API
> > in order to frob the vibrator.
> >
> > On Mon, Apr 16, 2012 at 3:55 PM, Lucas Adamski
> > <[hidden email]>
> > wrote:
> > > Last call for comments!  So far the only feedback I have received
> > > is
> > that it would be good to have a UI mechanism for determine which
> > app is
> > triggering the vibration, which sounds like a reasonable idea to
> > me.
> >  Thanks!
> > >  Lucas.
> > >
> > > On Apr 11, 2012, at 10:36 PM, Lucas Adamski wrote:
> > >
> > >> Name of API: Vibration
> > >> Reference: http://dev.w3.org/2009/dap/vibration/
> > >>
> > >> Brief purpose of API: Let content activate the vibration motor
> > >>
> > >> Inherent threats: Obnoxious if mis-used, consume extra battery
> > >> Threat severity: low
> > >>
> > >> == Regular web content (unauthenticated) ==
> > >> Use cases for unauthenticated code: Vibrate when hit in a game
> > >> Authorization model for uninstalled web content: Explicit
> > >> Authorization model for installed web content: Implicit
> > >> Potential mitigations: Limit how long vibrations can run
> > >>
> > >> == Trusted (authenticated by publisher) ==
> > >> Use cases for authenticated code:[Same]
> > >> Authorization model: Implicit
> > >> Potential mitigations:
> > >>
> > >> == Certified (vouched for by trusted 3rd party) ==
> > >> Use cases for certified code:
> > >> Authorization model: implicit
> > >> Potential mitigations:
> > >>
> > >> Notes:  This API may be implicitly granted.  User can deny from
> > Permission Manager to over-ride an abusive app.
> > >>
> > >
> > > _______________________________________________
> > > 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
> >
> _______________________________________________
> 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: Vibration API

Lucas Adamski-2
In reply to this post by Lucas Adamski-2
Updated proposal.  Note that since only foreground content can trigger vibrator, this seems equivalent to other potentially annoying feedback mechanisms and should be implicit for uninstalled web content… thoughts?

Name of API: Vibration
Reference: http://dev.w3.org/2009/dap/vibration/

Brief purpose of API: Let content activate the vibration motor

Inherent threats: Obnoxious if mis-used, consume extra battery
Threat severity: low

== Regular web content (unauthenticated) ==
Use cases for unauthenticated code: Vibrate when hit in a game
Authorization model for uninstalled web content: Implicit
Authorization model for installed web content: Implicit
Potential mitigations: Limit how long vibrations can run.  Only foreground content can trigger vibration.

== Trusted (authenticated by publisher) ==
Use cases for authenticated code:[Same]
Authorization model: Implicit
Potential mitigations:

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

Notes:  This API may be implicitly granted.  User can deny from Permission Manager to over-ride an abusive app.

On Apr 11, 2012, at 10:36 PM, Lucas Adamski wrote:

> Name of API: Vibration
> Reference: http://dev.w3.org/2009/dap/vibration/
>
> Brief purpose of API: Let content activate the vibration motor
>
> Inherent threats: Obnoxious if mis-used, consume extra battery
> Threat severity: low
>
> == Regular web content (unauthenticated) ==
> Use cases for unauthenticated code: Vibrate when hit in a game
> Authorization model for uninstalled web content: Explicit
> Authorization model for installed web content: Implicit
> Potential mitigations: Limit how long vibrations can run
>
> == Trusted (authenticated by publisher) ==
> Use cases for authenticated code:[Same]
> Authorization model: Implicit
> Potential mitigations:
>
> == Certified (vouched for by trusted 3rd party) ==
> Use cases for certified code:
> Authorization model: implicit
> Potential mitigations:
>
> Notes:  This API may be implicitly granted.  User can deny from Permission Manager to over-ride an abusive app.

_______________________________________________
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: Vibration API

Adrienne Porter Felt
Could it be limited to both foreground content that is the top level
window?  That way ads in iframes won't be able to annoy the user as much
(and websites can ensure that ads won't be annoying by putting them in
frames).

On Thu, Apr 19, 2012 at 3:44 AM, Lucas Adamski <[hidden email]> wrote:

> Updated proposal.  Note that since only foreground content can trigger
> vibrator, this seems equivalent to other potentially annoying feedback
> mechanisms and should be implicit for uninstalled web content… thoughts?
>
> Name of API: Vibration
> Reference: http://dev.w3.org/2009/dap/vibration/
>
> Brief purpose of API: Let content activate the vibration motor
>
> Inherent threats: Obnoxious if mis-used, consume extra battery
> Threat severity: low
>
> == Regular web content (unauthenticated) ==
> Use cases for unauthenticated code: Vibrate when hit in a game
> Authorization model for uninstalled web content: Implicit
> Authorization model for installed web content: Implicit
> Potential mitigations: Limit how long vibrations can run.  Only foreground
> content can trigger vibration.
>
> == Trusted (authenticated by publisher) ==
> Use cases for authenticated code:[Same]
> Authorization model: Implicit
> Potential mitigations:
>
> == Certified (vouched for by trusted 3rd party) ==
> Use cases for certified code:
> Authorization model: Implicit
> Potential mitigations:
>
> Notes:  This API may be implicitly granted.  User can deny from Permission
> Manager to over-ride an abusive app.
>
> On Apr 11, 2012, at 10:36 PM, Lucas Adamski wrote:
>
> > Name of API: Vibration
> > Reference: http://dev.w3.org/2009/dap/vibration/
> >
> > Brief purpose of API: Let content activate the vibration motor
> >
> > Inherent threats: Obnoxious if mis-used, consume extra battery
> > Threat severity: low
> >
> > == Regular web content (unauthenticated) ==
> > Use cases for unauthenticated code: Vibrate when hit in a game
> > Authorization model for uninstalled web content: Explicit
> > Authorization model for installed web content: Implicit
> > Potential mitigations: Limit how long vibrations can run
> >
> > == Trusted (authenticated by publisher) ==
> > Use cases for authenticated code:[Same]
> > Authorization model: Implicit
> > Potential mitigations:
> >
> > == Certified (vouched for by trusted 3rd party) ==
> > Use cases for certified code:
> > Authorization model: implicit
> > Potential mitigations:
> >
> > Notes:  This API may be implicitly granted.  User can deny from
> Permission Manager to over-ride an abusive app.
>
> _______________________________________________
> dev-webapi mailing list
> [hidden email]
> https://lists.mozilla.org/listinfo/dev-webapi
>
_______________________________________________
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: Vibration API

Chris Lee-21
In reply to this post by Lucas Adamski-2

On Apr 18, 2012, at 6:44 PM, Lucas Adamski wrote:

> Updated proposal.  Note that since only foreground content can trigger vibrator, this seems equivalent to other potentially annoying feedback mechanisms and should be implicit for uninstalled web content… thoughts?

I didn't see this called out, but how do we think about vibration triggers for the notification use case from SMS/3rd party apps?

Chris
_______________________________________________
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: Vibration API

Justin Lebar-3
In reply to this post by Adrienne Porter Felt
> I didn't see this called out, but how do we think about vibration triggers for the notification use case from SMS/3rd party apps?

We think about this as a completely separate "notifications" API.

This API is separate because it may not directly let pages frob the
vibrator -- if I've globally disabled sound and vibrating
notifications, then a background SMS app shouldn't be able to ring or
vibrate the phone.

> Could it be limited to both foreground content that is the top level
> window?  That way ads in iframes won't be able to annoy the user as much
> (and websites can ensure that ads won't be annoying by putting them in
> frames).

I can't think of a precedent for this kind of thing.  If there is a
precedent, then I might be OK applying it here.

On Thu, Apr 19, 2012 at 2:32 PM, Adrienne Porter Felt <[hidden email]> wrote:

> Could it be limited to both foreground content that is the top level
> window?  That way ads in iframes won't be able to annoy the user as much
> (and websites can ensure that ads won't be annoying by putting them in
> frames).
>
> On Thu, Apr 19, 2012 at 3:44 AM, Lucas Adamski <[hidden email]> wrote:
>
>> Updated proposal.  Note that since only foreground content can trigger
>> vibrator, this seems equivalent to other potentially annoying feedback
>> mechanisms and should be implicit for uninstalled web content… thoughts?
>>
>> Name of API: Vibration
>> Reference: http://dev.w3.org/2009/dap/vibration/
>>
>> Brief purpose of API: Let content activate the vibration motor
>>
>> Inherent threats: Obnoxious if mis-used, consume extra battery
>> Threat severity: low
>>
>> == Regular web content (unauthenticated) ==
>> Use cases for unauthenticated code: Vibrate when hit in a game
>> Authorization model for uninstalled web content: Implicit
>> Authorization model for installed web content: Implicit
>> Potential mitigations: Limit how long vibrations can run.  Only foreground
>> content can trigger vibration.
>>
>> == Trusted (authenticated by publisher) ==
>> Use cases for authenticated code:[Same]
>> Authorization model: Implicit
>> Potential mitigations:
>>
>> == Certified (vouched for by trusted 3rd party) ==
>> Use cases for certified code:
>> Authorization model: Implicit
>> Potential mitigations:
>>
>> Notes:  This API may be implicitly granted.  User can deny from Permission
>> Manager to over-ride an abusive app.
>>
>> On Apr 11, 2012, at 10:36 PM, Lucas Adamski wrote:
>>
>> > Name of API: Vibration
>> > Reference: http://dev.w3.org/2009/dap/vibration/
>> >
>> > Brief purpose of API: Let content activate the vibration motor
>> >
>> > Inherent threats: Obnoxious if mis-used, consume extra battery
>> > Threat severity: low
>> >
>> > == Regular web content (unauthenticated) ==
>> > Use cases for unauthenticated code: Vibrate when hit in a game
>> > Authorization model for uninstalled web content: Explicit
>> > Authorization model for installed web content: Implicit
>> > Potential mitigations: Limit how long vibrations can run
>> >
>> > == Trusted (authenticated by publisher) ==
>> > Use cases for authenticated code:[Same]
>> > Authorization model: Implicit
>> > Potential mitigations:
>> >
>> > == Certified (vouched for by trusted 3rd party) ==
>> > Use cases for certified code:
>> > Authorization model: implicit
>> > Potential mitigations:
>> >
>> > Notes:  This API may be implicitly granted.  User can deny from
>> Permission Manager to over-ride an abusive app.
>>
>> _______________________________________________
>> dev-webapi mailing list
>> [hidden email]
>> https://lists.mozilla.org/listinfo/dev-webapi
>>
> _______________________________________________
> 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: [b2g] WebAPI Security Discussion: Vibration API

Lucas Adamski-2
On Apr 18, 2012, at 10:29 PM, Justin Lebar wrote:
>> Could it be limited to both foreground content that is the top level
>> window?  That way ads in iframes won't be able to annoy the user as much
>> (and websites can ensure that ads won't be annoying by putting them in
>> frames).
>
> I can't think of a precedent for this kind of thing.  If there is a
> precedent, then I might be OK applying it here.

I think the precedent is being set in the orientation API, which has faced a similar set of (annoyance) concerns and come to a similar conclusion.
  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: Vibration API

JOSE MANUEL CANTERA FONSECA
In reply to this post by Lucas Adamski-2
Is there any special risk on allowing any kind of unauthenticated content
to request vibration without any permission request?

Thanks, best

El 16/04/12 07:55, "Lucas Adamski" <[hidden email]> escribió:

>Last call for comments!  So far the only feedback I have received is that
>it would be good to have a UI mechanism for determine which app is
>triggering the vibration, which sounds like a reasonable idea to me.
>Thanks!
>  Lucas.
>
>On Apr 11, 2012, at 10:36 PM, Lucas Adamski wrote:
>
>> Name of API: Vibration
>> Reference: http://dev.w3.org/2009/dap/vibration/
>>
>> Brief purpose of API: Let content activate the vibration motor
>>
>> Inherent threats: Obnoxious if mis-used, consume extra battery
>> Threat severity: low
>>
>> == Regular web content (unauthenticated) ==
>> Use cases for unauthenticated code: Vibrate when hit in a game
>> Authorization model for uninstalled web content: Explicit
>> Authorization model for installed web content: Implicit
>> Potential mitigations: Limit how long vibrations can run
>>
>> == Trusted (authenticated by publisher) ==
>> Use cases for authenticated code:[Same]
>> Authorization model: Implicit
>> Potential mitigations:
>>
>> == Certified (vouched for by trusted 3rd party) ==
>> Use cases for certified code:
>> Authorization model: implicit
>> Potential mitigations:
>>
>> Notes:  This API may be implicitly granted.  User can deny from
>>Permission Manager to over-ride an abusive app.
>>
>
>_______________________________________________
>dev-webapps mailing list
>[hidden email]
>https://lists.mozilla.org/listinfo/dev-webapps
>



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: Vibration API

Devdatta Akhawe
On 19 April 2012 11:31, JOSE MANUEL CANTERA FONSECA <[hidden email]> wrote:
> Is there any special risk on allowing any kind of unauthenticated content
> to request vibration without any permission request?
>

It will be an annoyance yes, but I don't see any security risk other
than Denial of Service.  I think of it similar to how websites could
window.alert in an infinite loop. It makes more sense to take the hit
for Denial of Service risk, than to annoy users with permission
dialogs.

=dev

On 19 April 2012 11:31, JOSE MANUEL CANTERA FONSECA <[hidden email]> wrote:

> Is there any special risk on allowing any kind of unauthenticated content
> to request vibration without any permission request?
>
> Thanks, best
>
> El 16/04/12 07:55, "Lucas Adamski" <[hidden email]> escribió:
>
>>Last call for comments!  So far the only feedback I have received is that
>>it would be good to have a UI mechanism for determine which app is
>>triggering the vibration, which sounds like a reasonable idea to me.
>>Thanks!
>>  Lucas.
>>
>>On Apr 11, 2012, at 10:36 PM, Lucas Adamski wrote:
>>
>>> Name of API: Vibration
>>> Reference: http://dev.w3.org/2009/dap/vibration/
>>>
>>> Brief purpose of API: Let content activate the vibration motor
>>>
>>> Inherent threats: Obnoxious if mis-used, consume extra battery
>>> Threat severity: low
>>>
>>> == Regular web content (unauthenticated) ==
>>> Use cases for unauthenticated code: Vibrate when hit in a game
>>> Authorization model for uninstalled web content: Explicit
>>> Authorization model for installed web content: Implicit
>>> Potential mitigations: Limit how long vibrations can run
>>>
>>> == Trusted (authenticated by publisher) ==
>>> Use cases for authenticated code:[Same]
>>> Authorization model: Implicit
>>> Potential mitigations:
>>>
>>> == Certified (vouched for by trusted 3rd party) ==
>>> Use cases for certified code:
>>> Authorization model: implicit
>>> Potential mitigations:
>>>
>>> Notes:  This API may be implicitly granted.  User can deny from
>>>Permission Manager to over-ride an abusive app.
>>>
>>
>>_______________________________________________
>>dev-webapps mailing list
>>[hidden email]
>>https://lists.mozilla.org/listinfo/dev-webapps
>>
>
>
>
> 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
_______________________________________________
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: Vibration API

JOSE MANUEL CANTERA FONSECA
El 19/04/12 23:21, "Devdatta Akhawe" <[hidden email]> escribió:

>On 19 April 2012 11:31, JOSE MANUEL CANTERA FONSECA <[hidden email]> wrote:
>> Is there any special risk on allowing any kind of unauthenticated
>>content
>> to request vibration without any permission request?
>>
>
>It will be an annoyance yes, but I don't see any security risk other
>than Denial of Service.  I think of it similar to how websites could
>window.alert in an infinite loop. It makes more sense to take the hit
>for Denial of Service risk, than to annoy users with permission
>dialogs.

Maybe the API implementation itself can limit the number of vibration
requests made by a page in a period of time ...

>
>=dev
>
>On 19 April 2012 11:31, JOSE MANUEL CANTERA FONSECA <[hidden email]> wrote:
>> Is there any special risk on allowing any kind of unauthenticated
>>content
>> to request vibration without any permission request?
>>
>> Thanks, best
>>
>> El 16/04/12 07:55, "Lucas Adamski" <[hidden email]> escribió:
>>
>>>Last call for comments!  So far the only feedback I have received is
>>>that
>>>it would be good to have a UI mechanism for determine which app is
>>>triggering the vibration, which sounds like a reasonable idea to me.
>>>Thanks!
>>>  Lucas.
>>>
>>>On Apr 11, 2012, at 10:36 PM, Lucas Adamski wrote:
>>>
>>>> Name of API: Vibration
>>>> Reference: http://dev.w3.org/2009/dap/vibration/
>>>>
>>>> Brief purpose of API: Let content activate the vibration motor
>>>>
>>>> Inherent threats: Obnoxious if mis-used, consume extra battery
>>>> Threat severity: low
>>>>
>>>> == Regular web content (unauthenticated) ==
>>>> Use cases for unauthenticated code: Vibrate when hit in a game
>>>> Authorization model for uninstalled web content: Explicit
>>>> Authorization model for installed web content: Implicit
>>>> Potential mitigations: Limit how long vibrations can run
>>>>
>>>> == Trusted (authenticated by publisher) ==
>>>> Use cases for authenticated code:[Same]
>>>> Authorization model: Implicit
>>>> Potential mitigations:
>>>>
>>>> == Certified (vouched for by trusted 3rd party) ==
>>>> Use cases for certified code:
>>>> Authorization model: implicit
>>>> Potential mitigations:
>>>>
>>>> Notes:  This API may be implicitly granted.  User can deny from
>>>>Permission Manager to over-ride an abusive app.
>>>>
>>>
>>>_______________________________________________
>>>dev-webapps mailing list
>>>[hidden email]
>>>https://lists.mozilla.org/listinfo/dev-webapps
>>>
>>
>>
>>
>> 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
>



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: Vibration API

Justin Lebar-3
> Maybe the API implementation itself can limit the number of vibration
> requests made by a page in a period of time ...

I don't know how to do this in a way which wouldn't mess up e.g. a
game which uses the vibrator all the time.  In general, heuristics
like this are hard.  :-/

>>On 19 April 2012 11:31, JOSE MANUEL CANTERA FONSECA <[hidden email]> wrote:
>>> Is there any special risk on allowing any kind of unauthenticated
>>>content
>>> to request vibration without any permission request?
>>>
>>> Thanks, best
>>>
>>> El 16/04/12 07:55, "Lucas Adamski" <[hidden email]> escribió:
>>>
>>>>Last call for comments!  So far the only feedback I have received is
>>>>that
>>>>it would be good to have a UI mechanism for determine which app is
>>>>triggering the vibration, which sounds like a reasonable idea to me.
>>>>Thanks!
>>>>  Lucas.
>>>>
>>>>On Apr 11, 2012, at 10:36 PM, Lucas Adamski wrote:
>>>>
>>>>> Name of API: Vibration
>>>>> Reference: http://dev.w3.org/2009/dap/vibration/
>>>>>
>>>>> Brief purpose of API: Let content activate the vibration motor
>>>>>
>>>>> Inherent threats: Obnoxious if mis-used, consume extra battery
>>>>> Threat severity: low
>>>>>
>>>>> == Regular web content (unauthenticated) ==
>>>>> Use cases for unauthenticated code: Vibrate when hit in a game
>>>>> Authorization model for uninstalled web content: Explicit
>>>>> Authorization model for installed web content: Implicit
>>>>> Potential mitigations: Limit how long vibrations can run
>>>>>
>>>>> == Trusted (authenticated by publisher) ==
>>>>> Use cases for authenticated code:[Same]
>>>>> Authorization model: Implicit
>>>>> Potential mitigations:
>>>>>
>>>>> == Certified (vouched for by trusted 3rd party) ==
>>>>> Use cases for certified code:
>>>>> Authorization model: implicit
>>>>> Potential mitigations:
>>>>>
>>>>> Notes:  This API may be implicitly granted.  User can deny from
>>>>>Permission Manager to over-ride an abusive app.
>>>>>
>>>>
>>>>_______________________________________________
>>>>dev-webapps mailing list
>>>>[hidden email]
>>>>https://lists.mozilla.org/listinfo/dev-webapps
>>>>
>>>
>>>
>>>
>>> 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
>>
>
>
>
> 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-webapi mailing list
> [hidden email]
> https://lists.mozilla.org/listinfo/dev-webapi
_______________________________________________
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: Vibration API

Adrienne Porter Felt
Surely there are limits as to what even a game wants to do with a vibrator
-- I doubt a game is going to want to constantly vibrate the phone for 20
solid minutes.  Since that is the case, there must be a threshold.

On Fri, Apr 20, 2012 at 1:12 AM, Justin Lebar <[hidden email]>wrote:

> > Maybe the API implementation itself can limit the number of vibration
> > requests made by a page in a period of time ...
>
> I don't know how to do this in a way which wouldn't mess up e.g. a
> game which uses the vibrator all the time.  In general, heuristics
> like this are hard.  :-/
>
> >>On 19 April 2012 11:31, JOSE MANUEL CANTERA FONSECA <[hidden email]> wrote:
> >>> Is there any special risk on allowing any kind of unauthenticated
> >>>content
> >>> to request vibration without any permission request?
> >>>
> >>> Thanks, best
> >>>
> >>> El 16/04/12 07:55, "Lucas Adamski" <[hidden email]> escribió:
> >>>
> >>>>Last call for comments!  So far the only feedback I have received is
> >>>>that
> >>>>it would be good to have a UI mechanism for determine which app is
> >>>>triggering the vibration, which sounds like a reasonable idea to me.
> >>>>Thanks!
> >>>>  Lucas.
> >>>>
> >>>>On Apr 11, 2012, at 10:36 PM, Lucas Adamski wrote:
> >>>>
> >>>>> Name of API: Vibration
> >>>>> Reference: http://dev.w3.org/2009/dap/vibration/
> >>>>>
> >>>>> Brief purpose of API: Let content activate the vibration motor
> >>>>>
> >>>>> Inherent threats: Obnoxious if mis-used, consume extra battery
> >>>>> Threat severity: low
> >>>>>
> >>>>> == Regular web content (unauthenticated) ==
> >>>>> Use cases for unauthenticated code: Vibrate when hit in a game
> >>>>> Authorization model for uninstalled web content: Explicit
> >>>>> Authorization model for installed web content: Implicit
> >>>>> Potential mitigations: Limit how long vibrations can run
> >>>>>
> >>>>> == Trusted (authenticated by publisher) ==
> >>>>> Use cases for authenticated code:[Same]
> >>>>> Authorization model: Implicit
> >>>>> Potential mitigations:
> >>>>>
> >>>>> == Certified (vouched for by trusted 3rd party) ==
> >>>>> Use cases for certified code:
> >>>>> Authorization model: implicit
> >>>>> Potential mitigations:
> >>>>>
> >>>>> Notes:  This API may be implicitly granted.  User can deny from
> >>>>>Permission Manager to over-ride an abusive app.
> >>>>>
> >>>>
> >>>>_______________________________________________
> >>>>dev-webapps mailing list
> >>>>[hidden email]
> >>>>https://lists.mozilla.org/listinfo/dev-webapps
> >>>>
> >>>
> >>>
> >>>
> >>> 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
> >>
> >
> >
> >
> > 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-webapi mailing list
> > [hidden email]
> > https://lists.mozilla.org/listinfo/dev-webapi
> _______________________________________________
> dev-webapi mailing list
> [hidden email]
> https://lists.mozilla.org/listinfo/dev-webapi
>
_______________________________________________
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: Vibration API

Justin Lebar-3
On Fri, Apr 20, 2012 at 9:33 AM, Adrienne Porter Felt <[hidden email]> wrote:
> Surely there are limits as to what even a game wants to do with a vibrator
> -- I doubt a game is going to want to constantly vibrate the phone for 20
> solid minutes.  Since that is the case, there must be a threshold.

Sure, but if we set the threshold at 20 minutes of continuous
vibration, we haven't accomplished very much in terms of avoiding user
annoyance.

> On Fri, Apr 20, 2012 at 1:12 AM, Justin Lebar <[hidden email]>
> wrote:
>>
>> > Maybe the API implementation itself can limit the number of vibration
>> > requests made by a page in a period of time ...
>>
>> I don't know how to do this in a way which wouldn't mess up e.g. a
>> game which uses the vibrator all the time.  In general, heuristics
>> like this are hard.  :-/
>>
>> >>On 19 April 2012 11:31, JOSE MANUEL CANTERA FONSECA <[hidden email]> wrote:
>> >>> Is there any special risk on allowing any kind of unauthenticated
>> >>>content
>> >>> to request vibration without any permission request?
>> >>>
>> >>> Thanks, best
>> >>>
>> >>> El 16/04/12 07:55, "Lucas Adamski" <[hidden email]> escribió:
>> >>>
>> >>>>Last call for comments!  So far the only feedback I have received is
>> >>>>that
>> >>>>it would be good to have a UI mechanism for determine which app is
>> >>>>triggering the vibration, which sounds like a reasonable idea to me.
>> >>>>Thanks!
>> >>>>  Lucas.
>> >>>>
>> >>>>On Apr 11, 2012, at 10:36 PM, Lucas Adamski wrote:
>> >>>>
>> >>>>> Name of API: Vibration
>> >>>>> Reference: http://dev.w3.org/2009/dap/vibration/
>> >>>>>
>> >>>>> Brief purpose of API: Let content activate the vibration motor
>> >>>>>
>> >>>>> Inherent threats: Obnoxious if mis-used, consume extra battery
>> >>>>> Threat severity: low
>> >>>>>
>> >>>>> == Regular web content (unauthenticated) ==
>> >>>>> Use cases for unauthenticated code: Vibrate when hit in a game
>> >>>>> Authorization model for uninstalled web content: Explicit
>> >>>>> Authorization model for installed web content: Implicit
>> >>>>> Potential mitigations: Limit how long vibrations can run
>> >>>>>
>> >>>>> == Trusted (authenticated by publisher) ==
>> >>>>> Use cases for authenticated code:[Same]
>> >>>>> Authorization model: Implicit
>> >>>>> Potential mitigations:
>> >>>>>
>> >>>>> == Certified (vouched for by trusted 3rd party) ==
>> >>>>> Use cases for certified code:
>> >>>>> Authorization model: implicit
>> >>>>> Potential mitigations:
>> >>>>>
>> >>>>> Notes:  This API may be implicitly granted.  User can deny from
>> >>>>>Permission Manager to over-ride an abusive app.
>> >>>>>
>> >>>>
>> >>>>_______________________________________________
>> >>>>dev-webapps mailing list
>> >>>>[hidden email]
>> >>>>https://lists.mozilla.org/listinfo/dev-webapps
>> >>>>
>> >>>
>> >>>
>> >>>
>> >>> 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
>> >>
>> >
>> >
>> >
>> > 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-webapi mailing list
>> > [hidden email]
>> > https://lists.mozilla.org/listinfo/dev-webapi
>> _______________________________________________
>> dev-webapi mailing list
>> [hidden email]
>> https://lists.mozilla.org/listinfo/dev-webapi
>
>
_______________________________________________
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: Vibration API

Adrienne Porter Felt
I wasn't suggesting that the threshold is 20 minutes. Instead, my comment
is that 20 minutes is clearly above the threshold, so this is evidence that
there must be *some* reasonable threshold that won't break many games.
 30sec? 20sec?  10sec?  3sec?  This could probably be resolved with a
rather fun short survey of games.

On Fri, Apr 20, 2012 at 1:44 AM, Justin Lebar <[hidden email]>wrote:

> On Fri, Apr 20, 2012 at 9:33 AM, Adrienne Porter Felt <[hidden email]>
> wrote:
> > Surely there are limits as to what even a game wants to do with a
> vibrator
> > -- I doubt a game is going to want to constantly vibrate the phone for 20
> > solid minutes.  Since that is the case, there must be a threshold.
>
> Sure, but if we set the threshold at 20 minutes of continuous
> vibration, we haven't accomplished very much in terms of avoiding user
> annoyance.
>
> > On Fri, Apr 20, 2012 at 1:12 AM, Justin Lebar <[hidden email]>
> > wrote:
> >>
> >> > Maybe the API implementation itself can limit the number of vibration
> >> > requests made by a page in a period of time ...
> >>
> >> I don't know how to do this in a way which wouldn't mess up e.g. a
> >> game which uses the vibrator all the time.  In general, heuristics
> >> like this are hard.  :-/
> >>
> >> >>On 19 April 2012 11:31, JOSE MANUEL CANTERA FONSECA <[hidden email]>
> wrote:
> >> >>> Is there any special risk on allowing any kind of unauthenticated
> >> >>>content
> >> >>> to request vibration without any permission request?
> >> >>>
> >> >>> Thanks, best
> >> >>>
> >> >>> El 16/04/12 07:55, "Lucas Adamski" <[hidden email]> escribió:
> >> >>>
> >> >>>>Last call for comments!  So far the only feedback I have received is
> >> >>>>that
> >> >>>>it would be good to have a UI mechanism for determine which app is
> >> >>>>triggering the vibration, which sounds like a reasonable idea to me.
> >> >>>>Thanks!
> >> >>>>  Lucas.
> >> >>>>
> >> >>>>On Apr 11, 2012, at 10:36 PM, Lucas Adamski wrote:
> >> >>>>
> >> >>>>> Name of API: Vibration
> >> >>>>> Reference: http://dev.w3.org/2009/dap/vibration/
> >> >>>>>
> >> >>>>> Brief purpose of API: Let content activate the vibration motor
> >> >>>>>
> >> >>>>> Inherent threats: Obnoxious if mis-used, consume extra battery
> >> >>>>> Threat severity: low
> >> >>>>>
> >> >>>>> == Regular web content (unauthenticated) ==
> >> >>>>> Use cases for unauthenticated code: Vibrate when hit in a game
> >> >>>>> Authorization model for uninstalled web content: Explicit
> >> >>>>> Authorization model for installed web content: Implicit
> >> >>>>> Potential mitigations: Limit how long vibrations can run
> >> >>>>>
> >> >>>>> == Trusted (authenticated by publisher) ==
> >> >>>>> Use cases for authenticated code:[Same]
> >> >>>>> Authorization model: Implicit
> >> >>>>> Potential mitigations:
> >> >>>>>
> >> >>>>> == Certified (vouched for by trusted 3rd party) ==
> >> >>>>> Use cases for certified code:
> >> >>>>> Authorization model: implicit
> >> >>>>> Potential mitigations:
> >> >>>>>
> >> >>>>> Notes:  This API may be implicitly granted.  User can deny from
> >> >>>>>Permission Manager to over-ride an abusive app.
> >> >>>>>
> >> >>>>
> >> >>>>_______________________________________________
> >> >>>>dev-webapps mailing list
> >> >>>>[hidden email]
> >> >>>>https://lists.mozilla.org/listinfo/dev-webapps
> >> >>>>
> >> >>>
> >> >>>
> >> >>>
> >> >>> 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
> >> >>
> >> >
> >> >
> >> >
> >> > 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-webapi mailing list
> >> > [hidden email]
> >> > https://lists.mozilla.org/listinfo/dev-webapi
> >> _______________________________________________
> >> dev-webapi mailing list
> >> [hidden email]
> >> https://lists.mozilla.org/listinfo/dev-webapi
> >
> >
>
_______________________________________________
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: Vibration API

Justin Lebar-3
On Fri, Apr 20, 2012 at 9:47 AM, Adrienne Porter Felt <[hidden email]> wrote:
> I wasn't suggesting that the threshold is 20 minutes. Instead, my comment is
> that 20 minutes is clearly above the threshold, so this is evidence that
> there must be *some* reasonable threshold that won't break many games.
>  30sec? 20sec?  10sec?  3sec?  This could probably be resolved with a rather
> fun short survey of games.

So suppose 10s of continuous vibration is more than enough for any
existing, and, we presume, future, game.  So we stopped all vibrations
after 10s.

That still wouldn't prevent an annoying page from doing an infinite
loop of 9.99s vibrations.

So we'd have to enforce a gap between these vibrations.  And at that
point, we start getting into non-trivial heuristics, it seems to me.

> On Fri, Apr 20, 2012 at 1:44 AM, Justin Lebar <[hidden email]>
> wrote:
>>
>> On Fri, Apr 20, 2012 at 9:33 AM, Adrienne Porter Felt <[hidden email]>
>> wrote:
>> > Surely there are limits as to what even a game wants to do with a
>> > vibrator
>> > -- I doubt a game is going to want to constantly vibrate the phone for
>> > 20
>> > solid minutes.  Since that is the case, there must be a threshold.
>>
>> Sure, but if we set the threshold at 20 minutes of continuous
>> vibration, we haven't accomplished very much in terms of avoiding user
>> annoyance.
>>
>> > On Fri, Apr 20, 2012 at 1:12 AM, Justin Lebar <[hidden email]>
>> > wrote:
>> >>
>> >> > Maybe the API implementation itself can limit the number of vibration
>> >> > requests made by a page in a period of time ...
>> >>
>> >> I don't know how to do this in a way which wouldn't mess up e.g. a
>> >> game which uses the vibrator all the time.  In general, heuristics
>> >> like this are hard.  :-/
>> >>
>> >> >>On 19 April 2012 11:31, JOSE MANUEL CANTERA FONSECA <[hidden email]>
>> >> >> wrote:
>> >> >>> Is there any special risk on allowing any kind of unauthenticated
>> >> >>>content
>> >> >>> to request vibration without any permission request?
>> >> >>>
>> >> >>> Thanks, best
>> >> >>>
>> >> >>> El 16/04/12 07:55, "Lucas Adamski" <[hidden email]> escribió:
>> >> >>>
>> >> >>>>Last call for comments!  So far the only feedback I have received
>> >> >>>> is
>> >> >>>>that
>> >> >>>>it would be good to have a UI mechanism for determine which app is
>> >> >>>>triggering the vibration, which sounds like a reasonable idea to
>> >> >>>> me.
>> >> >>>>Thanks!
>> >> >>>>  Lucas.
>> >> >>>>
>> >> >>>>On Apr 11, 2012, at 10:36 PM, Lucas Adamski wrote:
>> >> >>>>
>> >> >>>>> Name of API: Vibration
>> >> >>>>> Reference: http://dev.w3.org/2009/dap/vibration/
>> >> >>>>>
>> >> >>>>> Brief purpose of API: Let content activate the vibration motor
>> >> >>>>>
>> >> >>>>> Inherent threats: Obnoxious if mis-used, consume extra battery
>> >> >>>>> Threat severity: low
>> >> >>>>>
>> >> >>>>> == Regular web content (unauthenticated) ==
>> >> >>>>> Use cases for unauthenticated code: Vibrate when hit in a game
>> >> >>>>> Authorization model for uninstalled web content: Explicit
>> >> >>>>> Authorization model for installed web content: Implicit
>> >> >>>>> Potential mitigations: Limit how long vibrations can run
>> >> >>>>>
>> >> >>>>> == Trusted (authenticated by publisher) ==
>> >> >>>>> Use cases for authenticated code:[Same]
>> >> >>>>> Authorization model: Implicit
>> >> >>>>> Potential mitigations:
>> >> >>>>>
>> >> >>>>> == Certified (vouched for by trusted 3rd party) ==
>> >> >>>>> Use cases for certified code:
>> >> >>>>> Authorization model: implicit
>> >> >>>>> Potential mitigations:
>> >> >>>>>
>> >> >>>>> Notes:  This API may be implicitly granted.  User can deny from
>> >> >>>>>Permission Manager to over-ride an abusive app.
>> >> >>>>>
>> >> >>>>
>> >> >>>>_______________________________________________
>> >> >>>>dev-webapps mailing list
>> >> >>>>[hidden email]
>> >> >>>>https://lists.mozilla.org/listinfo/dev-webapps
>> >> >>>>
>> >> >>>
>> >> >>>
>> >> >>>
>> >> >>> 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
>> >> >>
>> >> >
>> >> >
>> >> >
>> >> > 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-webapi mailing list
>> >> > [hidden email]
>> >> > https://lists.mozilla.org/listinfo/dev-webapi
>> >> _______________________________________________
>> >> dev-webapi mailing list
>> >> [hidden email]
>> >> https://lists.mozilla.org/listinfo/dev-webapi
>> >
>> >
>
>
_______________________________________________
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: Vibration API

Paul Theriault
In reply to this post by Adrienne Porter Felt
So long as this is easily user configurable, then I don't see this as a
huge risk. Rather than heuristics, how about just giving the user an
easily accessible interface to disable vibration for a given domain
(maybe show the vibrate icon in the status bar, tapping brings up a
dialog that allows disable vibration for this domain).

Which makes me think we do actually need a permission for vibration,
even if it is granted by default.


On 4/20/12 9:47 AM, Adrienne Porter Felt wrote:

> I wasn't suggesting that the threshold is 20 minutes. Instead, my comment
> is that 20 minutes is clearly above the threshold, so this is evidence that
> there must be *some* reasonable threshold that won't break many games.
>   30sec? 20sec?  10sec?  3sec?  This could probably be resolved with a
> rather fun short survey of games.
>
> On Fri, Apr 20, 2012 at 1:44 AM, Justin Lebar<[hidden email]>wrote:
>
>> On Fri, Apr 20, 2012 at 9:33 AM, Adrienne Porter Felt<[hidden email]>
>> wrote:
>>> Surely there are limits as to what even a game wants to do with a
>> vibrator
>>> -- I doubt a game is going to want to constantly vibrate the phone for 20
>>> solid minutes.  Since that is the case, there must be a threshold.
>> Sure, but if we set the threshold at 20 minutes of continuous
>> vibration, we haven't accomplished very much in terms of avoiding user
>> annoyance.
>>
>>> On Fri, Apr 20, 2012 at 1:12 AM, Justin Lebar<[hidden email]>
>>> wrote:
>>>>> Maybe the API implementation itself can limit the number of vibration
>>>>> requests made by a page in a period of time ...
>>>> I don't know how to do this in a way which wouldn't mess up e.g. a
>>>> game which uses the vibrator all the time.  In general, heuristics
>>>> like this are hard.  :-/
>>>>
>>>>>> On 19 April 2012 11:31, JOSE MANUEL CANTERA FONSECA<[hidden email]>
>> wrote:
>>>>>>> Is there any special risk on allowing any kind of unauthenticated
>>>>>>> content
>>>>>>> to request vibration without any permission request?
>>>>>>>
>>>>>>> Thanks, best
>>>>>>>
>>>>>>> El 16/04/12 07:55, "Lucas Adamski"<[hidden email]>  escribió:
>>>>>>>
>>>>>>>> Last call for comments!  So far the only feedback I have received is
>>>>>>>> that
>>>>>>>> it would be good to have a UI mechanism for determine which app is
>>>>>>>> triggering the vibration, which sounds like a reasonable idea to me.
>>>>>>>> Thanks!
>>>>>>>>   Lucas.
>>>>>>>>
>>>>>>>> On Apr 11, 2012, at 10:36 PM, Lucas Adamski wrote:
>>>>>>>>
>>>>>>>>> Name of API: Vibration
>>>>>>>>> Reference: http://dev.w3.org/2009/dap/vibration/
>>>>>>>>>
>>>>>>>>> Brief purpose of API: Let content activate the vibration motor
>>>>>>>>>
>>>>>>>>> Inherent threats: Obnoxious if mis-used, consume extra battery
>>>>>>>>> Threat severity: low
>>>>>>>>>
>>>>>>>>> == Regular web content (unauthenticated) ==
>>>>>>>>> Use cases for unauthenticated code: Vibrate when hit in a game
>>>>>>>>> Authorization model for uninstalled web content: Explicit
>>>>>>>>> Authorization model for installed web content: Implicit
>>>>>>>>> Potential mitigations: Limit how long vibrations can run
>>>>>>>>>
>>>>>>>>> == Trusted (authenticated by publisher) ==
>>>>>>>>> Use cases for authenticated code:[Same]
>>>>>>>>> Authorization model: Implicit
>>>>>>>>> Potential mitigations:
>>>>>>>>>
>>>>>>>>> == Certified (vouched for by trusted 3rd party) ==
>>>>>>>>> Use cases for certified code:
>>>>>>>>> Authorization model: implicit
>>>>>>>>> Potential mitigations:
>>>>>>>>>
>>>>>>>>> Notes:  This API may be implicitly granted.  User can deny from
>>>>>>>>> Permission Manager to over-ride an abusive app.
>>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> dev-webapps mailing list
>>>>>>>> [hidden email]
>>>>>>>> https://lists.mozilla.org/listinfo/dev-webapps
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> 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
>>>>>
>>>>>
>>>>> 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-webapi mailing list
>>>>> [hidden email]
>>>>> https://lists.mozilla.org/listinfo/dev-webapi
>>>> _______________________________________________
>>>> dev-webapi mailing list
>>>> [hidden email]
>>>> https://lists.mozilla.org/listinfo/dev-webapi
>>>
> _______________________________________________
> 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: WebAPI Security Discussion: Vibration API

Justin Lebar-3
On Fri, Apr 20, 2012 at 10:18 AM, Paul Theriault <[hidden email]> wrote:
> So long as this is easily user configurable, then I don't see this as a huge
> risk. Rather than heuristics, how about just giving the user an easily
> accessible interface to disable vibration for a given domain (maybe show the
> vibrate icon in the status bar, tapping brings up a dialog that allows
> disable vibration for this domain).
>
> Which makes me think we do actually need a permission for vibration, even if
> it is granted by default.

We don't currently give users the ability to disallow audio from a
given domain.  Maybe you'd argue we should!  (You might be right.  :)
But until we do that, I don't think there's any need to give users an
"easily-configurable" way to disable vibration by domain, especially
since audio will play in background tabs, but vibration won't.

Just close the tab/app if it's vibrating like heck.  I feel like
anything else may be over-engineering this.

> On 4/20/12 9:47 AM, Adrienne Porter Felt wrote:
>>
>> I wasn't suggesting that the threshold is 20 minutes. Instead, my comment
>> is that 20 minutes is clearly above the threshold, so this is evidence
>> that
>> there must be *some* reasonable threshold that won't break many games.
>>  30sec? 20sec?  10sec?  3sec?  This could probably be resolved with a
>> rather fun short survey of games.
>>
>> On Fri, Apr 20, 2012 at 1:44 AM, Justin
>> Lebar<[hidden email]>wrote:
>>
>>> On Fri, Apr 20, 2012 at 9:33 AM, Adrienne Porter Felt<[hidden email]>
>>> wrote:
>>>>
>>>> Surely there are limits as to what even a game wants to do with a
>>>
>>> vibrator
>>>>
>>>> -- I doubt a game is going to want to constantly vibrate the phone for
>>>> 20
>>>> solid minutes.  Since that is the case, there must be a threshold.
>>>
>>> Sure, but if we set the threshold at 20 minutes of continuous
>>> vibration, we haven't accomplished very much in terms of avoiding user
>>> annoyance.
>>>
>>>> On Fri, Apr 20, 2012 at 1:12 AM, Justin Lebar<[hidden email]>
>>>> wrote:
>>>>>>
>>>>>> Maybe the API implementation itself can limit the number of vibration
>>>>>> requests made by a page in a period of time ...
>>>>>
>>>>> I don't know how to do this in a way which wouldn't mess up e.g. a
>>>>> game which uses the vibrator all the time.  In general, heuristics
>>>>> like this are hard.  :-/
>>>>>
>>>>>>> On 19 April 2012 11:31, JOSE MANUEL CANTERA FONSECA<[hidden email]>
>>>
>>> wrote:
>>>>>>>>
>>>>>>>> Is there any special risk on allowing any kind of unauthenticated
>>>>>>>> content
>>>>>>>> to request vibration without any permission request?
>>>>>>>>
>>>>>>>> Thanks, best
>>>>>>>>
>>>>>>>> El 16/04/12 07:55, "Lucas Adamski"<[hidden email]>  escribió:
>>>>>>>>
>>>>>>>>> Last call for comments!  So far the only feedback I have received
>>>>>>>>> is
>>>>>>>>> that
>>>>>>>>> it would be good to have a UI mechanism for determine which app is
>>>>>>>>> triggering the vibration, which sounds like a reasonable idea to
>>>>>>>>> me.
>>>>>>>>> Thanks!
>>>>>>>>>  Lucas.
>>>>>>>>>
>>>>>>>>> On Apr 11, 2012, at 10:36 PM, Lucas Adamski wrote:
>>>>>>>>>
>>>>>>>>>> Name of API: Vibration
>>>>>>>>>> Reference: http://dev.w3.org/2009/dap/vibration/
>>>>>>>>>>
>>>>>>>>>> Brief purpose of API: Let content activate the vibration motor
>>>>>>>>>>
>>>>>>>>>> Inherent threats: Obnoxious if mis-used, consume extra battery
>>>>>>>>>> Threat severity: low
>>>>>>>>>>
>>>>>>>>>> == Regular web content (unauthenticated) ==
>>>>>>>>>> Use cases for unauthenticated code: Vibrate when hit in a game
>>>>>>>>>> Authorization model for uninstalled web content: Explicit
>>>>>>>>>> Authorization model for installed web content: Implicit
>>>>>>>>>> Potential mitigations: Limit how long vibrations can run
>>>>>>>>>>
>>>>>>>>>> == Trusted (authenticated by publisher) ==
>>>>>>>>>> Use cases for authenticated code:[Same]
>>>>>>>>>> Authorization model: Implicit
>>>>>>>>>> Potential mitigations:
>>>>>>>>>>
>>>>>>>>>> == Certified (vouched for by trusted 3rd party) ==
>>>>>>>>>> Use cases for certified code:
>>>>>>>>>> Authorization model: implicit
>>>>>>>>>> Potential mitigations:
>>>>>>>>>>
>>>>>>>>>> Notes:  This API may be implicitly granted.  User can deny from
>>>>>>>>>> Permission Manager to over-ride an abusive app.
>>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> dev-webapps mailing list
>>>>>>>>> [hidden email]
>>>>>>>>> https://lists.mozilla.org/listinfo/dev-webapps
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> 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
>>>>>>
>>>>>>
>>>>>>
>>>>>> 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-webapi mailing list
>>>>>> [hidden email]
>>>>>> https://lists.mozilla.org/listinfo/dev-webapi
>>>>>
>>>>> _______________________________________________
>>>>> dev-webapi mailing list
>>>>> [hidden email]
>>>>> https://lists.mozilla.org/listinfo/dev-webapi
>>>>
>>>>
>> _______________________________________________
>> 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
12