#6958 HIGH 9.1.0: Need to be able to launch locally installed activities from within browse

[Zarro Boogs per Child]

#6958: Need to be able to launch locally installed activities from within browse
---------------------------+------------------------------------------------
   Reporter:  BryanBerry   |       Owner:  mstone 
       Type:  enhancement  |      Status:  new    
   Priority:  high         |   Milestone:  9.1.0  
  Component:  sugar        |     Version:         
 Resolution:               |    Keywords:  9.1.0:?
Next_action:  never set    |    Verified:  0      
  Blockedby:               |    Blocking:         
---------------------------+------------------------------------------------

Comment(by bemasc):

 Replying to [comment:8 bert]:
 > What actual harm could there be in instructing Sugar to launch an
 already installed activity as if we had clicked the activity icon?

 There are a number of reasons why we cannot provide a simple direct-launch
 system that allows one activity instance to launch another without user
 intervention.

 1. Security
 1a. Resource exhaustion attacks
 Although it is not yet implemented, Bitfrost explicitly contains a number
 of protections designed to prevent Activities from crashing the system by
 using up memory, CPU, network bandwidth, etc.  If Sugar provides an API
 for directly launching other activities, I can easily make a program that
 crashes the system by launching 1000 instances of Browse.

 1b. Data revelation attacks
 Our conception of Activities has long been that they are like blank
 canvases, and the interesting data is stored in the Journal.  Thus, for
 example, it is totally uninteresting to spawn an instance of Read without
 any contents.  What you want is to spawn an instance of Read, opening a
 specific ebook from the Datastore.  If Activity A does not have access to
 datastore object D, then it may simply launch another instance of A in the
 mode of "resuming" D.  This second instance might, for example, share D
 over the network.

 1c. Privilege combining attacks
 An activity that does not have permission to use the network may cause
 data to be sent over the network by repeatedly launching an activity that
 performs network communication on startup.  This can even be used as as
 side-channel network communications mechanism, using Morse code or similar
 on the startup time of the secondary activity.

 2. Design problems
 2a. Multiple versions
 Our plans for future Sugar explicitly permit multiple distinct Activities
 to be installed under the same name.  They may be distinguished by
 version, or by cryptographic identifiers.  Conversely, there may be no
 Activity installed under a particular name, but several user-created
 variants under different names that are functionally similar.  Only the
 user can decide which Activity merits opening at a given time.

 2b. Surprise
 If one activity instance can launch another at any time, this can create a
 very surprising situation for users, in which Activity instances are
 created out of nowhere, without any indication of who created them or why.
 It seems to me that part of the goal of the Sugar design is to provide a
 predictable, comfortable environment by preventing Activity authors from
 committing certain egregious crimes against usability.

 > Why can't there be a less intrusive way to open another activity?

 I agree that the current state of affairs is suboptimal.  I would say,
 "why can't there be a more convenient way to open another activity?".  I
 would like to make two arguments:

 1. Based on the above issues, the user must be given an opportunity to
 explicitly confirm any Activity launch.  This means that launching an
 Activity from Browse would require a minimum of two clicks.  The user
 would click on an "open eToys" hyperlink, and then again in a Sugar-
 provided launch confirmation dialog.

 2. The method I have proposed, of downloading an appropriately typed file,
 requires three clicks: one on the hyperlink, one to switch to the file's
 Details page in the Journal once the download completes, and one on the
 "resume" button in the Journal.

 If you would like to save the additional click, perhaps Browse could be
 patched to automatically bring up the Details page for any downloads from
 hyperlinks marked rel="autolaunch".  This would save one click.

 If you would like to save the creation of a datastore object, then perhaps
 the downloaded object should be "invisible", and be garbage-collected once
 both Activity instances close.  However, given that every Activity
 instance is to be associated with a datastore object, I don't see this as
 a significant overhead.  The downloaded object can also provide useful
 things like a default title for the instance and any other parameters.

-- 
Ticket URL: <http://dev.laptop.org/ticket/6958#comment:9>
One Laptop Per Child <http://laptop.org/>
OLPC bug tracking system