On Fri, Apr 20, 2012 at 9:47 AM, Adrienne Porter Felt <[email protected]> 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 <[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
