On Fri, Sep 3, 2010 at 11:32 AM, Brendan Eich <[email protected]> wrote:
> On Sep 3, 2010, at 10:31 AM, Mark S. Miller wrote: > > > From email on this thread and from private email I've received, I'm a bit > worried that my earlier message was misunderstood. > > I wrote "covert channel" too, when inviiting you to reply -- sorry about > that, you're right that the side channel is the bigger worry. > > > I agree that we're not going to secure JavaScript well enough to solve > the covert channel problem. > > (Will anything solve that problem, short of the kind of communication > technology described in science fiction, e.g the phones in > http://www.amazon.com/Dead-Lines-Bear-Greg/dp/0345448375 ?) > Thanks for the link. I just ordered it. Short answer: many people think they know how to build practical systems that can limit the bandwidth of outward covert channels. (Specifically, problem #2.a.i below) They may be right. But valuable secrets are often short, so it's not clear how useful bandwidth limits are. Also, as Moore's law continues, presumably the bandwidth of the covert channels scales up with everything else. Longer answer: (apologies for the repetition to those who've already seen this on private email. I though it was worth reposting publicly. I've also further clarified my position on side channel bandwidth issues below.) The EnumerableWeakMap debate is helping me to see a new distinction. Till now, we've only had the following taxonomy: 1) overt -- channel guaranteed by platform semantics, like reading & writing a shared variable. 2) non-overt 2.a) covert - where the communicating parties intent to communicate 2.a.i) outward confinement - where the good guy is trying to suppress the signaling ability of a bad guy presumably under his control. 2.a.ii) inward confinement - where the good guy is trying to suppress the listening ability of a bad guy presumably under his control. 2.b) side - where the signaling party does not intend to signal. Object-capability languages, including Caja and SES, prevent #1. The classic covert channel problem is #2.a.i, and it is indeed too hard. Deterministic object-capability languages such as E and Joe-E solve #2.a.ii. For #2.b as well, zero leakage is too hard and I would be foolish to attempt it. But because none of the signals on this channel are reliable, various countermeasures are possible to impede information leakage, such as introduction of timing noise. In fact, as a side-channel, the various other activities of the signaling app are itself a free source of timing noise absent from a covert channel. As apps get larger and do more, they accidentally provide more free noise for interfering with their own side channels. This is why the limited bandwidth argument has more force for side channels, and why the Moore's law counter-argument has less force. Punch line: Any observable weak reference system, including the EnumerableWeakMap example discussed here, is a taxonomy breaker, in that it is a channel which is half overt and half covert. If c.js observes that an object was collected, it must really have been collected. The only sense in which the channel is unreliable is that a collectable object might never get collected. Thus, the only countermeasure possible within the platform's semantics is to not collect objects which are used as keys in WeakMaps, which destroys the entire motivation for introducing WeakMaps in the first place. > > > > (Fortunately, regarding the WeakMap enumerability question, we seem to > have consensus to stick with non-enumerability on other grounds anyway. But > this side channel question will reappear so we may as well understand the > limits on how well we can resist them.) > > Leo does not concur and I suspect others (Arv) agree with him. > > IMHO Leo's point about weak listener maps and FRP is a good challenge to > the consensus that you, Erik Corry, and I among others do share. I need to > read Greg Cooper's thesis and medidate on our myriad C++ weak listener use > cases before replying further. > > /be > > -- Cheers, --MarkM
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
