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

[Nate Theis]

Hrmm. Now what if, instead of a socket (which is a kernel-level thing and
thus harder to regulate), each activity gets

A. Telepathy tubes, for real-time communication. (Activities already have
this, we just need a "directory" service that lets activities find other
activities' tubes. *but only tubes marked as Public. Maybe you "submit" the
tube to the directory?*)

B. A world-readable, owner/group-writable (chmod 664) public directory, like
the instance, data, and tmp directories. For things like the TamTam
instruments... (Try to make this noexec, to avoid the obvious issues)

This would all be relatively easy to do...

Benefits:

   - Telepathy tubes means intra- and inter-XO sharing of data
   - World-readable, group-writable, noexec directory lets things like
   TamTam sharing, etc take place
   - *Easy to implement!*

--Nate


On Sat, Jul 24, 2010 at 9:09 AM, George Hunt <georgejhunt at gmail.com> wrote:

> 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
>>
>
>
> _______________________________________________
> Devel mailing list
> Devel at lists.laptop.org
> http://lists.laptop.org/listinfo/devel
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.laptop.org/pipermail/devel/attachments/20100724/0e9bad4a/attachment.html>