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