Post by David Wagner Post by David Hopwood
- Confine the browser (and any other application with direct internet
access) that is used for 'skinnydipping'. It should already have been
designed to be confineable, along similar lines to the DarpaBrowser.
- Add a hook to the browser's powerbox so that is unable to write
anything outside its own private file area, unless it has been
virus-checked. This can be implemented by wrapping any directory
capabilities returned to the browser.
I like this, as a starting point for discussion.
- Does this mean that the browser instance I use to browse the
public Internet cannot share any settings or preferences with
the browser instance I use when connected to my intranet?
No, it can share settings. To make sure that these settings cannot be
used as a channel between instances, we can do something like this:
- there is a settings editor UI which is a separate component to the
rest of the browser. The confined instances never write to the settings
directly; they just have read-only access, plus the ability to make
the settings editor appear when the user asks for it (and it is not
- the settings editor has the ability to display a (labelled) window,
and its interface essentially acts as a function from old to new
settings. It doesn't need, and therefore doesn't have, any network
or filesystem access.
With two browser instances, the information flow in this system is:
.----------------> [ user ] <----------------.
| ^ |
v | v
[ Internet ] v [ intranet ]
[ browser ] <---- [ settings editor ] ----> [ browser ]
^ | | ^
| | | |
| '---------> [ virus checker ] | |
| | | |
| v | |
| [ filesystem ] <-----------' |
( Internet ) <-------> [ VPN bridge ] <------> ( intranet )
Note that information cannot get from the network cloud to the filesystem
- via the virus checker;
- via the VPN bridge;
- by the user cutting and pasting (or retyping) between applications.
I think that cutting and pasting is probably out of scope for this problem,
although it could be addressed in something like the EROS Window System
I imagine that a capability-based desktop environment would already have a
framework implementing the above, because it is such a common requirement to
be able to share settings between otherwise confined application instances.
(The problem statement begs the question of why you would not want the files
saved by the intranet browser also to be virus checked -- bearing in mind
that false positive virus indications are quite common, and would need to be
overridable by the user in any case. But hopefully the advantage of being
able to prevent direct communication between application instances, while
still allowing them to share settings, is clear in any case.)
Note that routinely separating the settings editor for each application from
the rest of the app has some other advantages: it would make it easier to
manage (back up, roll back, share between user accounts, limit according to
organisational policy) settings in a uniform way for all applications.
This could well improve usability, compared to the mess of settings handled
differently by each app in current operating systems.
Post by David Wagner
In essence, I have to configure every network application twice,
and manually synchronize them? I can see some ways how one
might avoid that, but they may require modifying every network
application that I might use while connected to the Internet.
- Doesn't this require modifying (the powerbox part of) every
network application that I might use while connected to the
public Internet, to support this sort of virtualization?
That's why I said 'add a hook to the browser's powerbox'. Running some
boolean predicate on file contents before allowing them to be saved is
such an obviously useful facility, then we can reasonably expect it to
have been anticipated. (In fact, it's insane that virus checkers don't
already work that way.) If we have more than one predicate to run, we can
'and' them without requiring them to have knowledge of each other.
In any case, the powerbox that needs to be changed/hooked here is logically
part of the shell, not of the app.
David Hopwood <***@blueyonder.co.uk>