W3C home > Mailing lists > Public > public-script-coord@w3.org > April to June 2014

[Bug 23369] Provide hooks for Typed Arrays (ArrayBuffer and friends)

From: <bugzilla@jessica.w3.org>
Date: Tue, 17 Jun 2014 23:45:56 +0000
To: public-script-coord@w3.org
Message-ID: <bug-23369-3890-rHFDPGiuCj@http.www.w3.org/Bugs/Public/>
https://www.w3.org/Bugs/Public/show_bug.cgi?id=23369

--- Comment #23 from Allen Wirfs-Brock <allen@wirfs-brock.com> ---
(In reply to Ryan Sleevi from comment #22)
... yes, got that.  It's how promise work in ES.
> 
> The output of the cryptographic operation should be consistent with its
> inputs. If we allowed arbitrary modification, we can run into situations
> like:
> 
> var a = new Uint8Array(4);
> a.set([0, 1, 2, 3]);
> 
> var promise = crypto.subtle.encrypt(.., a, ...);
> // At this time slice, the UA has not yet begun the encryption operation,
> // because the underlying subsystem may only support a single pending
> operation,
> // and the encrypt() is still pending
> a[0] = 4

yes, this would be a stupid thing for somebody to do

> 
> promise.then(result => { 
>   // Does result contain ciphertext for [0, 1, 2, 3] or for [4, 1, 2, 3]
> });
> 

Does it matter which cipertext was processed.  The caller was adequately warned
that they were invoking an async operation which they acknowledged by
explicitly coding a 'then' call.  They went ahead and did something stupid
anyway.  Do we really need to be nannies protecting them from their stupidity.
Is it worth the copying overhead for the vast majority of non-stupid callers
who don't do stupid things like this?  So far, at least for these two
operations it doesn't look like its an integrity issue.

> This is why an explicit copy is noted; the actual transformation of the
> input, plaintext buffer (A) is, in almost all cases (hardware or software),
> not going to happen synchronously before the return of the Promise and
> continuation of the task pool. So callers should have a reasonable
> expectation of what the transformation of the data will look like. Since
> objects - such as ArrayBuffer - are passed by reference, callers can fully
> mutate the object throughout the lifetime of the Promise, so it's necessary,
> as spec authors, to indicate at what point in execution the state is
> accessed.

Like I said above, yes this is all normal. Every good ES programmer understands
these things.  They don't need to be protected from themselves. 


> 
> In Web Crypto's case, we try to make it clear that any and all state that
> will be accessed before the return of the Promise object. Other specs (Web

I didn't catch this as I quickly scan the Web Crypto spec, but I probably just
missed it. At any rate, this answers my why not these question.

> Audio and Web Font Loading come to mind), have not, and as such, have subtle
> issues in their spec that can lead to user-observerable, non-interoperable
> behaviours.

I'm all for spec'ing thinks at a detailed enough level to ensure consistent,
interoperable behavior. But, as soon as you have timing variability, you may
have get observable difference, even within the same implementation. Isn't it
adequate to make it clear which objects are subject to deferred access and
hence produce timing sensitive results?

> ...
> 
> However, for fundamental ES types - those for which Web IDL spends
> significant time dealing with (in terms of the ES <-> IDL type conversions)
> - it would be nice to see %TypedArray% - which is as primitive as %Array%,

well, neither %TypedArray% or Array are primitive in the same sense as Number,
Boolean, Number in ES6. But I agree that handling of %TypedArrays% has a place
within WebIDL.  I don't think either Array or %TypedArray% instances should be
routinely copied as part of the WebIDL parameter passing mechanism.

> %String%, %Boolean%, or %Number% are in ES6 - to have specific language in
> Web IDL to explain how it's used with Web IDL, and to afford Spec Authors
> ways to hook or customize that behaviour (eg: copies), if necessary.
>

-- 
You are receiving this mail because:
You are on the CC list for the bug.
Received on Tuesday, 17 June 2014 23:45:57 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:22 UTC