WeakMap API questions?

Mark S. Miller erights at google.com
Fri Sep 3 12:27:48 PDT 2010

On Fri, Sep 3, 2010 at 12:20 PM, Mark S. Miller <erights at google.com> wrote:

> 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.

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20100903/f2b70dbd/attachment.html>

More information about the es-discuss mailing list