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