WebAPI/Security/FMRadioAPI: Difference between revisions

From MozillaWiki
Jump to navigation Jump to search
No edit summary
No edit summary
 
(5 intermediate revisions by 2 users not shown)
Line 1: Line 1:
== FM Radio API==
==WebFM API==
 
Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=749053
 
Brief purpose of API: FM radio feature.
Brief purpose of API: FM radio feature.


Line 13: Line 10:
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
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) ===
References:
Use cases for unauthenticated code: radio app/web page
*https://bugzilla.mozilla.org/show_bug.cgi?id=749053
 
*https://groups.google.com/d/topic/mozilla.dev.webapi/PraULCQntqA/discussion
Authorization model for normal content: Explicit
=== Permissions Table===
 
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
 
=== Trusted (authenticated by publisher) ===
Use cases for certified code:  radio app
 
Authorization model: Implicit
 
Potential mitigations: Same as for unauthenticated.


=== Certified (vouched for by trusted 3rd party) ===
{| border="1" class="wikitable"
Use cases for certified code: radio app
! Type
! Use Cases
! Authorization Model
! Notes & Other Controls
|-
| Web Content || radio app/web page || Explicit ||  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
|-
| Installed Web Apps || radio app/web page || Implicit || 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 Web Apps || radio app || Implicit ||
|-
| Certified Web Apps || radio app || Implicit || Same as for unauthenticated. Technically we wouldn't need to reset the frequency here, but seems nicer to keep things consistent.
|}


Authorization model: Implicit
__NOTOC__


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

Latest revision as of 23:40, 1 October 2014

WebFM API

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

References:

Permissions Table

Type Use Cases Authorization Model Notes & Other Controls
Web Content radio app/web page Explicit 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
Installed Web Apps radio app/web page Implicit 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 Web Apps radio app Implicit
Certified Web Apps radio app Implicit Same as for unauthenticated. Technically we wouldn't need to reset the frequency here, but seems nicer to keep things consistent.