WeakMap API questions?

Mark S. Miller erights at google.com
Fri Sep 3 12:20:37 PDT 2010


On Fri, Sep 3, 2010 at 11:32 AM, Brendan Eich <brendan at mozilla.com> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20100903/086fc247/attachment.html>


More information about the es-discuss mailing list