WebAPI/Security/FMRadioAPI: Difference between revisions

From MozillaWiki
Jump to navigation Jump to search
No edit summary
No edit summary
Line 1: Line 1:
== FM Radio API==
==WebFM API==


Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=749053
References:
*https://bugzilla.mozilla.org/show_bug.cgi?id=749053
*https://groups.google.com/d/topic/mozilla.dev.webapi/PraULCQntqA/discussion


Brief purpose of API: FM radio feature.
Brief purpose of API: FM radio feature.
Line 22: Line 24:
Potential mitigations: An app or page can't access any of the radio API if another page/app is currently using it. Whenever a page/app uses the API for the first time since another page/app used it, always reset the current frequency to some specified value
Potential mitigations: An app or page can't access any of the radio API if another page/app is currently using it. Whenever a page/app uses the API for the first time since another page/app used it, always reset the current frequency to some specified value


=== Trusted (authenticated by publisher) ===
== Privileged (approved by app store) ==
Use cases for certified code: radio app
Use cases for privileged code: radio app


Authorization model: Implicit
Authorization model: Implicit
Line 29: Line 31:
Potential mitigations: Same as for unauthenticated.
Potential mitigations: Same as for unauthenticated.


=== Certified (vouched for by trusted 3rd party) ===
== Certified (system-critical apps) ==
Use cases for certified code:  radio app
Use cases for certified code:  radio app



Revision as of 23:48, 6 August 2012

WebFM API

References:

Brief purpose of API: FM radio feature.

General Use Cases: Turn on/off the radio, change frequency, check status of various radio features Inherent threats: annoyance, drain the battery

Threat severity: Low

General notes: Multiple apps/pages can try to modify radio settings at the same time with the most recent action taking effect. Turning on the radio causes the audio stream to be played - there is no access to the stream data

Regular web content (unauthenticated)

Use cases for unauthenticated code: radio app/web page

Authorization model for normal content: Explicit

Authorization model for installed content: Implicit

Potential mitigations: An app or page can't access any of the radio API if another page/app is currently using it. Whenever a page/app uses the API for the first time since another page/app used it, always reset the current frequency to some specified value

Privileged (approved by app store)

Use cases for privileged code: radio app

Authorization model: Implicit

Potential mitigations: Same as for unauthenticated.

Certified (system-critical apps)

Use cases for certified code: radio app

Authorization model: Implicit

Potential mitigations: Same as for unauthenticated. Technically we wouldn't need to reset the frequency here, but seems nicer to keep things consistent.