----- Original Message ----- > From: "Devdatta Akhawe" <[email protected]> > To: "Justin Lebar" <[email protected]> > Cc: [email protected], [email protected], > [email protected], "Lucas Adamski" > <[email protected]>, "dev-b2g mailing list" <[email protected]> > 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 <[email protected]> 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 > > <[email protected]> > > 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 > > > [email protected] > > > https://lists.mozilla.org/listinfo/dev-b2g > > _______________________________________________ > > dev-security mailing list > > [email protected] > > https://lists.mozilla.org/listinfo/dev-security > > > _______________________________________________ > dev-b2g mailing list > [email protected] > https://lists.mozilla.org/listinfo/dev-b2g > _______________________________________________ dev-security mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security
