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 _______________________________________________ Sugar mailing list [email protected] http://lists.laptop.org/listinfo/sugar
