[E-Lang] what is good about E?

[Mark S. Miller]

[I quote from Ken out of order below.  --MarkM]

At 05:26 PM Tuesday 7/24/01, Ken Kahn wrote:
>Going back to your IE5 example, suppose that Netscape wasn't already
>installed. Shouldn't it automatically associate HTM with IE? Or should it
>get your permission?
>
>I agree that capabilities are a nice way to think about what an installation
>script does but I'm not sure I see a connection with E.

Your message seems to assume we're simply trying to admonish installer 
writers such as yourself to ask for authorization instead of assuming it 
silently.  The issue is not "What should the IE5, Netscape, or Toontalk 
installation script do, in order to balance politeness vs convenience?".  In 
all these examples, these installers run on an insecure OS (Win9x, WinME) or 
one with a bad security architecture (Unix, WinNT), where installers are 
normally given the equivalent of root authority.  This puts the machine 
fully at the mercy of the installer (and the installer's manufacturer, and 
the installed software) forever, or until they wipe the disk and do a fresh 
reinstall of their OS from floppy.

No.  The issue is, instead, to create a secure framework in which you don't 
have to entrust each installer with your life.  Rather, like Alice's 
Amplifier, it must be easy and intuitive, on unpacking the new device to 
live in your home (and its new home), to deliberately give it access to 
certain things it says it needs, or not, depending on how the user reacts to 
the reasonableness of what it says it needs.  Alice deciding not to give the 
Amplifier access to her telephone line is exactly parallel to MarcS's story 
http://www.skyhunter.com/marcs/ewalnut.html#SEC40 of why Melissa would never 
have spread in a capability world.  If you change this story so that 
one-click installation is the normal case, and the one click normally grants 
the installer full authority to install itself as it likes, then even if 
everything else is our most perfect fantasy security architecture, we're 
still toast.

So I'll use your example -- installing Toontalk.  The issue is not, what 
should the Toontalk installer do?, but, "If Toontalk were being installed as 
a capability-based application inside a capability secure framework, what 
could it do?  And within these constraints of what it could do, what should 
it do?"

There are five capability frameworks where we might want to consider this 
question:


* On KeyKOS, which worked through solutions to all these issues, but in a 
command line environment not designed for grandmothers.

* On EROS, which is in the KeyKOS tradition, but must work out solutions 
palatable in the modern GUI/ease-of-use world.

* In the secure user-interface framework presented by 
http://www.cs.berkeley.edu/~pingster/sec/project/ , which specifically 
focused on the usability issues of interacting securely with partially 
trusted apps, and specifically on the issues relating to install-time 
authorization decisions.  In desperation for a name for this proposal, for 
the moment I call this after its most striking visual feature -- the RedWire 
system.  (These wires serve very much the same purpose as in the fable of 
Alice's Amplifier.)

* In E and the upcoming CapWT (Capability Windowing Toolkit) and its support 
for installing caplets (Capability-based applets) that ask the Powerbox for 
the capabilities it needs ("I need a left speaker").  The Powerbox is a part 
of the TCB that then interacts with the user.

* In Toontalk itself, when Bob considers running a thought balloon received 
from Alice.


While each of these and various combinations are all interesting to examine, 
I'll switch back and forth between two: RedWire on EROS, and 
E/CapWT/caplets/Powerbox.  Much of this examination consists of speculation 
and fantasy, as none of these systems but KeyKOS have fully worked out 
answers to these questions (we're working on it), and KeyKOS's answers as is 
are not acceptable from a usability-by-grandmothers perspective.

(In case there are any grandmothers reading this.  No offense meant by the 
stereotyping.  Until better language develops, often a stereotype is the 
most effective means of bringing forth a shared vivid image of a kind of 
person we're all familiar with.  We're trying to make the world a better 
place for, among others, these people that we're so awkwardly trying to 
designate.)


>I too think about the grandmother type. But I don't think it is this simple.
>When I wrote the installation script for ToonTalk I worried about these
>issues. Should I make an association with a unused extension without asking?
>(I agree it is rude to take over an extension in use without asking.) 


                         CapToon:  Toontalk as a caplet


As a caplet, you could not.  A caplet starts off being granted only the 
authority to 1) render itself into its pane on the screen, 2) to receive ui 
events directed at that pane (mouse motion in that pane, drag motion whose 
down-click was in that pane), 3) keystrokes that occur while that pane has 
the focus, and 4) access to a Powerbox, which it can ask for particular 
authorities.  The Powerbox then asks the user to authorize or provide those 
authorities.

Unfortunately, grabbing desktop extensions is one of the ugliest examples, 
as these are that worst of all things -- a global name space -- but here 
goes.  You would provide to the powerbox a list of all the extensions you 
want to grab in one request, including all the names in all the namespaces 
that you need in order to do so.  These are all provided in one request for 
usability purposes: The powerbox can then present the user with a single 
dialog box with a matrix, where each authorization is a proposed name and an 
initially-on checkbox in the matrix.  Each column of the matrix is an 
extension that you propose to grab, and each row is a namespace from which 
you need to grab a name.  Each cell should also indicate to the user (not the 
caplet) if there's already a conflicting use of the proposed name in that 
row's namespace.

For Windows, I count three rows/namespaces: 

1) The extension itself -- ".html", ".txt"

2) I'm not sure what to call it, but I'll call it the "Windows type".  In 
the registry, the extension is looked up to find this name, and then this 
name is looked up to find most everything else.  In my registry, the 
respective associations are "Opera.HTML" (now you know what my default 
browser is) and "txtfile".

3) The Mime Type (called on Windows the "Content Type"), which in my system 
are respectively "text/html" and "text/plain".

In addition, if you aren't allocating a new Windows type to yourself, but 
adding menu entries to an existing one, then each added menu-item name would 
also need to be authorized.  If you want one of your menu-items to be the 
new default (the one launched on double-click), which is often the point of 
the whole exercise, then that would need to be authorized as well.

The icon choice functions effectively as a namespace of a sort, so perhaps 
it should be part of this interaction as well.  I find it hard to think 
about this one.


The powerbox, by presenting all these on one dialog with individual 
initially-on checkboxes, allows the user to scan all these authorizations, 
approve them en-masse by just hitting ok, or approve or disapprove them 
individually before hitting ok.

Note that the above story ignores yet another ugly fact: It treats the 
correspondence of extensions, Windows types, and Mime types as one-to-one.  
They certainly aren't.  I don't know what to do about that while maintaining 
usability.  This last issue may push this design over the edge of the 
usability cliff.  At least there's a sane long term answer, but not for 
stock platforms.


               Toontalk on RedWire/EROS, and Pet Extensions


Of course, the whole notion of extensions as a global name space is corrupt. 
We can never have a good answer to this issue until we rid ourselves of 
this notion.  There are two ways to think about extensions, and each 
suggests something different to do instead.

* The extension is effectively the document's behavior pointer, much like a 
Smalltalk or Java object's class pointer, or a C++ or E object's vtable 
pointer.  Compared to our desktops, Smalltalk, Java, C++, and E all have 
this right: the behavior pointer is an inherent first-class part of the 
object's encapsulated state.  A "document" is really just an instance of an 
application.  On RedWire/EROS, an instance of an application would just be a 
persistent process (or set of processes), and the "document" would just be 
one of the start keys.  The presentation of the document, both icon and 
filename/extension, would just be according to the documents behavior.  It 
would be alleged, in just the logic of the "allegedType" query.  The 
user's sense of "document" may be most like the Lisa, even though the 
particulars are all different.  (This solution should also be available for 
E, for persistent E objects themselves, so long as we're not trying to 
figure out how they can appear on the desktop of the underlying stock 
platform.)

* The file is not an instance, but is open data allegedly in some 
interoperable data format, like ".html" or ".txt" above.  For this, the 
extension really serves the same function as the Mime type.  However, we 
solve nothing by saying "let's use Mime type instead".  Mime types are also 
a global name space, and so are equally unworkable and corrupt.  For this, I 
think we can adapt the Pet Name system 
http://www.erights.org/elib/capability/pnml.html .

Each mime-type-like type tag becomes a globally-unique but unreadable bit 
string, such as the hash of the canonical document defining this particular 
data format.  These would never accidentally collide, and the same type tag 
could never designate two definitions.  Then the extension to show for a 
given type tag on a given desktop would just be that user's pet extension 
for that type tag.  As with Pet Names, there could be a nick-extension 
system, which are used as the default pet-extension in the absence of a 
conflict.  This allows the first app that introduces the html type to your 
desktop to, by default, cause it to be called ".html" as a pet-extension 
without further before-the-fact prompting.  But the application can't tell 
what it's currently called on any particular desktop.  That's between that 
desktop and its user.


>How should I make tradeoffs of speed vs. disk space consumed?  

In the caplet environment, I don't expect to see us try to throttle either 
space or time when running on stock OSes.  To do this well, you really need 
OS support we don't have.  Instead, E has always said "We're vulnerable to 
denial of service attacks, including resource exhaustion attacks."  So 
however you may decide to make such tradeoffs is up to you.  We won't try to 
enforce any better behavior.

Making a transition from no OS support to essentially perfect OS support, 
EROS provides essentially perfect means to control the authorization of 
resource use, and essentially perfect foundations for agoric computation 
among mutually suspicious entities.  When installing under RedWire/EROS, 
Toontalk should be able to state its resource requirements, and the user 
should be able to make a decision about provisionally granting them.  But 
the user still owns their resources and can take them back.  Program 
termination in KeyKOS and EROS is normally by resource eviction.  I 
currently have no idea how to usably present this to the grandmother.


>Should I, as
>Microsoft suggests and my own testing indicates is a good idea, update
>Microsoft facilities such as DirectX? (I recommend it but ask first.)

I don't know anything about DirectX, but I assume this means something like 
"May I upgrade your OS?"  If so, it's a sufficiently big topic that we 
should deal with it separately.


>I've read several reviews of consumer software where the reviewer was
>pleased at the ease of the "one click installation" and others that
>complained an installation was too complex and asked too many questions that
>a "grandmother type" has no clue how to answer.

These reviewers may dislike both the CapWT desktop and the RedWire/EROS 
systems described.  Again, it depends how hostile the world becomes to those 
who operate insecurely.  Absent dangers, our cars, homes, and bank deposits 
would all be more usable if all safety measures (like doors, keys, and 
locks) were removed.  But consumers, including grandmothers, put up with the 
usability costs of doors, keys, and locks anyway.  Indeed, doors are a mass 
market consumer success.  Keys and locks haven't done too badly either.


>I ended up following the Windows convention of offering 3 choices: 1.
>typical (default that automates most choices), 

Wouldn't be possible.

>2. minimal (which does as
>little as possible but the software may not run as well) 

Even this would often require some authorization decisions.

>and 3. custom
>(where you have fine control over most choices).

Let's not assume this will necessarily be hard to use until more thinking 
has been invested into making it be easy.  To date, only three people 
(Miriam, Ping, MarcS) have ever tried to attack these problems, with very 
little total time invested so far.  Their work has already shown that secure 
interaction can be miraculously more usable than we had any reason to 
expect.  You are certainly a very serious UI designer. I'd love to see what 
you come up with.


        Cheers,
        --MarkM