Re: Extensions Infrastructure Work

["Jasper St. Pierre" <jstpierre mecheye net>]

OK. This has caused quite the controversy here. I do not really want
to hurt or upset anybody, and I understand a lot of your concerns
about security and safety.

By now I've believe I've made my case on why I would like to pursue an
in-browser approach. I'm just going to take one last chance to go over
some common concerns about using a local HTTP server, with some proper
responses to go on record. After this, I'm going to delay working on
upgrading and the "extension management" parts of the shell, and
instead focus on the app store-y parts: comments, ratings, code
review, uploading, and a proper look.

Well, ready? Here we go:

== Security ==

Q: Will this server be exported over the network?
A: No. It is bound to localhost, not the standard listen address "0.0.0.0".

Q: What about third-party sites manipulating the HTTP server by way of
AJAX, redirection, or forms?
A: For AJAX,  I added an Access-Control-Allow-Origin header that
modern browsers can use to accept or deny connections. For
redirection, I am making all the handlers use POST instead of GET. For
forms, I'm going to use a simple CSRF technique: you POST to a URL and
get a token back that has to be used in the next POST request. I don't
think IFRAMES can make POST requests, nor can web sites scrape content
from it that's from an external domain.

Q: What about a user that has access on the current machine
manipulating another user's Shell session?
A: I'm going to scrape "netstat" or "/proc/net/tcp" on every
connection and make sure that the UID that's making the HTTP
connecting matches the UID of the current user's Shell session.

Q: What about multi-user sessions?
A: I will probably have a list of ports about 10-long, trying one
after the other until the first one lets me in, as described above.

== Convenience ==

Q: My localhost/127.0.0.1 is behind a proxy server. What can I do?
A: Right now? Don't do that or...

Q: What happens when I'm offline and want to disable/enable extensions?
A: Well, for those cases, I'll probably have an extremely bare-boned
UI that allows people to disable/enable extensions.

== Code Quality ==

Q: Eww... fixed ports are ugly.
A: Not really... most services usually only live on one fixed port:
HTTP is on 80, FTP is on 21, SSH is on port 23.

Q: Why not use an in-process server to Shell or libsoup?
A: The current Python implementation is a toy, and I'll probably write
a server in libsoup. It may be in-process with GNOME Shell, written in
GJS. I'm not sure yet.

==

At this point, I feel everything can possibly be said has been said.

On Thu, Jun 23, 2011 at 12:26 PM, Milan Bouchet-Valat <nalimilan club fr> wrote:
> Le jeudi 23 juin 2011 à 22:00 +1200, John Stowers a écrit :
>> On Thu, 2011-06-23 at 11:48 +0200, ecyrbe wrote:
>> > thank you john for the bits of history of the design.
>> > i do know about server programming, as in fact it's my job to make
>> > high load servers in c++.
>> > i also understand the design better and the solution you try to
>> > provide.
>> >
>> > as i said. you can make the server lightweight inside the shell, i
>> > don't think people would complain as this would make it a lighter
>> > solution than a separate daemon.
>> > The problem with a separate daemon, is that you end up using a process
>> > to do nothing 99% of the time. integrating it in the shell would make
>> > it :
>> > - leightweight -> you only add a listening port to gnome-shell.
>> > - integrated -> you don't need to add a dbus api to control extension
>> > enabling/disabling
>> > - easy to implement -> you only have to use libsoup asynchronously, no
>> > threading use
>> > - no memory overhead -> it's integrated in the shell , you don't have
>> > to allocate a new stack for it
>> >
>> > so, why not integrate it? why would people complain ?
>>
>> Cool. As an engineer you probably also understand that one does not
>> always start with the perfect implementation.
>>
>> Pragmatically the separate process HTTP server is not bad for a first
>> go.
>>
>> I'm still not convinced a process that is sleeping 99% is a big deal. It
>> should be swapped out and take no resources.
> On the plus side of the out-process approach, if we switch to systemd to
> handle the whole user session, the HTTP daemon will merely register the
> port, and would never be started until actually used. So, if you want to
> discuss theoretical details of a few kB of RAM, you also need to
> consider this possibility. ;-)
>
>
> Cheers
>
>
> _______________________________________________
> gnome-shell-list mailing list
> gnome-shell-list gnome org
> http://mail.gnome.org/mailman/listinfo/gnome-shell-list
>

-- 
 Jasper