W3C home > Mailing lists > Public > public-webcrypto@w3.org > October 2013

Re: Mutability of CryptoOperationData

From: Alexey Proskuryakov <ap@webkit.org>
Date: Tue, 29 Oct 2013 12:49:10 -0700
Cc: "public-webcrypto@w3.org" <public-webcrypto@w3.org>
Message-id: <7DCEB911-92AF-455E-AA5D-A7FFB41FE603@webkit.org>
To: Ryan Sleevi <sleevi@google.com>

29 ΟΛΤ. 2013 Η., Χ 12:17, Ryan Sleevi <sleevi@google.com> ΞΑΠΙΣΑΜ(Α):

> Spec wise, I think the goal should be to permit any number of possible internal implementations, provided the external behaviour remains consistent. The 'expected' external behaviour is that the operation acts upon the data present in the CryptoOperationData at the time of the call. This would be specified by describing the normative-equivalent operation as taking a copy of all the data during the call - eg: by invoking Structured Clone and then freezing the structured clone (but *not* neutering or freezing the original). Implementations could then implement COW w/o violating that normative guarantee.

I just got strong feedback from our JavaScript team. Sounds like the practical choices are:
- freeze the input buffers;
- copy the data eagerly (bad for WebCrypto performance, but won't kill performance of other code that uses typed arrays, like WebGL);
- make the algorithms run synchronously on the main thread.


It would not be practical to implement copy-on-write for array buffers.  Array buffers are meant to be used as arrays for JavaScript code.  If we added copy-on-write then every single store operation into every single array would have to do a check to see if it should invoke a copying operation.  This gets really horrific very quickly and would lead to a dramatic performance regression for JavaScript.

This regression wouldn't just manifest for our JS engine but also for any other JS engine that also implemented copy-on-write for crypto.

- WBR, Alexey Proskuryakov
Received on Tuesday, 29 October 2013 19:49:38 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:17:19 UTC