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<[email protected]>wrote:
On Fri, Apr 20, 2012 at 9:33 AM, Adrienne Porter Felt<[email protected]>
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<[email protected]>
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<[email protected]>
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"<[email protected]> 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
[email protected]
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
[email protected]
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
[email protected]
https://lists.mozilla.org/listinfo/dev-webapi
_______________________________________________
dev-webapi mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-webapi
_______________________________________________
dev-security mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-security
_______________________________________________
dev-security mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-security
