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

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 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
>>
>>
>