WebAPI/Security/FMRadioAPI: Difference between revisions
No edit summary |
No edit summary |
||
Line 1: | Line 1: | ||
== | ==WebFM API== | ||
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 | ||
== | == Privileged (approved by app store) == | ||
Use cases for | 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 (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:
- 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.
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.