Re: JS code examples for ACTION 43

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

>
> Mitch
>
>>
>> -- A*
>>
>

Received on Monday, 10 September 2012 17:32:01 UTC