[sugar] Journal integration design for Measure Activity

[Antoine van Gelder]

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

*ponder*


> 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)


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


Tx!

  - a


-- 

"Any organization that designs a system (defined broadly) will produce a
  design whose structure is a copy of the organization's communication
  structure."

  - Melvin Conway