WebAPI/Security/Vibration: Difference between revisions

Jump to navigation Jump to search
no edit summary
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
Confirmed users
717

edits

Navigation menu