[sugar] Mini-Conference Proposal: Automatic transfer/update of activities on the mesh

[Jameson "Chema" Quinn]

OK, the mini-conference happened - thanks for trying to let off-siters like
me participate. Here's the Gobby doc which resulted, below are my
post-meeting comments:

Activity sharing:

* Should we show people what the size/download time for a package is before
d/l?
* We might download something more readily if it's coming from a friend.
  * Michael:  Trusting a friend isn't the same as trusting code coming from
    that friend.

Ben:  The only security question is whether it's safe to *replace* an
activity
      with a new one.  Bitfrost guarantees that running untrusted code is
safe.

Scott:  You can always modify code, but you have to give it a new name.

Michael:  Making something default is a separate UI action from downloading
it.
Should distinguish between activities by their hashes; version numbers
shouldn't
be used for equality.

homunq: unsigned versions should obviously not get the same preference
directory.

proposals for naming:
  * centralized registry, e.g. microsoft.com
  * mstone:  first person to get there owns the space (and others get
"another version of %s")
  * each activity has a random guid for "same activity" and ...


http://wiki.laptop.org/go/Talk:Activity_bundles#A_proposal_for_Activity_Signing

How to put related activities together?
  * group by tag
  * add prefix in name, sort by name
  * group by magic "sortkey" tag
  decision: A and/or B as author decides.


SJ:  Attach names to the inherent identity of an activity
.. okay, SJ can type what he meant ;-)
I make a new activity, *E*.  It gets a ?unique? id, E.id and a ?pretty
unique? package name, ?E?.  ?E? is the friendly name you use locally to
identify the activity.  There is also a pretty name ued in interfaces, which
is ?E!? this can be translated, changed from version to versiion.

when I join a larger group that has some other activity named E, I should
change my public activity-name (andraelly should change the display name).
Everyone can see that my ?E? is differnet from the existing one, since they
have different unique IDs, but to supprot simple intreface-driven updates
and version selection, the friendly package name should change.

aside: there is some confusion about the hisotrical and practical use of
sortkeys.  this is some piece of metadata that an author can acontribuet,
which will help to sort a cluster of related activities with one another.

similarly, which activities appear nextto which other ones in the circle
view is improtnt.   note - this is NOT aout ?favorites?.


Grouping   Version   Identity
  P            10     X
   \- P         9     O  <-- change in ownership
  N             8     X
   \- N         7     X

Eben:  Use tags to support grouping, e.g. "tamtam" or "mamamedia" or "draw"
Scott: Localisation of tags is hard.

note : having ?signed? versions of activities, and the ecure model, is not
necesarily relevant to lots of activities and use caes.  we should support
identifying versions that claim to e of the same underlying activity, and
claimed merges and forks, without worrying about keys and signing.


THINGS ABOUT WHICH THERE IS NOT CONSENSUS.
how to bulk update a set of activities soeveryone in a room has the same
version

update on share?  is this a good idea?  how would it work in ui?

push updates - is this a good idea? how would it work?

My post-meeting comments:

1. for "version threading", what we need for an activity is not a claim like
"I am a version of activity ID XXXX" but "My prior version was XXX and the
one before that was YYY". What is the granularity of XXX and YYY? I'd say, a
hash on the activity.info would be fine - that way, version changes are
automatically picked up, but not every change in the source code. If, later,
activity.info picks up some elements which are too volatile (thus leading to
unnecessarily-long geneologies), we could filter those out before hashing.
Note that this is totally orthogonal to whether an activity version is
signed by the original devteam, and yet allows for forks to become
independent without fighting over who is the "real pippy
org.laptop.XYZ1FFE3". I submit that merges are unnecessary.

2. If we get the version threads right, then the auto-update on sharing
becomes safer. I still don't understand who has to sign to avoid a break in
the ownership chain - I would presume a given set of maintainer/developers,
and I would presume that there would be some way for the group to change
over time - but those details can be worked out.

3. For "push updates" and "school versions", I would presume you'd in some
manner beyond the scope of this discussion get an xo bundle (or a bundle of
bundles), the only problem here is how to install it and mark it as the
official school version. Stated like that, it seems to be obviously a
problem of tagging. How do you securely tag documents you receive from
external sources? I'd say that only signed tags should be allowed to move
from one XO to another, and that it should be possible to have a filter
which automatically pushes activity versions with "tag X signed by entity Y"
to the front of the line, or even into the activity donut. This filter would
be user-modifiable, but the default filter could be to trust the signature
of your school server; thus, the 99% of kids who didn't bother with that
would automatically and painlessly use the official school version.

Jameson



On Tue, Mar 25, 2008 at 3:31 PM, Eben Eliason <eben.eliason at gmail.com>
wrote:

> After just a couple well considered responses, it seems that this
> might be another topic worthy of some time under the spotlight at the
> mini-conference.  I copied both of these great responses to my initial
> email below, just to make sure they remain for everyone to reference.
> I trust that you can faithfully reconstruct my initial proposal and
> questions from the responses.
>
> - Eben
>
>
> On Tue, Mar 25, 2008 at 4:02 PM, Benjamin M. Schwartz
> <bmschwar at fas.harvard.edu> wrote:
> > On Tue, 2008-03-25 at 13:46 -0400, Eben Eliason wrote:
> >  > Naturally, there are some security concerns, but those could be
> easily
> >  > addressed, I believe, with the usual signing mechanisms.  Updates to
> >  > activities would only be transparent if the update was signed, etc.
> >
> >  I agree.  For a first implementation, only basic signing is required.
> >  Eventually, we may have activities written by teams of children in
> which
> >  new members come and go, and the projects occasionally fork.  This
> >  requires a more complex signing/upgrade system.  I sketched one
> proposal
> >  at [1]; it is not perfect.
> >
> >
> >  > The bigger question is really determining how to make the whole
> >  > transfer process work smoothly in these cases.  Can we use a torrent
> >  > model to make it easy to get activities from the mesh, even as people
> >  > come and go on an unreliable network?
> >
> >  For a first implementation, this is not necessary.  Most Activity
> >  Bundles (.xo's) are about 100 KB or less.  Over a direct mesh link,
> >  transferring small bundles takes about a second.  Only with very large
> >  activities, and very bad links, will simple transfers be insufficient.
> >
> >
> >  > Can we transfer it directly
> >  > from someone who is in the activity we join?
> >
> >  This seems the simplest solution.
> >
> >
> >  > If so, can we still ask
> >  > the next activity participant for the remainder if the first one
> >  > leaves?
> >
> >  Yes.  However, for a first implementation, the download should probably
> >  just restart.  This optimization will only be important for activities
> >  with exceptionally high turnover.
> >
> >
> >  > As there has been interest expressed in developing basic OS
> >  > integrated object transfer as a GSoC project, I wonder if those
> >  > efforts could also be applied to this problem, or if this should be
> >  > offered as another distinct project alternative.
> >
> >  Current implementations of file transfer (Read, and therefore
> >  Distribute) work by getting a Stream Tube from Telepathy, and then
> >  running a HTTP server on this tube.  Any near-term implementation of
> >  transferring Journal Entry Bundles or Activity Bundles is likely to use
> >  the same mechanism.
> >
> >  This works, and will work for the proposed case.  For the future, I see
> >  file transfer as precisely the sort of thing that should be handled
> >  internally to Telepathy.  Perhaps Telepathy should implement XEP-0234
> >  (file transfer)[2] or even XEP-0214 (file sharing)[3].
> >
> >  > What do people think?
> >
> >  I think it would not be too hard, and should definitely be on the to-do
> >  list.  It would be a major user-visible milestone in the journey toward
> >  Complete Sugar.  There are several things that have to happen first:
> >
> >  1. Basic activity signing.
> >  2. Pushing SVG files through Presence, so that I can see the icon in
> the
> >  mesh for an activity I don't have.
> >  3. Sane activity storage:
> >  What if the shared session is a newer version of an installed activity,
> >  but it's been modified by someone other than the original author?  I
> >  should then be able to join, but it should be treated as a new
> activity,
> >  not an upgrade, even though it has the same name.  This means we need
> an
> >  activity storage mechanism that can handle multiple activities with the
> >  same name.
> >
> >  Also, all installed .xo bundles must be kept around, or Sugar must be
> >  able to reconstitute them on demand without invalidating the
> signatures.
> >
> >  --Ben
> >
> >  [1]
> http://lists.laptop.org/pipermail/security/2007-December/000341.html
> >  [2] http://www.xmpp.org/extensions/xep-0234.html
> >  [3] http://www.xmpp.org/extensions/xep-0214.html
> >
> >
>
> On Tue, Mar 25, 2008 at 3:40 PM, Michael Stone <michael at laptop.org> wrote:
> > 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.
> _______________________________________________
> Sugar mailing list
> Sugar at lists.laptop.org
> http://lists.laptop.org/listinfo/sugar
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.laptop.org/pipermail/sugar/attachments/20080403/a8e88038/attachment-0001.htm