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)â€