#6958 HIGH 9.1.0: Need to be able to launch locally installed activities from within browse
Zarro Boogs per Child
bugtracker at laptop.org
Sun Jul 6 12:47:46 EDT 2008
#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:
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
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.
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
More information about the Bugs