Re: What happens if input ArrayBufferView changes during a WebCrypto operation ?

On Mar 7, 2013 6:26 AM, "Harry Halpin" <hhalpin@w3.org> wrote:
>
> On 03/07/2013 03:21 PM, Ryan Sleevi wrote:
>>
>>
>> On Mar 7, 2013 5:48 AM, "Harry Halpin" <hhalpin@w3.org> wrote:
>> >
>> > On 03/06/2013 09:02 PM, Mark Watson wrote:
>> >>
>> >> On Mar 6, 2013, at 11:41 AM, Ryan Sleevi wrote:
>> >>
>> >>> On Wed, Mar 6, 2013 at 11:33 AM, Mark Watson <watsonm@netflix.com>
wrote:
>> >>>>
>> >>>> Our operations are asynchronous. We pass in ArrayBufferView
objects. What is the expected behavior if the application changes the
ArrayBufferView before the WebCrypto operation completes ?
>> >>>>
>> >>>> If the expectation is that the operation completes normally on the
input data as it was when the call was made, then the UA either needs to
make a copy of the data when the call is first made or do some fancy lazy
copy-on-write thing to ensure the web crypto operation retains access to
the original data.
>> >>>
>> >>> Correct. That is what I was trying to express through the description
>> >>> of pending data, but I recognize this needs work, and have been
>> >>> working on rewriting this.
>> >>>
>> >>>> Alternatively, we may say that the behavior is undefined if you
modify the ArrayBuffer that you pass in.
>> >>>
>> >>> If there is anything I have learned from C/C++, it's that undefined
>> >>> behaviour is the root of all error.
>> >>>
>> >>>> Are there other async web APIs that accept ArrayBufferView objects
that have established a precedent for this ?
>> >>>>
>> >>>> …Mark
>> >>>
>> >>> We can force it to be ArrayBuffer, to make it explicit there's a
copy,
>> >>> but the intent of using ABV was to give greater implementation
>> >>> flexibility in optimization, while also allowing easier use for
>> >>> developers.
>> >>
>> >> Ok. Are you aware of anywhere else in the web platform where this
problem exists and what solution they've chosen ?
>> >
>> >
>> > Very good question. One option brought up to be to to cast it to an
immutable Blob.
>>
>> No, not Blob, Harry. ArrayBuffer. Same notion of copy semantics, but
without the requirement of Blobs.
>
> I think you missed my "it" :)
>

No, I didn't. It is unnecessary and overly complex - hence the correction.

> The suggestion was to cast the ArrayBuffer to an immutable Blob for the
duration of the invocation if needed, although I agree that could be
overkill.

ArrayBuffers have more explicit copy semantics - you clone them and you
clone the underlying data, whereas you clone an ArrayBufferView, you MAY
simply reference the underlying data. So there is no need to say you have
to go to Blob - those semantics are already available as an ArrayBuffer, no
normative dependency on FileAPI needed.

Regardless, the use of Blob is wholly unnecessary for immutability - its
simple to use ArrayBuffer (and say MUST copy) or use ArrayBufferView (and
say it must be *indistinguishable * from a copy).

The latter is more preferable because it allows maximum implementation
flexibility, and does not *force* the caller to make an *extra* copy
themselves (which both Blob and ArrayBuffer do). Using ArrayBuffer = 2
copies with added callet complexity. Using ABV = 1 in the worst case.

>
> Whether that is needed or not is a question that depends on the JS
environment - the question is how much guarantees its wise for the spec to
make about that environment.
>
>> I still think the API is fine as is - the only requirement is that its
immutable for the duration of the invocation (which is guaranteed through
JS being single threaded anyways). Any further copying or optimizations are
an implementation option with maximum flexibility.
>>
>> >
>> > The official advice is to bring it up on public-script-coord@w3.org as
this may effect how other WGs deal with the question - if they haven't
already dealt with it.
>> >
>> >   cheers,
>> >      harry
>> >
>> >>
>> >> …Mark
>> >>
>> >>
>> >
>
>