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

On 03/07/2013 03:21 PM, Ryan Sleevi wrote:
>
>
> On Mar 7, 2013 5:48 AM, "Harry Halpin" <hhalpin@w3.org 
> <mailto: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 
> <mailto: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" :)

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.

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