Security/Reviews/Firefox4/AudioAPI Security Review: Difference between revisions

no edit summary
(Created page with "== Overview == ''Audio Data API'' ;Background links * API Spec and Wiki Page * [https://bugzilla.mozilla.org/show_bug.cgi?id=490705 Bug 490705] == Security ...")
 
No edit summary
Line 10: Line 10:


* Is this feature a security feature?
* Is this feature a security feature?
 
** No.
No.


* Is system or subsystem security compromised in any way if your project's configuration files / prefs are corrupt or missing?
* Is system or subsystem security compromised in any way if your project's configuration files / prefs are corrupt or missing?
 
** No.
No.


* If any content or UI is displayed to the user, in what context is that content presented?  Does it have chrome privileges, for example?
* If any content or UI is displayed to the user, in what context is that content presented?  Does it have chrome privileges, for example?
 
** No UI.
No UI.


* Does the feature include any new cryptographic functions or other security-critical code?
* Does the feature include any new cryptographic functions or other security-critical code?
 
** No.
No.


== Data ==
== Data ==


* What data is read or parsed by this feature?
* What data is read or parsed by this feature?
 
** This API exposes two new data pipes to content scripts.  The first is a read-only framebuffer (via a DOM event) of raw audio data (floats) representing the decoded audio information in a media element (video or audio).  The second is a set of functions allowing JavaScript developers to create and write to an audio stream.
This API exposes two new data pipes to content scripts.  The first is a read-only framebuffer (via a DOM event) of raw audio data (floats) representing the decoded audio information in a media element (video or audio).  The second is a set of functions allowing JavaScript developers to create and write to an audio stream.


** What types of validation are done on data inputs (e.g., type checking, string decoding/encoding, etc.)?
** What types of validation are done on data inputs (e.g., type checking, string decoding/encoding, etc.)?
 
*** When writing data to an audio stream from JavaScript, users must pass a regular JavaScript Array or a Typed Float32 Array.  Passing other JavaScript objects or primitives (including null, undefined, etc.) will cause an error to be thrown (we have tested sending every possible type, which is how we found a few crash bugs before landing).  Next, we check to see how much data the underlying audio stream can write without buffering, and only write this amount.  We do this in order to avoid overflowing the various audio buffers with overly large arrays.
When writing data to an audio stream from JavaScript, users must pass a regular JavaScript Array or a Typed Float32 Array.  Passing other JavaScript objects or primitives (including null, undefined, etc.) will cause an error to be thrown (we have tested sending every possible type, which is how we found a few crash bugs before landing).  Next, we check to see how much data the underlying audio stream can write without buffering, and only write this amount.  We do this in order to avoid overflowing the various audio buffers with overly large arrays.
*** A second check is placed on users' ability to alter framebuffer sizes.  We allow users to set a new framebuffer size for audio events (default is channels * 1024), but force them to pick a value between 512 and 16384.  Any other value causes an error, and the default value to still be used.  We did this in order to make sure that users can't set very large sizes and request too much memory, or very small sizes and flood the event system.
 
A second check is placed on users' ability to alter framebuffer sizes.  We allow users to set a new framebuffer size for audio events (default is channels * 1024), but force them to pick a value between 512 and 16384.  Any other value causes an error, and the default value to still be used.  We did this in order to make sure that users can't set very large sizes and request too much memory, or very small sizes and flood the event system.


* What is the output of this feature?
* What is the output of this feature?
 
** As mentioned above, raw audio data in the form of a framebuffer (Typed Float32 Array) is exposed to the DOM.
As mentioned above, raw audio data in the form of a framebuffer (Typed Float32 Array) is exposed to the DOM.


* What storage formats are used?
* What storage formats are used?
 
** No data is ever stored.
No data is ever stored.


== Configuration ==
== Configuration ==


* Can the end user configure settings (via UI, about:config, or environment variables)?
* Can the end user configure settings (via UI, about:config, or environment variables)?
 
** Preferences affecting same-origin checks will influence the availability of the framebuffers.  We perform an origin check before releasing audio data into the DOM.  In order to use audio from file:/// URIs, for example, the security.fileuri.strict_origin_policy pref has to be turned off (it is on by default).
Preferences affecting same-origin checks will influence the availability of the framebuffers.  We perform an origin check before releasing audio data into the DOM.  In order to use audio from file:/// URIs, for example, the security.fileuri.strict_origin_policy pref has to be turned off (it is on by default).


* Are there build options for developers (e.g. #ifdefs, ac_add_options)
* Are there build options for developers (e.g. #ifdefs, ac_add_options)
 
** This feature integrates with the main media features, and would be turned on/off as they were.
This feature integrates with the main media features, and would be turned on/off as they were.


* What are its on-going maintenance requirements (e.g. Web links, perishable data files)?
* What are its on-going maintenance requirements (e.g. Web links, perishable data files)?
 
** The [[Audio Data API]] wiki page currently serves as the most reliable and complete set of documentation, and needs to be kept up-to-date.
The [[Audio Data API]] wiki page currently serves as the most reliable and complete set of documentation, and needs to be kept up-to-date.


= Review comments =
= Review comments =
''Notes and bug numbers will be recorded here.  Let's try not to spend too much time on any one topic during the meeting.''
''Notes and bug numbers will be recorded here.  Let's try not to spend too much time on any one topic during the meeting.''
Confirmed users
656

edits