WebAPI/Security/Vibration: Difference between revisions

From MozillaWiki
Jump to navigation Jump to search
mNo edit summary
Line 20: Line 20:
Potential mitigations: Limit how long vibrations can run.  Only foreground content can trigger vibration.
Potential mitigations: Limit how long vibrations can run.  Only foreground content can trigger vibration.


== Trusted (authenticated by publisher) ==
<h2> Privileged (approved by app store) </h2>
Use cases for authenticated code:[Same]
<p>Use cases for authenticated code: [Same]
 
</p><p>Authorization model: Implicit
Authorization model: Implicit
</p><p>Potential mitigations:
 
</p>
Potential mitigations:  


== Certified (vouched for by trusted 3rd party) ==
== Certified (vouched for by trusted 3rd party) ==

Revision as of 21:03, 6 August 2012

Name of API: Vibration

Reference: http://dev.w3.org/2009/dap/vibration/

Background Discussion: https://groups.google.com/group/mozilla.dev.webapps/browse_thread/thread/6aa715e1d7a5a9f5#

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.

Privileged (approved by app store)

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. Since only foreground content can trigger vibrator, this seems equivalent to other potentially annoying feedback mechanisms and should be implicit for uninstalled web content.