W3C home > Mailing lists > Public > public-webcrypto@w3.org > September 2012

Re: JS code examples for ACTION 43

From: Ryan Sleevi <sleevi@google.com>
Date: Mon, 10 Sep 2012 11:05:11 -0700
Message-ID: <CACvaWvaZ+NAY9OpcGhLnPkC6ADdwWgmTO9VrNkBQvJhLtjBXsA@mail.gmail.com>
To: Mitch Zollinger <mzollinger@netflix.com>
Cc: public-webcrypto@w3.org
On Mon, Sep 10, 2012 at 10:31 AM, Mitch Zollinger
<mzollinger@netflix.com> wrote:
> Hi Arun,
> On 9/7/2012 2:42 PM, Mitch Zollinger wrote:
>> On 9/6/2012 7:38 AM, Arun Ranganathan wrote:
>>> Ryan,
>>> On Sep 5, 2012, at 7:58 PM, Ryan Sleevi wrote:
>>>> On Wed, Sep 5, 2012 at 4:34 PM, David Dahl <ddahl@mozilla.com> wrote:
>>>>> Hello everyone:
>>>>> Arun and I have created a JS example file related to ACTION 43 here:
>>>>> https://github.com/daviddahl/web-crypto-ideas/blob/master/sample-code-fpwd.js
>>>>> Please send comments when you get a chance. I can incorporate approved
>>>>> examples later this week.
>>>>> Cheers,
>>>>> David
>>>> Line 203 - 209: Am I mistaken that, by storing into a Uint16Array,
>>>> you're effectively adding an extra 0 byte for each ASCII character?
>>>> That means that what you're encrypting is not
>>>> "53kr3t" but "5\03\0k\0r\03\0t"
>>> You're right, I was asleep at the wheel. In general, writing sample code
>>> has unearthed a few things about our API, and how we should showcase it in
>>> our spec.
>>> 1. The general unwieldiness of ArrayBufferViews. I shouldn't have used a
>>> Uint16Array, so no cookie for me. But this raises an interesting point:
>>> should we just use an ArrayBuffer, or should we use an ArrayBufferView?
>>> Using an ArrayBufferView obliges users to go through one additional step:
>>> figuring out what the data format *is*. UTF-16? UTF-8? And it might be hard
>>> to write a generic conversion to ArrayBufferView. Of course, most
>>> applications will have a tight handle on data that they'll want manipulated
>>> with the Crypto API.
>>> I liked the assumption of starting with a string, since that really
>>> showcases a simple use case. For such a simple use case, using an
>>> asynchronous API to get an ArrayBuffer (like File API) seemed overkill. We
>>> could have used a WorkerThread and used a sync version, but that's overkill
>>> too. So I tried to get at a synchronous way to get to ArrayBufferView
>>> arguments. And that's a path fraught with some small dangers :)
>>> 2. Call order. You've commented on this already.
>>> 3. Sample code sections. I like the idea of a small sample use case that
>>> accompanies the introduction, followed by individual snippets that
>>> illustrate things after they are defined.
>>> And, given nuances like 1. above, maybe even an appendix. Overkill?
>>>> That sort of subtlety scares me, since I fear people will copy the
>>>> spec as 'good' things. Perhaps this means re-discussing
>>>> ArrayBuffer[View] as a data type, or it may mean that the
>>>> toArrayBufferView should be "ASCIIToArrayBufferView" or some other
>>>> aspect, so that a JS String "53kr3t" is the same as a
>>>> C/Python/Ruby/etc string of "53kr3t" which is the same as the literal
>>>> data "0x35, 0x33, 0x6b, 0x72, 0x33, 0x74", and NOT "0x35, 0x00, 0x33,
>>>> 0x00, 0x6b, 0x00, 0x72, 0x00, 0x33, 0x00, 0x74, 0x00"
>>> Let's say we re-open the ArrayBuffer[View] discussion. Is that bike
>>> shedding? Have I just been careless in writing an utility, or do we think
>>> developers will run into this?
>>> I'd love feedback from Mark W. and Mitch Z. For Netflix use cases, given
>>> (I assume) video content, what would make your life easier?
>> Our use case is more of a lightweight secure protocol wrapper mixed with a
>> fair bit of device / user authentication and authorization. The fact that
>> we're streaming just means that our tolerance for heavyweight protocols that
>> may require significant overhead / latency is extremely low. (SSL, often
>> because of operational misconfiguration issues outside our control, fits the
>> definition of heavyweight.)
>> I'll ping the primary engineer on the WebCrypto update to our secure
>> protocol wrapper to see if he can take a look at this and the other parts of
>> the spec.
> What I heard back is as follows:
> ...
> But regarding ArrayBuffer / ArrayBufferViews, I think it’s important to
> support Uint8Array (which is an ArrayBufferViews), instead of requiring
> ArrayBuffer.
> Whether to support ArrayBuffer as is… it’s a nice to have, since it’s easy
> to “new Uint8Array(ArrayBuffer)”.
> Reason I say Uint8Array support is important, because a typical scenario
> looks like this:
> 1. Download chunk of data as ArrayBuffer
> 2. Say this chunk is ASN1 encoded array (or any other container)… so when I
> extract IV and CypherText from it… they will be two Uint8Arrays (views) over
> same ArrayBuffer.
> 3. If Uint8Arrays is not supported, one will need to make copies of portions
> of original ArrayBuffer…
> ...
> HTH,
> Mitch

Thanks Mitch. That confirms what my thought had been in favouring

I think we can also address the ArrayBuffer v ArrayBufferView by
revisiting the support for Blob - which also supports copy-free
slice()-ing and can save an indirection through a FileReader.
Received on Monday, 10 September 2012 18:05:43 UTC

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