On Fri, Apr 20, 2012 at 10:18 AM, Paul Theriault <ptheria...@mozilla.com> 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<justin.le...@gmail.com>wrote: >> >>> On Fri, Apr 20, 2012 at 9:33 AM, Adrienne Porter Felt<a...@berkeley.edu> >>> 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<justin.le...@gmail.com> >>>> 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<j...@tid.es> >>> >>> 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"<ladam...@mozilla.com> 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 >>>>>>>>> dev-weba...@lists.mozilla.org >>>>>>>>> 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 >>>>>>>> dev-security@lists.mozilla.org >>>>>>>> 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 >>>>>> dev-web...@lists.mozilla.org >>>>>> https://lists.mozilla.org/listinfo/dev-webapi >>>>> >>>>> _______________________________________________ >>>>> dev-webapi mailing list >>>>> dev-web...@lists.mozilla.org >>>>> https://lists.mozilla.org/listinfo/dev-webapi >>>> >>>> >> _______________________________________________ >> dev-security mailing list >> dev-security@lists.mozilla.org >> https://lists.mozilla.org/listinfo/dev-security _______________________________________________ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
