Re: JS code examples for ACTION 43

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.

Mitch

>
> -- A*
>

Received on Friday, 7 September 2012 21:43:05 UTC