[support-gang] Fwd: Redesigning: Library, Read, Get-Books, and Content bundles

[George Hunt]

Gary, Yioyos, Martin,

The trick is to prevent circumstantially malicious co-Activities from doing
harm, without at the same time preventing cooperation between functional
blocks essential to the satisfaction of user needs.

I ran into this issue, when I was writing my python debugger "PyDebug".  I
chose to write a monolithic set of function which incorporated Browse,
Terminal, Pippy, etc. And since we are all essentially individual
developers, this may still be the best approach.  (modifying multiple
cooperating programs, testing and releasing seems larger than a one person
task).

That said, I believe there should be a method whereby cooperating Activities
can share their I/O resources, under proper OS supervision.  One mechanism
might be for the OS to open a socket, provided that both have declared their
willingness to connect with the other in their "permissions.info" file.  I
used this method successfully when I wanted the debugging process to
communicate back to the parent the line number where an exception occurred.
Applied to the multiple Activity situation, each process could expose a
single interface object to the other, with appropriate trapping/checking (I
used the rpyc package).

I share DSD's concern about the problem of the Journal and the list view of
the home page being confusingly similar, and would like the solution to make
library content visible on the home page.  But perhaps one issue at a time.

George

On Sat, Jul 24, 2010 at 2:48 AM, Michael Stone <michael at laptop.org> wrote:

> Gary, Yioryos,
>
> Here are a couple of thoughts for you on isolation issues. (I have thoughts
> on
> the Journal issues too but I'll save them for another occasion.)
>
> >> Step 3 is to introduce marks (hyperlinks?) in Read and Write where
> hovering
> >> over you get the tag opened to tell you what is about, and clicking
> transposes
> >> you to the relevant book/app-mark
> >
> > As noted already this would seem to break Sugars's security model,
> activities
> > need to be sand-boxed from each other, one activity is not allowed to
> resume
> > another. Yea, back to Journal, again! ;)
>
> Let's think about this a bit more deeply. As I see it:
>
> The key idea that Bitfrost offers is that system software needs to make it
> easy
> for the authors of benign apps to protect human interests. (A number of
> useful
> features are then proposed toward this end.)
>
> The key idea that Rainbow offers is that accounts are a good device for
> isolating processes.
>
> Within this problem domain, the key idea of Sugar is that people engage in
> fairly discrete sessions of activity which may be started, stopped,
> resumed,
> and isolated from one another.
>
> Significant isolation is possible because data rarely needs to move from
> session to another and, when it does, the motion may be orchestrated
> through a
> supervisor.
>
> Note, however, that the idea is that it doesn't matter much what actual
> processes run within a given session or whether there are many windows or
> one,
> many documents or none, many hosts contacted or none, etc.
>
> Indeed, we shouldn't worry so much about whether Browse invokes Read in
> order
> to render a downloaded PDF or whether Chat invokes Browse when the human
> operator clicks on a hyperlink -- Browse already had complete control over
> the
> contents and distribution of the PDF and Chat already had complete control
> over
> the text of the URI that Browse will see.
>
> Instead, what does matter is the ability to control what happens *when*
> Browse
> or Chat or Read becomes circumstantially malicious. What matters then is
> the
> ability of the human operator and the system supporting them to manage the
> mappings of I/O resources to sessions -- that is, crudely, of the "start
> new"
> vs. "resume" problem. :)
>
> Thoughts?
>
> Regards,
>
> Michael
> _______________________________________________
> support-gang mailing list
> support-gang at lists.laptop.org
> http://lists.laptop.org/listinfo/support-gang
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.laptop.org/pipermail/devel/attachments/20100724/474a4518/attachment.html>