Re: JS code examples for ACTION 43

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?

-- A*

Received on Thursday, 6 September 2012 14:38:49 UTC