[E-Lang] not a statement of consensus on ERiaSR versus liveref

[Marc Stiegler]

We've had a long, tortuous discussion about ERiaSR and liverefs. Truthfully,
I have not read and understood in nitty detail every message that has showed
up about this topic. But the following sums up my own current mental state
with respect to the discussion. This mental state is composed of highlights,
arguments for/against that struck me strongly and have not been memorably
refuted . So this is not a statement of consensus, or even a draft of such a
statement, but might prove useful as a starting point from which to compose
such a draft.

-- Tyler has convinced me that ERiaSR could solve the simple form of the
Zooko-Wagner-Stiegler attack on the marketplace. As such, it has
demonstrated a desireable security property.

-- Tyler's has not convinced me that ERiaSR would solve the complicated form
of the attack, in which the the attacker depends upon the statistical
phenomenon of the bidder moving to his neighbor's machine to continue his
transaction after the impatience policy on his own machine asserts that the
bidder should abandon hope of further communication with the server. Quite
possibly, I am not convinced of this only because I do not understand
Tyler's proposal in its full glory. But that is my mental state at this
time.

-- I have proposed a simple rule that renders systems safe from the original
Zooko-Wagner-Stiegler attack (revoke the capabilities for live message
recipients before assuming they will receive no more messages). This rule
works for both simple and complex versions of the attack. It also works for
both liveref and ERiaSR systems.

-- Neither ERiaSR nor the simple liveref rule protects from the more serious
Hartley time-value-of-messages attack.

-- Zooko has convinced me that there are times when it would be nice if a
dialog between two objects could continue despite breaks in the low-level
comm infrastructure (lower-level than E or the jvm upon which it runs)
"automatically", without application-level programmer intervention to
explicitly make the objects sturdy. For example, if the line drops between
my Linux server and my ISP, it would be nice if, when it automatically
redials, and if it succeeds in getting a connection, my operations would
just simply continue (though as a practical matter, sometimes when my Linux
box loses the connection, I have to reboot the box to regain the connection,
in which case the current behavior of the system more usefully models my
needs and interests. As a practical matter, I would hardly notice the
improvement ERiaSR would in theory give me in the operation of eDesk. And in
a world in which it did make a serious difference, I would  probably upgrade
the software so that those liverefs became sturdy--my current understanding
of what it will take to implement this at the application layer is, it won't
be hard, probably not as hard as implementing keepalives at the application
layer...though I look forward to having a more informed opinion when
persistence is available :-).

-- I remain convinced that the current impatience policy based on keepalives
makes a remarkably good default policy, and haven't heard an argument that
convinces me it has a serious downside as a default. Even if someone
composes an example of a situation in which it has a serious downside,
unless the example is really powerful, my answer would be to make E have
replaceable default impatience policies in a later version.

-- No one has refuted the statement that moving vats, rather than
capabilities, around your system to maintain communication state is a
violation of POLA. Any system which requires moving vats around is, in my
current opinion, far more harmful to system security than is the risk from
incorrect application-level implementations of protection against the
delayed delivery attack.

-- No one has refuted the statement that moving vats around would create
systems whose behavior is unpredictable because of the increased risk of
having duplicates.

-- No one has refuted the statement that depending on up-to-date vats
creates a backup problem. I will mention here that I consider such
dependency to be fatally grievous: there has to be something you can burn on
a cd-rom that enables you to pick up and get on with your life with
reasonable effectiveness.

--Between this loss of predictability and the backup problem and the serious
POLA issue, I believe a requirement upon any comm system for E is that it
must not in general depend on copying vats rather than capabilities for
transfers of authority or operation (though if someone develops a particular
application that depends on this, it is okay, it is their problem). An
earlier, more naive self would have said this rules out ERiaSR, but Tyler
seems to have ideas on how to solve this problem.

-- I surmise that, with the passage of time, this argument will become less
important while, in its reduced importance, increasingly favoring ERiaSR.
This is based on the prediction that with the passage of time connections
will become more reliable. For example, I myself am likely to get a DSL line
in a couple of months, and may no longer be on the front line of the part of
the world in which the keepalive impatience policy is strikingly useful.
However, it will be a long time in conventional years--and centuries in
Internet years--before connections get that reliable for everyone (remember,
even while our connectivity is getting reliable, vast swaths of Earth are
just getting their first minimal levels of connectivity, and have a long way
to go before getting good reliability).

My bottom line on all this is that I am intrigued by ERiaSR, but I am not
yet really convinced that it is, overall, clearly better than liverefs--and
I am a long way from being convinced that it is so much better that we
should gut the comm system to support it in version 1.0 of E.

Point of philosophy: I said above that ERiaSR has demonstrated a desireable
security property. Someone might think this is, all by itself, a single-hit
proof that ERiaSR is required. But the design goal for E cannot be that it
will automatically protect from every attack for which we can imagine
implementing an automated defense. The goal must be the simpler purpose of
ensuring that programmers have enough tools so that they can indeed develop
secure systems, with a simplicity and straightforwardness a couple of orders
of magnitude better than with current tools, yet still expecting that the
ferocity of security analysis and security architecture will grow in
parallel with the ferocity of the security requirement. This is on the one
hand a more modest goal, yet it is a huge goal, and one which E achieves
regardless of ERiaSR versus liveref (at least, there are no counterproofs to
this statement at this time).

In the absence of a dramatically compelling argument (compelling to me, that
is, it is clear that some of the arguments already presented are
dramatically compelling to others :-), I personally would be more interested
in identifying ways of making ERiaSR an upwardly compatible upgrade for a
future version of E. Such a path would enable us to defer the debate until
we have had more serious actual run-ins with the limitations of liverefs,
and to experiment in a more leisurely fashion with ERiaSRs to see what (if
any) their limitations might be.

--marcs