[sugar] Journal integration design for Measure Activity
Mike C. Fletcher
Mon Oct 22 16:36:57 EDT 2007
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.
* 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
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
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 and Union File Systems 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.
Mike C. Fletcher
Designer, VR Plumber, Coder
More information about the Sugar-devel