[prev in list] [next in list] [prev in thread] [next in thread] 

List:       e-lang
Subject:    [E-Lang] Caplet Launcher issues
From:       "Marc Stiegler" <marcs () skyhunter ! com>
Date:       2000-11-30 19:15:29
[Download RAW message or body]

> I'm unclear about some of this. Suppose you use the launcher to start a
word
> processor on a "single document" and all is well. Then you run the spell
> checker and you add a few words to your custom dictionary. How does the
app
> save your dictionary if it only has the authority to write the main
> document?  Lots of similar examples occur with "office" applications.
> Another example, is that I find it convenient that when I start MS Word
that
> it shows me a list of the most recent files I've loaded so I can more
> quickly indicate which file I want. But that list needs to be stored
> somewhere...

Great questions! You're right, this 5-line launcher doesn't deal with these
issues (dictionaries and most-recently-used docs). As I said in my PS, there
are things that are left out of the 5-line launcher. Solving the problems
you raised requires additional machinery, some simple, some not, as
described below:

Read access to a standard dictionary is a simple additional authority you
would pass in. Granting write access to a file like the custom dictionary
that spans multiple sessions and multiple documents, and perhaps even
multiple apps, can open a data leak, so it is trickier and requires a more
sophisticated interaction with the launcher. The launcher must evolve into a
capability-manager to handle this (and to handle even fancier problems, the
capability-manager must evolve into a desktop environment, which is a pet
enthusiasm of mine, a capability-secure desktop). Part, though not all, of
the answer with the custom dictionary lies in storing the custom dictionary
with the doc itself (which lies within the capabilities in the launcher as
it stands), and being able to reuse that doc as a template for other docs
(which depends on using facilities outside the 5-line launcher, and has some
security issues itself--do not use your CIA classified documents as
templates for your emails to your mother!).

Drag-drop, by the way, is a very fine capability metaphor, and could be used
to allow a single caplet to work on multiple docs simultaneously (and to
implement cut/copy/paste across those documents, using a clipboard internal
to the caplet that avoids the security issues of the system clipboard). The
launcher as written allows drag-drop (though as written it allows so much
access to swing and awt that the security implications are unknown and
therefore awful, as markm pointed out earlier).

For the list-of-recent-files, if you want to be fierce in your application
of capabilities (and who doesn't want to be fierce? :-) the list must be
remembered by the launcher; the caplet would request that the launcher
present the list, and forward to the caplet the capabilities on files
selected by the user. For this particular example, I think we may be asking
the wrong question. On a meta-level, I would prefer to answer the question,
how must desktops be enhanced so that  applications no longer need to be
supplying file-system information, i.e., how do we finally get from an
application-centric universe to a doc-centric one? But until this question
is answerable, the extension to the  launcher to handle the
most-recently-used list is pretty straightforward, though it takes a few
more lines :-)

As a less fierce interim solution for those who worry only about viruses and
not about data leaks, you could pass the caplet read/write authority to a
permanent directory that the caplet could use for storing preferences and
custom dictionaries. With this strategy, the caplet could store its own
custom dictionaries. You could still buy an evil word processor from the
developer of BackOrifice and still keep your e-gold and PayPal accounts
safe. But if even once you used the evil word processor for handling CIA
documents explaining who really shot JFK, you could absolutely not ever give
it authority to access the Internet (whereas, without the permanent
directory, you could even give the evil word processor Internet access when
writing letters to your mother). A programmatically simple, though not
user-intuitive, solution for mixed CIA+mother word processing would be to
grant the word processor preferences directory authority when writing
mother, and refuse preferences authority when writing for the CIA (or give
it only preferences-read-authority on CIA docs, no write authority).

Here you see the beginnings of the work to fully separate caplet
functionality from launcher functionality. My preliminary thoughts suggest
another interesting separation is the difference between capability leak and
data leak. From the perspective of user intuitions and user interface design
I believe  that preventing capability leak may be mostly straightforward (of
course, I am eager to hearing counterexamples. Window forgery is the only
one I know of, and I have preliminary ideas for solving that). This would
make the world safe from viruses and such, which desire capabilities. But
maximal prevention of data leak will require some innovations.

--marcs

_______________________________________________
e-lang mailing list
e-lang@mail.eros-os.org
http://www.eros-os.org/mailman/listinfo/e-lang

[prev in list] [next in list] [prev in thread] [next in thread]