[sugar] Journal integration design for Measure Activity
Antoine van Gelder
Tue Oct 23 01:28:44 EDT 2007
Mike C. Fletcher wrote an awesome analysis of security implications of
persisting application state across sessions.
> 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.
This is great Mike !
As it happens JokeMachine in particular only persists the state of the
current joke collection - i.e. if you delete a Joke from the collection
and activity.write_file() is called on the activity then that Joke is
gone for good. (Non-withstanding forensic recovery of flash drives :-D)
The generic point you're making however of automatically loading up old
Journal data without the child's explicit say-so makes sense to me though.
As I understand it your point is that starting the activity from the
frame should _not_ be an implicit authorization to open up an arbitrary
journal record. (as opposed to explicitly calling up specific content
from the Journal interface.)
> Suggested approaches:
<schnipped sundry recommendations to platform folk />
> * 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.
For my particular use-case of Joke Machine this would be a very workable
solution as it would be clear to the child that there is a difference
between her starting the activity vs. restoring journal content and
allows for easy access to multiple Jokebook collections. (jokes in
English, jokes in Klingon, naughty jokes, clean jokes)
>  http://wiki.laptop.org/go/Journal_and_Overlays
>  http://wiki.laptop.org/go/Union_File_Systems
"Any organization that designs a system (defined broadly) will produce a
design whose structure is a copy of the organization's communication
- Melvin Conway
More information about the Sugar-devel