[sugar] Journal integration design for Measure Activity

[Tomeu Vizoso]

Hi,

follow some comments on the suggested alternatives from Mike:

On Mon, 2007-10-22 at 16:36 -0400, Mike C. Fletcher wrote:
> 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).

I think (Eben should confirm), that "workspace-oriented activities"
doesn't match quite well with our current concept of Activity. The
journal is intended (not there yet, lots of work left to do) to give a
good browsing experience for all the content that is kept inside the
laptop. So that if the user wanted to find a jokes collection, he would
go first to the journal and find it either by filtering, searching or a
combination of those.

If any activity author thinks that his activity could give a better
experience in browsing all the content created within it, please pass to
us your requests for improving the journal. Preferably as trac tickets.

We also think that a good way to improve this situation is to make it
easier to resume existing entries in the Journal. Mike's ideas below are
good, any other in this direction would be greatly appreciated. But
remember that the user needs to know at every point to which data an
activity is being granted permission.

>     * 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.

This has been discussed, could be implemented for 1.1.

>           o Alternately, launch the Journal with a pre-selection query
>             from the control.

This is scheduled for 1.0. Activity icons in the frame will have an
option in the palette that will show the journal filtered by that
Activity. See #4275.

>     * 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.

If the user wants to start an activity, has he given it the permission
to access the last activity instance data? The user should remember
which was the last thing he did in that activity before using that
option?

Tomeu