Confirmed users
656
edits
Security/Reviews/Firefox4/AudioAPI Security Review: Difference between revisions
Security/Reviews/Firefox4/AudioAPI Security Review (view source)
Revision as of 03:02, 20 January 2011
, 20 January 2011→Data
No edit summary |
(→Data) |
||
| Line 25: | Line 25: | ||
* 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. | ||