From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <1474129398.70526.YahooMailMobile@web161803.mail.bf1.yahoo.com> Date: Sat, 17 Sep 2016 09:23:18 -0700 From: Chris McGee To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-2037608182-449245065-1474129398=:70526" Subject: Re: [9fans] Questions on the browser as a platform if plan 9 had gained marketshare Topicbox-Message-UUID: 9ef63ddc-ead9-11e9-9d60-3106f5b1d025 ---2037608182-449245065-1474129398=:70526 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Hi,=0A=0AI have been pondering the same kind of thing myself lately. In an = alternate bizarro universe, what would the web look like that is modelled m= ore around plan 9 concepts. Here's my fantastic take on this.=0A=0AFirs= t, there is a focus on simplicity of implementation and interface over flas= hiness of UI. As a result, services are much easier to use directly rather = than having to rely on html/js UI's. You just mount search engine, rout= e planning tool, or even shopping site and echo commands into the ctl file.= And you get back results as numbered files with simple text output. User d= oesn't accidentally run malicious software embedded in the service. It&= #39;s all just 9P.=0A=0AIf a service is complex enough, due to complexity o= f the problem it is trying to solve (not invented complexity). Source code = is posted on the service in C source code form. User runs mk, which is supe= r fast because the compilers are optimized for this. They run the program i= n a rfork+rio sandbox. Users quickly learn how simple this is and do it reg= ularly so that in trusted programs don't have access to what they shoul= dn't. The process isn't automatic so it doesn't happen without = user knowledge. Pop ups and such are not possible.=0A=0AUser wraps the conn= ection in tls if they don't want any snooping. Sensitive services such = as banking don't allow unencrypted sessions.=0A=0AURL's are just re= lative paths, navigable using acme and plumber. Absolute links to sites don= 't exist since the user can map their namespaces any way they choose. I= nstead, documents may give 9P connection information and locations. Cross s= ite linking becomes very clear. To facilitate ease of navigation and discov= ery services pop up to curate documents with nice easy relative linking wit= hin that service.=0A=0AMultimedia documents with both pictures and text are= compiled into self contained files kind of like PDF without hyperlinks and= arbitrary code expectation. Links between documents are relative paths as = above. Users are accustomed to using simple text or even markup/markdown fo= r most things. This rich format is for longer and more focused reading sess= ions: studying a topic, leisure reading.=0A=0AImplementers of Internet serv= ices have a strong focus on simplicity of implementation and interface, but= also in adopting common conventions. For example, a ctl file where you sen= d commands and numbered directories with results of each invocation. Perhap= s a new convention could be to include a readme file and maybe man page wit= h details about how to use the service. Also, services are designed to be f= ocused enough and standard enough that they can be easily interact with oth= er services using pipes, redirects, etc. so that the user can combine them = to suit their needs.=0A=0AServices take advantage of the simplicity of plan= 9 and 9P to easily sandbox, proxy and load balance their services. Also, c= ommodity and mixed architecture systems are easily integrated for free or n= ew services that are built with whatever hardware they can find.=0A=0ASingl= e signon is achieved using symmetric encryption. If the service recognizes = your public key and you are able to sign a message using your private key y= ou can proceed. Not sure how much overlap there is here with what is in tls= and factotum. Something like factotum could be useful to allow you to spec= ify different keys (identities) for different services. The point here is t= hat authentication is in the user's control and not the service. The us= er ever only needs to remember one password or store their thumbprint in on= e place.=0A=0AThat's all I have so far.=0A=0AChris ---2037608182-449245065-1474129398=:70526 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
Hi,

I have been pondering the same kind of thing myself= lately. In an alternate bizarro universe, what would the web look like tha= t is modelled more around plan 9 concepts. Here's my fantastic take on this= .

First, there is a focus on simplicity of implementation and in= terface over flashiness of UI. As a result, services are much easier to use= directly rather than having to rely on html/js UI's. You just mount search= engine, route planning tool, or even shopping site and echo commands into = the ctl file. And you get back results as numbered files with simple text o= utput. User doesn't accidentally run malicious software embedded in the ser= vice. It's all just 9P.

If a service is complex enough, due to c= omplexity of the problem it is trying to solve (not invented complexity). S= ource code is posted on the service in C source code form. User runs mk, which is super fast because the compilers are optimized for this. They run= the program in a rfork+rio sandbox. Users quickly learn how simple this is= and do it regularly so that in trusted programs don't have access to what = they shouldn't. The process isn't automatic so it doesn't happen without us= er knowledge. Pop ups and such are not possible.

User wraps the = connection in tls if they don't want any snooping. Sensitive services such = as banking don't allow unencrypted sessions.

URL's are just rela= tive paths, navigable using acme and plumber. Absolute links to sites don't= exist since the user can map their namespaces any way they choose. Instead= , documents may give 9P connection information and locations. Cross site li= nking becomes very clear. To facilitate ease of navigation and discovery se= rvices pop up to curate documents with nice easy relative linking within th= at service.

Multimedia documents with both pictures and text are compiled into self contained files kind of like PDF without hyper= links and arbitrary code expectation. Links between documents are relative = paths as above. Users are accustomed to using simple text or even markup/ma= rkdown for most things. This rich format is for longer and more focused rea= ding sessions: studying a topic, leisure reading.

Implementers o= f Internet services have a strong focus on simplicity of implementation and= interface, but also in adopting common conventions. For example, a ctl fil= e where you send commands and numbered directories with results of each inv= ocation. Perhaps a new convention could be to include a readme file and may= be man page with details about how to use the service. Also, services are d= esigned to be focused enough and standard enough that they can be easily in= teract with other services using pipes, redirects, etc. so that the user ca= n combine them to suit their needs.

Services take advantage of the simplicity of plan 9 and 9P to easily sandbox, proxy and = load balance their services. Also, commodity and mixed architecture systems= are easily integrated for free or new services that are built with whateve= r hardware they can find.

Single signon is achieved using symmet= ric encryption. If the service recognizes your public key and you are able = to sign a message using your private key you can proceed. Not sure how much= overlap there is here with what is in tls and factotum. Something like fac= totum could be useful to allow you to specify different keys (identities) f= or different services. The point here is that authentication is in the user= 's control and not the service. The user ever only needs to remember one pa= ssword or store their thumbprint in one place.

That's all I have= so far.

Chris
=0A
=0A
=0A =
=0A
=0A=
=0A <= b>=0A From:= =0A =0A Ma= rshall Conover <marzhall.o@gmail.com>; =0A =0A To:=0A = =0A <9fans@9fans.net>; =
=0A = =0A Subject:=0A =0A = [9fans] Questions on the browser as a platform if plan = 9 had gained=09marketshare
=0A = =0A Sent:=0A =0A = Sat, Sep 17, 2016 3:19:51 PM
= =0A
=0A
=0A = =0A =0A = =0A =0A = =0A = =0A
Hi all,

=A0=A0 For context, I am a plan 9 novice - I've p= layed around just enough to add jury-rigged background-image support for ri= o (for better or worse), implore sl - if I remember correctly - to add the = ^B option to 9front's rc that brings the cursor to the current input pl= ace, and, for what it's worth, create this: http://i.imgur.com/6iiF= 3zi.png.

=A0=A0 I've been wondering about how the web = - specifically, the browser as a platform for applications - would have bee= n different had plan 9 become a significant influence in operating systems = in the early 90s. I've come to the point where I thought a discussion h= ere might be enjoyable and enlightening, hopefully even to the point of dis= pelling the playful ribbing that this mailing list may or may not be dead. If this conversation has al= ready occurred, my apologies.

=A0 The improvement I think plan= 9 could have brought to the early web is in allowing the browser to have r= emained, as I understand it to have been,=A0 a medium for mark-up text and = images, and have the OS act as the platform for web applications.

The process I'm thinking of would be, with the example of a banking= application: the user opens the bank's web page in a plan 9 browser; t= he user clicks a 'login' link; that link is sent to the plumber, wh= ich detects it as a web application link and directs it to a service which:=
- sandboxes it, perhaps by using a 'web' user or just mod= ifying the namespace to show the process a limited set of information;
<= /div>- sets the namespace to prefer any libraries that are on the remote ba= nk machine, allowing the application to always run with the environment the application developers intended;
- sets the names= pace to include any files the application needs from the remote sandbox, e.= g. a directory with the user's banking files.

As a result = of this, it seems that much of the hooplah around flash, webGL, javascript,= etc. could have been avoided, and that web applications from yesteryear co= uld still run today (for better or worse), since they could control their e= nvironment. Web programming would have also have started off with far great= er ability, instead of having being limited by the abilities of its browser= platform and waiting years for even simple things to be standardized. Web = games, video-streaming applications, etc. on par with local applications co= uld have been launched as soon as the infrastructure could support them, as= the providers could just program the application to do whatever the OS all= owed.

It also seems it would avoid cookies and other privacy issues, since applications would be sandboxed to only know about the thing= s they have available to them.

That said, having had discussions wi= th friends in web development, they have expressed concerns about ease-of-u= se and their initial interest in the field - if I understand correctly, the= y feel that html's ease of modification and immediate gratification was= beneficial to getting them into programming, which - while my understandin= g of this community is that here it's not a highly valued thing - is, I= think an important point to address. They are application developers, and = the web had aspects system languages did not which attracted them.

<= /div>Again, if these thoughts are obvious, my apologies, and if it's de= eply flawed, my apologies - but I'd be interested in hearing why.
Thanks for your time,

Mars


=0A
=0A =
=0A
=0A ---2037608182-449245065-1474129398=:70526--