[sugar] datastore use cases for activities

[Michael Stone]

Note: I am going to completely ignore rate-limiting in the following
analysis.

> == Activity session stops ==
> 
> When an activity session stops, we want to store its state to the
> Datastore so it can be examined later from the journal and it can be
> resumed from where it was stopped.

No security impact.

> Activities need to at least save to the journal an entry with the
> activity session title, the buddies that participated on the activity
> session, an image that visually represents the state of the activity (a
> screenshot, currently), any tags that can help in categorizing the entry
> and the activity-dependent data as metadata properties or a file on
> disk. If the data in the file can be interpreted by other activities,
> the 'mime_type' property should be set.

No security impact.

> For some activities like Record that wish to expose some products of the
> activity session like in this case photographs, videos or audio
> recordings, a journal entry for each of those can be created, specifying
> the right mime type for each of them. In this way, a photograph can be
> modified in Paint, a video watched in Watch&Listen, or an audio
> recording imported in one of the TamTam activities.

With reference to my recent emails, I don't think there's a security
impact here. However, if further clarification is needed, let me know
and I'll attempt to provide it.

> == Activity automatically saves its state ==
> 
> At any point during the activity session, the activity can judge
> necessary to update the entry in the journal. In this way the journal
> can show the state of currently running activities and in case of a
> crash the work is not lost.

No security impact.

> == User presses 'Keep' button in a running activity instance ==
> 
> Same as in the two previous use cases, only that in this case, any
> future saves will be done in a new entry. The current one is preserved
> in the journal as frozen so it can be resumed later in a new activity
> session. This acts similarly as branching in a vcs.

No security impact.


> == A Journal entry is resumed ==
> 
> The activity is started by the journal and an object id corresponding to
> the resumed entry is handled to it.
> 
> The activity will retrieve from the datastore the metadata for that
> object id and the file were data was stored.

... I need to know more about how this actually works to judge the
security impact. The important thing is that activities must not be
granted access to user documents *simply because they know the object's
IDs*. Instead, each time they run, they must explicitly be granted
access through the mechanisms previously described: i.e. by being
resumed, by exercising P_DOCUMENT, or by exercising P_DOCUMENT_RO.

> In cases like Record, querying the datastore by 'activity_id' will
> retrieve the separate entries that make part of this activity session
> (photographs, videos and audio recordings).

See above.

> == User presses 'Insert image' button in a running activity instance ==
> 
> The activity requests sugar that the user should choose a journal entry
> of the type Image (or several).

Instead, I think this should be something like "User presses
Sugar-provided 'Insert Item' button, selects some documents, the
documents are provided, and the activity is notified".

> After the user has chosen one or several entries, the dialog is closed
> and the activity receives the object ids for those entries. Then it can
> request the metadata or files for any of them.

If you really want to have the activity talk directly to the DS, then it
is a security requirement that the DS delegate access-control checks to
Rainbow.

> A similar use case would be for the upload file dialog in Browse. In
> this case all entries that have an associated file should be presented
> to the user. The user should be able to search, filter and sort just
> like in the journal in order to find the entry that will be uploaded.

Activity-provided file selection boxes are explicitly not supported by
the current Bitfrost spec. 

Michael