WebAPI/Security/Vibration: Difference between revisions

From MozillaWiki
Jump to navigation Jump to search
No edit summary
Line 3: Line 3:
Reference: http://dev.w3.org/2009/dap/vibration/
Reference: http://dev.w3.org/2009/dap/vibration/


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


Brief purpose of API: Let content activate the vibration motor
Brief purpose of API: Let content activate the vibration motor
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.


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


== Certified (vouched for by trusted 3rd party) ==
== Privileged (approved by app store) ==
Use cases for certified code:
Use cases for privileged code:


Authorization model: Implicit
Authorization model: Implicit
Line 35: Line 35:
Notes:  This API may be implicitly granted.  User can deny from Permission Manager to over-ride an abusive app.
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.
Since only foreground content can trigger vibrator, this seems equivalent to other potentially annoying feedback mechanisms and should be implicit for uninstalled web content.
== Certified (system-critical apps) ==
Same as Privileged

Revision as of 21:13, 6 August 2012

Name of API: Vibration

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

Security 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:

Privileged (approved by app store)

Use cases for privileged 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.

Certified (system-critical apps)

Same as Privileged