W3C home > Mailing lists > Public > public-webcrypto@w3.org > April 2013

Re: Web Crypto Spec Updates for ArrayBufferView, ArrayBuffer, and Streams

From: Ryan Sleevi <sleevi@google.com>
Date: Fri, 26 Apr 2013 19:37:52 -0700
Message-ID: <CACvaWvayC-ySXAnpGFN_UvL9ZxGYsaXQoW_5x1P=qNKALG=R3Q@mail.gmail.com>
To: Israel Hilerio <israelh@microsoft.com>
Cc: Aymeric Vitte <vitteaymeric@gmail.com>, Alex Russell <slightlyoff@google.com>, Arun Ranganathan <aranganathan@mozilla.com>, "public-webcrypto@w3.org" <public-webcrypto@w3.org>
On Fri, Apr 26, 2013 at 7:09 PM, Israel Hilerio <israelh@microsoft.com> wrote:
> Per our conversation during the F2F.  ArrayBufferViews are useful to when
> you want to access parts of the information inside an ArrayBuffer.  If you
> are going to be consuming the ArrayBuffer directly, it doesnít make sense to
> create ArrayBufferViews.  Here are some examples of APIs that directly
> generate ArrayBuffers or consume it:
> * XHR return type can be an ArrayBuffer --> XMLHttpRequestResponseType of
> ArrayBuffer
> * Blob constructor (takes both ArrayBuffer or ArrayBufferView)
> * Blob readAsArrayBuffer returns an ArrayBuffer

Right - I have to keep up with stalking Arun's bugs.

Blob started as ArrayBuffer, then switched to ArrayBufferView (along
with XHR.send()) in

However, overloaded support for ArrayBufferView was restored back in
https://www.w3.org/Bugs/Public/show_bug.cgi?id=18668 , as a result of

If you examine that bug, you will see that decision was in part based
on the fact that IE10 was shipping with Blob supporting ArrayBuffer in
the constructor. I don't think we have the same limitations here, so I
think we want to be careful when using Blob as a justification for the

For example, XHR.send() continues to only take an ArrayBufferView -
see http://xhr.spec.whatwg.org/#the-send()-method - and the
ArrayBuffer overload is something we've deprecated in Chrome ( see

I think we should also be careful when distinguishing between
*generating* and *returning* an ArrayBuffer. I agree that it may make
sense to update result to be an explicit ArrayBuffer, but I'm less
convinced on the overloads for inputs, given the other API

> * MSE appendBuffer(ArrayBuffer)
> Overloading the existing methods to directly consume ArrayBuffer, in
> addition to ArrayBufferView, provides more flexibility and simplifies the
> programming model for developers who are looking to use the ArrayBuffer
> content directly.
> Like I mentioned during our F2F, the purpose of this suggestion was to
> simplify the programming model.  Iím not as passionate on this topic because
> our engine internally manages both ArrayBuffer and ArrayBufferView inputs
> the same way.
> As we also discussed in the F2F, the use of streams enables many useful
> scenarios and the existing event model can be nicely incorporated to provide
> progress events.  We agreed that streams enables the support of needed uses
> cases to reduce number of buffer copies and increase performance.  Streams
> are currently supported in the MSE and XHR:
> *  SourceBuffer.appendStream (Stream stream, optional unsigned long long
> maxSize);
> * XHR return type can be an stream --> XMLHttpRequestResponseType of stream
> Also, my understanding from Ryan was that Chrome is working on a streamís
> implementation.  If we are considering making fundamental changes to the
> spec this late in the game to include things like Future then this seems
> like a reasonable addition given there are concrete use cases for it and a
> more stable spec for it ;-).

I would suggest Futures is probably far less reaching than Streams,
for the reasons discussed and explored at

The primary reason that I see it as less-fundamental is that the
current API is already modeled after 'success'+result/'failure' - a
concept easily modeled by Futures.

Streams is a much more significant conceptual shift in design, at
least with respect to *vending* a Stream - perhaps as much as to
suggest a fundamentally different API.

That is, the current API conceptually models elements of both a Stream
(eg: the nature of result) and a StreamBuilder (eg:
CryptoOperation.process() ~= StreamBuilder.append() ,
CryptoOperation.finish() ~= StreamBuilder.close() )

Streams are also somewhat troubling because, as defined in
, Streams have a content type, whereas CryptoOperations do not. For
most use cases of crypto, this adds additional caller overhead to
(perhaps redundantly) indicate the type if application/octet-stream.
Additionally, Streams may be used with URL.createObjectURL() - which
has a whole host of issues that have yet to be addressed in the File
API, but carry with it significant security / performance
considerations when applied to Crypto.

I'd like to detach the Streams proposal from the
ArrayBuffer/ArrayBufferView discussion, to make sure that we can
adequately discuss both issues, but it certainly seems like if we were
to make changes in the first version, ArrayBuffer/ArrayBufferView is
much more tenable than Streams.
Received on Saturday, 27 April 2013 02:38:19 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:17:16 UTC