Re: JS code examples for ACTION 43

On Thu, Sep 6, 2012 at 7:38 AM, Arun Ranganathan <arun@mozilla.com> 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.

Can you explain how ArrayBuffer is any easier than ArrayBufferView?

Perhaps you meant to say Blob (from the File API), since Blob has a
constructor that can take an ArrayBufferView or DOMString.

My concern with Blob (and with ArrayBuffer w/o the View) is that they
both seem to require that the underlying data be copied in order to
construct/invoke, whereas ArrayBufferView is a slice of an already
existing ArrayBuffer (or arbitrary data source, in the case of
DataView), and thus is copy-free.

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

I'm not sure "small sample" and "introduction" are necessarily
compatible, as David's example shows. Plus I'd like to avoid having to
delay FPWD for another week or two weeks while the merits of needing
to demonstrate a particular use case are discussed.

+1 for individual snippets (I'm thinking more on the objects, rather
than on the methods)
+1 for appendix example that "ties it all together" (eg: where this
sample code might live)

>
> 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?

It's not clear which discussion we're re-opening. ArrayBuffer v
ArrayBufferView seems a new one. Blob v ArrayBuffer[View] is
reasonable. There's also the "streaming" API issue that is open as
ISSUE-18 - http://www.w3.org/2012/webcrypto/track/issues/18

>
> 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*

I'd be curious to, because this would be a new use case not yet
discussed. The wiki and text have focused on device authentication.

Received on Thursday, 6 September 2012 17:12:24 UTC