
Blink-dev – Intent to Ship: SharedArrayBuffer - okket
https://groups.google.com/a/chromium.org/forum/#!msg/blink-dev/dnzvgTswfbc/AFIUge2oDQAJ
======
Sephr
If Chrome is going to ship SharedArrayBuffer, then why will the resolution of
performance.now() and other timer APIs continue to be neutered? I don't have
any preference one way or the other for implementing SharedArrayBuffer, but I
am fully against neutering timers with jitter if a vendor does choose to
implement SharedArrayBuffer. Random additional timer jitter becomes a false
layer of security in this scenario, and
[https://bugs.chromium.org/p/chromium/issues/detail?id=506723](https://bugs.chromium.org/p/chromium/issues/detail?id=506723)
should be reverted.

With SharedArrayBuffer you can easily implement extremely high resolution sub-
nanosecond timers and open the door to new timing attacks. For example, here
is a high resolution SharedArrayBuffer timer:
[https://codepen.io/yossioren/pen/LVBNMR](https://codepen.io/yossioren/pen/LVBNMR)

For more discussion regarding the security implications of this change, see
[https://github.com/tc39/ecmascript_sharedmem/issues/1](https://github.com/tc39/ecmascript_sharedmem/issues/1)
. Some of the security problems may be mitigable with Intel CAT, although I am
not aware of Chrome making use of that yet.

~~~
skrebbel
Is there any layman's introduction to this subject? I can't comprehend how
having an accurate timer lets me steal information from other processes.

~~~
Sephr
The papers "The Spy in the Sandbox -- Practical Cache Attacks in Javascript"
at
[https://arxiv.org/pdf/1502.07373.pdf](https://arxiv.org/pdf/1502.07373.pdf)
and "ASLR on the Line: Practical Cache Attacks on the MMU" at
[http://www.cs.vu.nl//~herbertb/download/papers/anc_ndss17.pd...](http://www.cs.vu.nl//~herbertb/download/papers/anc_ndss17.pdf)
are good starting points, though they are not very accessible to a layman.

There have even been timing attacks that let you recover AES keys from
analyzing a device's power usage.

In layman's terms: computers are extremely complicated beasts of coordinated
timing of software and hardware, and timing data leaks many things about what
a piece of software is doing. This is the reason that many modern encryption
libraries pad operations as a defense against timing attacks.

~~~
skrebbel
Thanks. I had actually started reading The Spy in the Sandbox but it was too
hardcore for me.

So, how does this work? I set a timer, and then read the time a bit later, and
somehow I recovered an AES key from a different process? I'm still missing a
piece :-)

Notably, how can timing data _leak_ things?

I mean, I can see how I can do

    
    
        1. Start hi-res timer
        2. Kick off something that involves out-of-sandbox data
        3. Stop hi-res timer
    

and do this often enough and with well-tuned input to read useful data out. Is
that how it works?

But how can I use this to read stuff in entirely different processes?
Moreover, how can I do that in a targeted manner? Eg I suspect my target is
using internet banking but I don't know which other programs are running, how
many cores the machine has, etc etc etc.

~~~
Dylan16807
> Notably, how can timing data leak things?

That part's simple. Naive crypto code will often vary in speed based on the
data. A 0 bit in the key causes some behavior, a 1 bit causes some slightly
different behavior, and suddenly if you can measure the length of each step
you can recover the secrets.

Getting the timing data is a little bit trickier from javascript, but it's
also simple in concept. As sensitive code runs, it affects the CPU cache.
Javascript can use memory locations that go in the same cache slots as
sensitive code. This goes a few nanoseconds faster or slower based on what
parts of the sensitive code have finished. Now you have timing data.

If you don't know what else is running or if you're on the same core, you just
have to try repeatedly.

------
franciscop
I am not sure I like some of the new changes. It seems to me like JS is
expanding both towards an _upper level_ language and a _lower level_ language,
which frankly makes it look more like a Frankenlanguage. I guess it's the
limitations of having a single real language to be used in the browsers.

Edit: just check this tutorial. I'd venture to guess to 99% of JS developers
it sounds totally bizarre:
[https://github.com/tc39/ecmascript_sharedmem/blob/master/TUT...](https://github.com/tc39/ecmascript_sharedmem/blob/master/TUTORIAL.md)

~~~
zensavona
But that is exactly what is needed. JavaScript is essentially a becoming a
~native~ language (like C, C++, Java) which is used to implement all kinds of
abstractions.

Think of C++ for example. It's used to implement frameworks like JUCE, used
for high-level application logic and UIs, but underneath that there are a lot
of optimised abstractions. Some of these abstractions can only be so good or
so deep until the language they are implemented in can get closer to the
"metal" (or in this instance, VM).

I for one welcome these new additions to the ECMAscript spec.

~~~
vvanders
> ... ~native~ language (like C, C++, Java)

One of those is not like the others.

~~~
stymaar
Surprisingly enough, Java is a native language in some parts of the embeded
world (see smart cards for instance, but not only [1]).

[1]:
[https://en.m.wikipedia.org/wiki/Java_processor](https://en.m.wikipedia.org/wiki/Java_processor)

~~~
fulafel
Also Android.

------
bhouston
This is great. It opens up a lot of possibilities for our online 3D editor -
background worker threads that each work on a segment of an array.

Now if only Node.JS could support worker threads at all.

~~~
rogerwang
In NW.js you can use Node.js in Web Worker:
[https://nwjs.io/blog/v0.18.4/](https://nwjs.io/blog/v0.18.4/) . HTH.

~~~
tuananh
why is it available in NW.js but not Node?

~~~
rogerwang
I think Node community is working on it. In NW the implementation of webworker
from browser can be leveraged.

------
caleblloyd
The main benefit here will be realized in Shared Workers. Unfortunately Edge
support is "not planned" and WebKit support is "removed"
[http://caniuse.com/#feat=sharedworkers](http://caniuse.com/#feat=sharedworkers)

I guess it may come in handy for Electron apps.

~~~
chrismorgan
You don’t need Shared Workers to benefit from this. I haven’t ever actually
_used_ Shared Workers, but as I understand it the normal sort of case for them
could be polyfilled without too much difficulty.

Using Web Workers instead of Shared Workers just means that any actual
communication beyond the shared memory must be posted via the instantiator of
the worker.

~~~
streptomycin
You're right about Shared Workers not being needed for this, but just to
continue going off on a tangent...

I think a polyfill would be pretty difficult. First you have to make sure only
one tab starts a Web Worker. Maybe that's not impossible, but it's tricky. And
then the real difficulty... when the tab that spawned the Web Worker closes
while another tab is open, you'd need to spawn another Web Worker in that tab
and copy the state of the first Web Worker to the second Web Worker before the
first one is destroyed by the browser. Not sure if that's possible.

~~~
the8472
You can use broadcastchannel to coordinate multiple tabs and workers. And I
think once you receive a message from such a channel you get a proxy for the
sender, which means you can establish a 1-1 channel, which in turn means you
can can transfer objects like sharedarraybuffer.

------
riquito
I've just stumpled once again on atob/btoa not working with characters like or
𝒞 and here I read about SharedArrayBuffers, which is way a greater goal. Of
course they're right to work on such projects, go for it, but I can't avoid to
be baffled by the fact that (apparently) more mundane operations don't receive
love.

Other examples would be MD5 removed from subtlecrypto, killing any way to
speak with services that use it for non-cryptographic operations, or the
missing functions to encode/decode hex strings, which maybe are not everyday
use cases but are provided by most languages and would need an afternoon to
write with tests.

I want a better standard library. Just my discouraged 5 cents.

~~~
IIIIIIIIIIII
I'm just curious since I never used this feature, are you talking about this
issue?

> The "Unicode Problem"

> Since DOMStrings are 16-bit-encoded strings, in most browsers calling
> window.btoa on a Unicode string will cause a Character Out Of Range
> exception if a character exceeds the range of a 8-bit ASCII-encoded
> character. There are two possible methods to solve this problem:

[https://developer.mozilla.org/en/docs/Web/API/WindowBase64/B...](https://developer.mozilla.org/en/docs/Web/API/WindowBase64/Base64_encoding_and_decoding#The_.22Unicode_Problem.22)

~~~
riquito
Yes, that one

------
dom0
> Gives JavaScript access to shared memory, atomics, and futex.

Holy fuck, this is going to be _bad_ , introducing a whole continent of new
bugs into JavaScript land. And also giving JS even more and even better
options to spy and attack other applications on the same computer.

~~~
Matthias247
Yes, it introduces a whole new range of multithreading issues also to JS land.

However I think threading issues won't be as common as in C++/Java/C# land,
since the only thing that will be shared between threads/workers is byte
arrays -> There's no shared access to other Javascript objects. As most normal
JS developers won't be dealing with plain byte arrays the potential for misuse
is not too high.

------
bricss
SharedArrayBuffer and Atomics is already in Chrome, unluckily behind the flag.

------
ic4l
This is GREAT! Transferable's didn't make sense in a few situations.

