> I didn't see this called out, but how do we think about vibration triggers > for the notification use case from SMS/3rd party apps?
We think about this as a completely separate "notifications" API. This API is separate because it may not directly let pages frob the vibrator -- if I've globally disabled sound and vibrating notifications, then a background SMS app shouldn't be able to ring or vibrate the phone. > Could it be limited to both foreground content that is the top level > window? That way ads in iframes won't be able to annoy the user as much > (and websites can ensure that ads won't be annoying by putting them in > frames). I can't think of a precedent for this kind of thing. If there is a precedent, then I might be OK applying it here. On Thu, Apr 19, 2012 at 2:32 PM, Adrienne Porter Felt <[email protected]> wrote: > Could it be limited to both foreground content that is the top level > window? That way ads in iframes won't be able to annoy the user as much > (and websites can ensure that ads won't be annoying by putting them in > frames). > > On Thu, Apr 19, 2012 at 3:44 AM, Lucas Adamski <[email protected]> wrote: > >> Updated proposal. Note that since only foreground content can trigger >> vibrator, this seems equivalent to other potentially annoying feedback >> mechanisms and should be implicit for uninstalled web content… thoughts? >> >> 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: Implicit >> Authorization model for installed web content: Implicit >> Potential mitigations: Limit how long vibrations can run. Only foreground >> content can trigger vibration. >> >> == 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. >> >> 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-webapi mailing list >> [email protected] >> https://lists.mozilla.org/listinfo/dev-webapi >> > _______________________________________________ > 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
