Re: WebIDL usage for Algorithms

On Mar 17, 2014 7:54 PM, "Mark Watson" <watsonm@netflix.com> wrote:
>
>
>
>
> On Mon, Mar 17, 2014 at 7:30 PM, Ryan Sleevi <sleevi@google.com> wrote:
>>
>>
>>
>>
>> On Mon, Mar 17, 2014 at 6:55 PM, Boris Zbarsky <bzbarsky@mit.edu> wrote:
>>>
>>> On 3/17/14 9:37 PM, Ryan Sleevi wrote:
>>>>
>>>> Just to make sure - are you advocating for "any" as the type, on this
>>>> basis, or are you still advocating for "object", for the reason below.
>>>
>>>
>>> I think using "object" here would be the right thing to do.
>>>
>>>
>>>> I'm not sure I fully grok your concern here or what you're proposing as
>>>> an alternative.
>>>
>>>
>>> If you look at the algorithm at
https://dvcs.w3.org/hg/webcrypto-api/raw-file/tip/spec/Overview.html#dfn-SubtleCrypto-method-encryptfor
example, it performs all the steps after step 3 asynchronously (using
what task source?).  Step 6 involves invoking
https://dvcs.w3.org/hg/webcrypto-api/raw-file/tip/spec/Overview.html#algorithm-normalizing-rules(I
assume; the actual link in that step is broken), which can cause
execution of arbitrary page script.
>>>
>>> If it's not critical that this happen asynchronously, it would be best
to do this arbitrary script execution before returning from the encrypt()
call, to avoid introducing races.  If it _is_ critical that this happen
asynchronously, then we need to specify which task queue is used for the
task that calls into script.
>>
>>
>> Yeah. The previous version of the spec was clear that there was a new
(crypto) task queue, but this got inadvertently reverted.
>>
>> Algorithm *normalization*, as currently specified, could happen
serially. This design itself was an artifact of the event-based system. The
key event that needs to remain asynchronous is detection as to whether or
not an algorithm is supported by the underlying implementation. In the
previous (event-based) system, it had to make a distinction between a
fast-failure path or not, but in the Promise system, we have a bit more
flexibility to still reject later.
>>
>> This definitely all goes out the window if we allow JS to register its
own polyfills as algorithms - as has been discussed in the past (eg: for
allowing custom KDFs/digest operations). Of course, that's a "Version 3"
kind of feature (where "Version 2" just deals with Streams API).
>>
>>>
>>>
>>>
>>>> The asynchronous nature is already going to be a problem for
>>>> ArrayBuffers - which we MUST take a structured clone of the data BEFORE
>>>> we can return the promise
>>>
>>>
>>> This is somewhat similar, yes.
>>>
>>>
>>>> On a spec level, can we not simply state that you invoke the structured
>>>> clone algorithm on /alg/, letting o be the internal object created from
>>>> such clone. Then, at later points, as needed, you convert o to the IDL
>>>> dictionary type D, then normalize over D?
>>>
>>>
>>> Even if you create a structured clone, as long as the result of the
clone operation is being created in the same global getting properties from
it can invoke arbitrary script.  Consider, for example:
>>>
>>>   Object.defineProperty(Object.prototype, "name", {
>>>       get: function() { /* Now we get to do whatever we want */ }
>>>     });
>>>
>>> and then passing an empty object literal (so {}) as the algorithm.  The
structured clone will create a new object with no properties in the same
global, and getting .name on it will invoke the getter defined on
Object.prototype.
>>>
>>> You could structured clone into a clean global, I guess.  Is that what
you're talking about here?  If so, can we guarantee that the clean global
will never leak out observably?
>>>
>>> -Boris
>>
>>
>> Yeah, I think we *could* get away with a clean global, since it's just
used as a place-holder to defer IDL conversions, and never exposed.
>>
>> I'll try to put together a spec that attempts to *synchronously* handle
the IDL conversion into the target/derived type prior to returning the
promise, which should hopefully address this. It won't happen until after
the LC version is published, unfortunately.
>>
> Hi Ryan,
>
> To do that in the synchronous section, we're going to need to look up the
correct target type for the ( algorithm, operation ) pair in the
synchronous section. Is that what you mean ?

Yes.

> So, we would also detect supported / unsupported algorithm / operation
combinations here ?
>

No. That (namely unsupported detection) needs to remain asynchronous, even
if some impls. can sync complete.

The distinction here is the assumption the UA can always synchronously
convert JS params, but detection against the underlying libraries may be
async.

> [Boris - thanks for jumping in on this topic - I've learned a lot already]
>
> ...Mark
>