No subject


Thu Aug 19 10:50:54 PDT 2010


worried that my earlier message was misunderstood. I agree that we're not
going to secure JavaScript well enough to solve the covert channel problem.
I stated so:


On Tue, Aug 31, 2010 at 9:32 PM, Mark S. Miller <erights at google.com> wrote:

> The example above is of a covert channel, in the sense that b.js *intends*
> to send a signal that c.js can read. When b.js does not intend to signal, we
> have a side channel rather than a covert channel. Preventing a covert
> channel is generally much harder than preventing a side channel, so one
> might argue that the addition of this covert channel doesn't matter much.
>
> But JavaScript currently doesn't have any side channels as juicy as this
> one. If b.js is not intending to signal to c.js, but rather is just
> innocently doing some internal data-dependent algorithmic task, how much can
> c.js ascertain about b.js's internals by seeing which shared immutable
> objects get dropped? Securing JavaScript is already hard enough as it is.
> I'd rather not have to add to it the burden of trying to answer this very
> hard question.
>


Although I illustrated the non-overt channel here as a covert channel in a
possibly failed attempt at clarity, my real point and my real worry is about
its use as a side channel. As a side channel, this ability to sense the
collection of individual objects is much more informative than anything I
know of in current JS. If anyone knows of any side channels that seem as
bad, perhaps I've overlooked them, so please post. If they also seem
unpluggable, then I would agree that my position here becomes pointless and
we'd need to give on resisting side channels as well.

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


-- 
    Cheers,
    --MarkM

--0016e68db6e60bba4e048f5e4d1d
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div>From email on this thread and from private email I&#39;ve received, I&=
#39;m a bit worried that my earlier message was misunderstood. I agree that=
 we&#39;re not going to secure JavaScript well enough to solve the covert c=
hannel problem. I stated so:</div>
<div><br></div><div><br></div>On Tue, Aug 31, 2010 at 9:32 PM, Mark S. Mill=
er <span dir=3D"ltr">&lt;<a href=3D"mailto:erights at google.com">erights at goog=
le.com</a>&gt;</span> wrote:<br><div class=3D"gmail_quote"><blockquote clas=
s=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;pad=
ding-left:1ex;">
<div class=3D"im">The example above is of a covert channel, in the sense th=
at b.js *intends* to send a signal that c.js can read. When b.js does not i=
ntend to signal, we have a side channel rather than a covert channel. Preve=
nting a covert channel is generally much harder than preventing a side chan=
nel, so one might argue that the addition of this covert channel doesn&#39;=
t matter much.=A0</div>
<div class=3D"gmail_quote">
<div><br></div><div>But JavaScript currently doesn&#39;t have any side chan=
nels as juicy as this one. If b.js is not intending to signal to c.js, but =
rather is just innocently doing some internal data-dependent algorithmic ta=
sk, how much can c.js ascertain about b.js&#39;s internals by seeing which =
shared immutable objects get dropped? Securing JavaScript is already hard e=
nough as it is. I&#39;d rather not have to add to it the burden of trying t=
o answer this very hard question.</div>
</div></blockquote><div><br></div><div><br></div><div>Although I illustrate=
d the non-overt channel here as a covert channel in a possibly failed attem=
pt at clarity, my real point and my real worry is about its use as a side c=
hannel. As a side channel, this ability to sense the collection of individu=
al objects is much more informative than anything I know of in current JS. =
If anyone knows of any side channels that seem as bad, perhaps I&#39;ve ove=
rlooked them, so please post. If they also seem unpluggable, then I would a=
gree that my position here becomes pointless and we&#39;d need to give on r=
esisting side channels as well.</div>
<div><br></div><div>(Fortunately, regarding the WeakMap enumerability quest=
ion, we seem to have consensus to stick with non-enumerability on other gro=
unds anyway. But this side channel question will reappear so we may as well=
 understand the limits on how well we can resist them.)</div>
<div><br></div><div><br></div></div>-- <br>=A0 =A0 Cheers,<br>=A0 =A0 --Mar=
kM<br>

--0016e68db6e60bba4e048f5e4d1d--


More information about the es-discuss mailing list