Re: WebIDL usage for Algorithms

On Mon, Mar 17, 2014 at 7:58 PM, Ryan Sleevi <sleevi@google.com> wrote:

>
> 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.
>
I meant algorithm/operation pairs that were unsupported by the
*specification*, not just by the implementation. For example, trying to
call "sign" with an algorithm that specifies AES-CTR. You won't even find
a target dictionary type to which the argument should be converted in this
case.

...Mark

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