[OLPC Security] [sugar] Automatic transfer/update of activities on the mesh (Was: Sharing behavior in the core Read activity)

[Michael Stone]

Eben,

I've got more questions than answers for you, but perhaps my smaller
questions will make the overall problem easier to analyze.

Michael

Questions:

First, how will we discover that a code exchange is needed?

Three straw-man options include:

a) include adequate information in a presence notification or in a
resource discovery URL [1] to permit us to calculate decide
protocol compatibility

[1]: http://lists.laptop.org/pipermail/devel/2008-February/011108.html

b) add a new handshake to the "join a shared instance" protocol to
establish this information.

c) leave it up to the activity to figure out (perhaps with assistance
from a system service or library)

Next, let us assume that a code or data exchange is necessary in order
to provide protocol compatibility. How do I figure out what bits are
needed? How do I figure out where to go in order to get the requisite
bits?

I think it would be wise to add some indirection here so that people
who are not in physical proximity can acquire the bits from low-cost
sources when possible and to fall back on direct exchange of bits when
necessary. Also so that we can extend the bit-acquiry software with
new protocols as they become available.

(For a first draft, we might as well copy Read's use of
HTTP-over-Tubes, since it's already conveniently available to us.)

NB: If we ever want to imagine running Sugar on platforms other than
XOs, (or even between XOs running significantly different builds),
then we'd better consider system-dependency issues up front. (We can
ignore this question temporarily while doing feasibility studies on
our own platform, but if this idea is going to rock the world like I
want it to, then we need to think early on about giving the humans
operating our technology access to information adequate to debug and
work around incompatibilities between their respective systems.)

After acquiring the bits, there's a small question of what to do with
them. Do they go into the Journal as a new entry? Are they immediately
unpacked alongside the user's other activities? If so, do they
obscure older versions of the same activity? Should the older version be
removed?

I'm particularly concerned by Pippy-generated bundles here because
they seem like they might be particularly subject to edit wars simply
by being so easy to create and modify! (Should Pippy-generated bundles
"stake claims" to their names in the fashion proposed in [2]?)

[2]: http://dev.laptop.org/git?p=users/krstic/installer;a=tree;

Naturally, there are some security concerns, but those could be easily
addressed,

They are far from "easily" addressed, but there's a good argument that
they're _worth_ addressing because, in my opinion, easy and safe code
sharing is one of the most attractive UI goals of our project!

I believe, with the usual signing mechanisms. Updates to
activities would only be transparent if the update was signed, etc.

Information assurance mechanisms primarily deal with spoofing attacks
and network hanky-panky. Isolation mechanisms are what we're using to
make it generally safer to run code, regardless of whether we know where
it came from. Both are necessary to make this "easy code sharing" policy
more safe to pursue.