[Bug 23728] CryptoOperationData can be mutated during operation

https://www.w3.org/Bugs/Public/show_bug.cgi?id=23728

Ryan Sleevi <sleevi@google.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |public-webcrypto@w3.org

--- Comment #2 from Ryan Sleevi <sleevi@google.com> ---
So, the Web Audio solution isn't fully applicable here.

Web Audio only takes ArrayBuffer's as inputs, and describes an algorithm that
is not clear if it's actually legal. That is, the algorithm ( from
https://dvcs.w3.org/hg/audio/raw-file/tip/webaudio/specification.html#methodsandparams-AudioContext
), is roughly

- Temporarily mark [input buffer] as neutered
- Perform some asynchronous operation
- Restore [input buffer] to it's original, un-neutered state.

That doesn't work for CryptoOperationData, which may take an ArrayBufferView,
for the reasons described in
https://www.khronos.org/registry/typedarray/specs/latest/#9.3 - Cloning an
ArrayBufferView - although the language in ES6 (which is where TypedArrays now
live - http://people.mozilla.org/~jorendorff/es6-draft.html#sec-structured-data
- with the transferrable semantics in
http://www.whatwg.org/specs/web-apps/current-work/multipage/common-dom-interfaces.html#transferable-objects
)

Implementing something like the Typed Array transfer semantics isn't desirable
in general, for consider a use case like digest(). Neutering the original
object forces the copy semantics onto the caller, which then makes memory
management more difficult to reason about (as it relates to reasoning about all
the scopes both the original buffer and its clone are viable in).

In order to resolve this, I've made it explicit that the asynchronous
operations operate on a copy of the data. This was included in the pre-Promises
version of the specification, as well as the "sequence<CryptoOperationData>"
form.

Alternative suggestions are welcome, but probably with accompanying proposed
spec text.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

Received on Monday, 12 May 2014 03:25:08 UTC