Re: JS code examples for ACTION 43

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

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