W3C home > Mailing lists > Public > public-webcrypto@w3.org > March 2014

Re: WebIDL usage for Algorithms

From: Boris Zbarsky <bzbarsky@MIT.EDU>
Date: Mon, 17 Mar 2014 21:55:30 -0400
Message-ID: <5327A792.7020509@mit.edu>
To: Ryan Sleevi <sleevi@google.com>
CC: "public-webcrypto@w3.org" <public-webcrypto@w3.org>
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 
for example, it performs all the steps after step 3 asynchronously 
(using what task source?).  Step 6 involves invoking 
(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.

> 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 

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?

Received on Tuesday, 18 March 2014 01:55:59 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:02:41 UTC