[IPython-dev] IPEP 3: Multiuser support in the notebook

[Fernando Perez]

On Sat, Sep 8, 2012 at 2:02 AM, Matthias BUSSONNIER
<bussonniermatthias at gmail.com> wrote:
> Comment on current IPEP version :

> Ability to have "soft" more grained privileges. Invite a user than can only edit and not run.

Definitely.  Given how potentially destructive execution can be, this
is a very important permission level we want to have.  In static
documents (say google docs), the only things that matter are
read/write privileges.  We have read/write/execute, and all three
levels of permission should be available.

> Obviously we are really vulnerable to JS injection. We should definitely try to do something about that, even if we sell the notebook as beeing not totally secured. One thing we can use is html5 sandboxed feature of iframe. This could also solve the "problem" of css in ".rendered_html".
>

Yes, the ipep should have a section on security in the web sense (JS,
cross-scripting possibilities, etc).  I know next to nothing about
that stuff, but at least we should outline what the boundaries of the
problem are, and hopefully we'll get some expertise on the matter over
time.

> One of the things I came across while prototyping live collaboration is the real need to have the current state of the notebook on the kernel side.
> I think we should define a format of notebook 'patches' that represent common operation on a ipynb file, at least:
>         - appending/moving/deletting worksheet/cells
> preferably with reference to the worksheet/cell by UUID.

Yes, this is a tough one: for many reasons a fully stateless server
has many benefits, but it's also a real hindrance for other key use
cases.  Managing long-running processes is very hard with the current
design, and having all save operations send the full notebook back
uplink is simply unsustainable in the long run as it makes the system
unusable with large notebooks over asymmetric or metered links (such
as mobile connections).

We *will* have to come up with a solution where that state is managed
server side somehow, the current design simply fails to solve this key
use case that will become increasingly important as people move more
and more from local notebook use to server-based one.

> I also think that for live collaboration we need both a 'cell is being edited' lock, and also maybe a 'cell is being executed' lock.
>
> shift+Enter in collaboration is annoying as it makes you select the next cell, releasing your lock and selecting a new cell, potentially locked.
> I would be inclined to change ctrl+enter to execute without selecting all to be able to stay on the same cell.

We debated a lot whether to select all or not, initially it didn't.
I'm not opposed to going back to the no-select state on Ctrl-Enter if
we find a good reason for it (and this could be one).  I don't think
the reasons for going with select were super strong.

Cheers,

f