On Fri, Sep 3, 2010 at 12:20 PM, Mark S. Miller <[email protected]> wrote:
> 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. > Sigh. Even when trying to be careful I make the same mistake I just previously tried to correct. I meant "half overt and half non-overt". Whether the non-overt half is covert or side depends on the signaling party's intention, which is orthogonal to the new distinction. > 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 > -- Cheers, --MarkM
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
