Re: WebIDL usage for Algorithms

Sent from my iPhone

On Mar 10, 2014, at 6:39 PM, Richard Barnes <rlb@ipv.sx> wrote:

So it seems like the editors' inclination (and what's in WebKit/Chrome) is
option (1), requiring custom bindings.  I can agree with that, and
understand the utility of still having the dictionaries around in that case.

It still seems like we need to change the use of Algorithm in the
SubtleCrypto methods to prevent binding at that method invocation.


We have text that says the type mapping doesn't happen on method invocation
but when explicitly stated in the asynchronous part. Do you think we need
more ?

...Mark


--Richard



On Mon, Mar 10, 2014 at 11:50 PM, Mark Watson <watsonm@netflix.com> wrote:

> Richard,
>
> Yes, Ryan and I discussed this and I've proposed a solution in the ED.
>
> First, since we decided all errors must be asynchronous, we can't have
> WebIDL type mapping happening at the usual time. We explicitly note this
> and then explicitly specify when to do type mapping. The type mapping is
> done in the "normalize to X" algorithm which takes an object and does
> WebIDL type mapping to dictionary type X (as well as resolving any aliases,
> though we still don't have any of these defined).
>
> As you say, this mapping discards members not mentioned in X, so
> "normalize to Algorithm" leaves you only with name. The individual
> algorithm operations call "normalize to Y" where Y is the appropriate
> subclass.
>
> ...Mark
>
>
> On Mon, Mar 10, 2014 at 4:18 PM, Ryan Sleevi <sleevi@google.com> wrote:
>
>>
>> On Mar 10, 2014 4:12 PM, "Richard Barnes" <rlb@ipv.sx> wrote:
>> >
>> > TL;DR: Usage of Dictionary inheritance for Algorithms is broken.
>>  Should use WebIDL object type or callback interfaces instead.
>> >
>> > BACKGROUND:
>> > In the current spec, algorithm identifiers and parameters are passed to
>> encrypt(), decrypt(), etc. using dictionaries that inherit from Algorithm,
>> which is itself a dictionary type.  For example:
>> >   dictionary Algorithm { DOMString name; }
>> >   dictionary AesCbcParams : Algorithm { CryptoOperationData iv; }
>> >   typedef (Algorithm or DOMString) AlgorithmIdentifier;
>> >   Promise<any> encrypt(AlgorithmIdentifier algorithm, ... )
>> >
>> > PROBLEM:
>> > According to the WebIDL spec for handling of dictionary types, the
>> implementation is required to create the dictionary object by copying out
>> of the source object the fields specified in the type definition.
>> > http://www.w3.org/TR/WebIDL/#es-dictionary
>> >
>>
>> Yes, I raised this privately with Mark when discussing things I didn't
>> think were LC ready.
>>
>> > For WebCrypto, this means that polymorphism via inheritance of
>> dictionaries doesn't work.  If someone creates a dictionary that matches
>> AesCbcParams and passes it to encrypt(), then the WebIDL implementation
>> will only store the "name" field, and throw everything else away.  Anything
>> using the WebIDL object will not be able to see the "iv" parameter.
>> >
>>
>> Did the wording Mark proposed to handle this not address it?
>>
>> Note the asynchronous behavior of WebIDL conversions that are written.
>>
>> > As far as implementation: I discovered this bug while trying to
>> implement using the Firefox WebIDL implementation, so clearly Firefox has
>> this problem :)  It appears that Chromium is internally treating
>> "algorithm" arguments as generic objects (not following the WebIDL spec for
>> dictionaries), then using a "parseAlgorithm" method to pull out relevant
>> information.
>> >
>>
>> Both Blink and WebKit have implemented this with custom bindings.
>>
>> > PROPOSED RESOLUTION:
>> > It seems to me that we have a couple of options here.
>> >
>> > 1. "typedef object Algorithm" - Don't have the WebIDL handle any of the
>> internal structure of Algorithm objects, but instead lay this out in the
>> text of the spec.  In this case, there's no inheritance to speak of, just
>> lists of what parameters must be present in each use of Algorithm.  We
>> would need to specify at what point in the process values are extracted
>> from the object.
>> >
>>
>> Or just call it "any"
>>
>> > 2. "callback interface Algorithm" - This would use inheritance and have
>> the expected behavior, since callback interfaces keep around a copy of the
>> provided JS object.  However, there might be some weird behaviors if people
>> pass in exotic objects, e.g., side-effects or changing values.  Also, the
>> spec would need to carefully define exactly when the properties are
>> accessed, and all per-spec access to the properties would need to be done
>> on the main thread, since it needs to be able to run script.
>> >
>>
>> Strongly opposed to this. Its going to be quite ugly and requires
>> painting over all of the ES5/ES6 interactions.
>>
>> > I have a slight preference for (2).  It continues to delegate most of
>> the work to WebIDL, and it seems unlikely that people will do exotic enough
>> things to cause trouble, given that the way WebCrypto uses these objects is
>> fairly straightforward.
>> >
>> > --Richard
>> >
>> >
>>
>> Considering that the WebIDL spec changed in order to support other use
>> cases of ours - notably, the Promise<resolve type> notation - have you
>> considered approaching the WebIDL WG with this?
>>
>> >
>> >
>> >
>> >
>>
>
>