[sugar] Journal integration design for Measure Activity

[Mike C. Fletcher]

Antoine van Gelder wrote:
...
> The JokeMachine activity is a good example of an activity where 'resume' 
> by default makes sense.
>
> In this activity children can enter and read jokes in a list of various 
> joke books (Knock Knock Jokes, Riddles, Cheese? etc.)
>
> Should they exit the activity and start it up again the 
> NaturalThingToExpect(tm) is to see your joke books in the state you last 
> left them, rather than a blank slate which you must populate with new 
> joke books.
>   
Please consider the security implications of this.  BitFrost is designed 
with the idea that the only way to access information in the Journal is 
by having the child explicitly authorize the Journal to grant access to 
the information.  That separation is (partially) to prevent subversion 
of a program at time N from allowing the subverted program access to all 
content created at time M<N without explicit authorisation.  If all 
activities are automatically choosing some random (as far as the 
security system is concerned) journal record to access and being granted 
that access, you have lost the protection.

To underline the issue, the particular activity described, collecting 
and sharing jokes is one which can quite conceivably be very 
security-sensitive.  If the jokes in question happen to be political in 
nature (or religious, or whatever), having a subversion of the activity 
at some point allow some external actor access to every joke you've ever 
told might be very painful.

If you need the workspace metaphor, that's fine, but I'd be wary, for 
instance, of allowing access to the history of all jokes (even those 
that were deleted by your parents because they were 
inappropriate/dangerous) to be accessible by default.  That is, the 
document of "my current joke collection" might be something that you 
want to be auto-loading, but the trace of undo/redo might *not* be 
something you want available after that new software update from the 
people who just took over your government.  If you allow unfettered 
access to the Journal (even if just the current activity's entries), 
then the activity can be subverted to act against you at any time.

Suggested approaches:

    * Provide a mechanism in the Journal to flag a given entry/file as
      "time-shared" with its future instances
          o Activities which are "workspace-oriented" in nature (mail
            clients, joke-collection managers, photo managers) would
            mark their stored "workspace" items as time-shared, and
            would automatically attempt to load the last record in the
            Journal.  That would require an extra API in the Journal to
            allow safe (non-metadata-leaking) requests to retrieve lists
            of the time-shared values.
          o Activities which are "document-oriented" in nature (word
            processors, audio-file editors, video editors, etc) would
            only mark their "settings" (or a subset of them) as
            time-shared, and would attempt to load them automatically,
            while not restoring the last-run-file(s).
    * Provide a shell-level UI control on each frame activity icon.
          o On clicking (or hovering) it brings up the Journal set
            produced by that activity (say the last 15 entries from the
            activity) to be directly launched.  That is, a recently-used
            Journal-list for each icon, but the default would still be
            to create a new instance without access to your previously
            created files.
          o Alternately, launch the Journal with a pre-selection query
            from the control.
          o These are both intrusive (first less than second), but they
            require minimal changes and only the shell itself has access
            to the journal here, so doesn't require any major changes to
            the journal or security system
    * Provide just a BitFrost protection "P_LAST_USED" that signals that
      the application should always be given access to the latest
      Journal entry from that activity (all other access (i.e. switching
      workspaces) would require explicit authorisation)).  This
      effectively just prevents "random" choice of Journal records, and
      reduces the attack surface to just the last items stored.  Of
      course, information-leakage attacks are generally the most
      valuable with recent data, so it's not a perfect solution.
    * Most activities would only need access to the last item, so we
      might have two permission bits for "P_LAST_USED" (just the one
      entry) and a more permissive one for "P_TIME_SHARED" (all
      time-shared entries made available, obviously assumes that there
      is some way to mark a given item time-shared)
    * Restrict workspace time-sharing to a single version of an activity
          o Mitigates some threats (e.g. updates from a new government
            that report back on all children's jokes)
          o Makes for some annoyance in rapidly-updating software,
            particularly as the UI of a persistent-environment activity
            likely won't be optimised for choosing a workspace in which
            to work.

None of those approaches would prevent a child from choosing an older 
workspace if they wish, and they would allow activities to choose 
whether auto-restore-workspace or new-workspace is their appropriate 
mode of operation (heck, we could even let the child decide with some of 
those options ;) ).

BTW, Journal and Overlays[1] and Union File Systems[2] have a fairly 
extensive discussion of Journal issues like this, though in the context 
of a less intrusive Journal design intended more as a global (i.e. *all* 
linux desktops, not just the XOs) approach that makes it easier to port 
software.  Many of the ideas are still applicable, e.g. the need to be 
able to mark sets of data for prioritized treatment, allowing 
suggestions for alternate storage/backup strategies, that kind of thing.

Take care,
Mike

[1] http://wiki.laptop.org/go/Journal_and_Overlays
[2] http://wiki.laptop.org/go/Union_File_Systems

-- 
________________________________________________
  Mike C. Fletcher
  Designer, VR Plumber, Coder
  http://www.vrplumber.com
  http://blog.vrplumber.com