[kentonv]

We're certainly aware of them, but haven't spent a lot of time focused on this issue yet. Of course, the issue exists on all forms of shared compute. So if you're going to do crypto, you'd better make it constant-time. Which is... not easy in Javascript. (But we will provide the WebCrypto API, which might help.)

There is a theoretical solution that we might be able to explore at some point: If compute is deterministic -- that is, always guaranteed to produce the same result given the same input -- then it can't possibly pick up side channels. It's possible to imagine a Javascript engine that is deterministic. The fact that Javascript is single-threaded helps here. In concrete terms, this would mean hooking Date.now() so that it stays constant during continuous execution, only progressing between events.

That said, this is just a theory and there would be lots of details to work out.

[SomeStupidPoint]

> There is a theoretical solution that we might be able to explore at some point: If compute is deterministic -- that is, always guaranteed to produce the same result given the same input -- then it can't possibly pick up side channels.

Doesn't this require the timing and interleaving with other processes also be deterministic? ...which seems hard to guarantee with modern CPUs, async IO, and shared execution.

[kentonv]

If you don't provide (real) time as an input to the program, then non-determinism of time does not affect determinism of the program. At least, in theory. It's definitely a long way from there to practice.

[SomeStupidPoint]

That's true -- but "the program" is also any code using yours as a middle-step, which is the case of a network service is a huge number of people. So anything that requires total program control rather than subroutine enforced safety is a nonstarter.

The timing may occur outside of your control, and then statistical profiling used. If the timing of a reponse to a network request has a time component that depends on shared load, then you have a side-channel.