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

Security/Reviews/Firefox4/AudioAPI Security Review (view source)

Revision as of 03:06, 20 January 2011

2 bytes removed , 20 January 2011

→‎Data

David.humphrey

Confirmed users

656

edits

@@ Line 25: / Line 25: @@
 * 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.
-** 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.
+* What types of validation are done on data inputs (e.g., type checking, string decoding/encoding, etc.)?
-*** 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.
+** 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.
 * What is the output of this feature?