Read-only executable notebooks, live collaboration with widgets and notebook security model

[SylvainCorlay]

Hi All,

After a few in-person discussions about this, since feedback has been positive so far (@fperez @ellisonbg @minrk @sccolbert @rgbkrk @Carreau @jasongrout ), I thought that it was a good idea to submit the idea to the list.

What I am proposing here is a significant change in how we deal with the communication between the front-end and the kernel in the case of the notebook which would also apply to contexts such as dashboards.

In my opinion, it would greatly simplify

• our security model, by decoupling edition and execution rights.
• live collaborations with interactive widgets.

Let's start with the simpler problem of how to build read-only executable notebooks:

So the proposal to handle this is to forbid the front-end to send execute_request messages, and have it send messages to the server of the form execute cell #af12b239ca3.

The server would have the notebook document model and the content of the corresponding cell.

A user that does not have edit rights on the document model cannot send arbitrary code to the kernel, i.e. it is really a read-only notebook from a security standpoint.

The front-end would not have the ability to modify the code, but only to refer to addressable parts of existing code.

Live collaboration with interactive widgets:

We could go one step further and completely remove the ability of the front-end to send messages to the kernel, including comm messages.

In this case, the interactive widget state would be part of the notebook model held by the server. The only way the front-end interacts with the kernel is by modifying the document model (via widgets or cell content). In the case where a widget model was modified, the server would be the one sending a comm message to the kernel.

I think that it would also simplify the problem of live collaboration with interactive widgets because their would be no way to bypass the server and its conflict resolution by sending directly a message to the kernel.

Conclusion:

• Web front-ends would not be clients to the kernel messaging protocols anymore, and only the notebook server would be allowed to send kernel messages.
• The communication between web front-ends and the web server would mostly be
  • proposed changes on the state of the document (some of which trigger comm messages when it is widget state).
  • request execution of addressable portions of code (cells).

[blink1073]

For consideration:

• Do we still allow other kernel messages such as completion_request and inspect_request?
• Do we sync exactly the document model itself? For example, if a display output has multiple mime types, do we send all of them to the front end and still let the front end decide which to render?

[SylvainCorlay]

• Do we still allow other kernel messages such as completion_request and inspect_request?

I imagine that these could be supported aside of the "execute_request" of addressable code.

[ellisonbg]

While I think this model would work very well for parts of the notebook, there are some significant downsides:

• There are parts of the notebook UI that do need to send actual kernel messages (tab completion, variable monitoring, etc.). Implementing those would be more difficult as they aren't as stateful.
• The big vision of Jupyter is to provide building blocks for interactive computing - both in the backend but also in the frontend. Kernels are one of the most important building blocks. This change would essentially amount to removing kernels from the frontend entirely. Anyone who wanted to build a new UI component that uses kernels would then have to instead extend the server. Even something as simple as a QTConsole style UI in the browser would need to then be server side. I think that would be a huge step backwards for the project.

Because of these things, I don't think this makes sense for the main Jupyter project to be implemented in this manner. However, I definitely think it may make perfect sense for someone to build a server/client with this architecture for the reason you describe.

[SylvainCorlay]

There are parts of the notebook UI that do need to send actual kernel messages (tab completion, variable monitoring, etc.). Implementing those would be more difficult as they aren't as stateful.

These shell messages could be exposed by the server and directly forwarded from and to the kernel since they don't change the state of the document or the interpreter.

[SylvainCorlay]

Because of these things, I don't think this makes sense for the main Jupyter project to be implemented in this manner. However, I definitely think it may make perfect sense for someone to build a server/client with this architecture for the reason you describe.

Although it would greatly simplify live collaboration with widgets. I imagine that we could have the two models coexist.