Non-trusted mode?

[Guillawme]

Hello,

I think the execution barrier feature recently introduced (see #985) enables an interesting new feature: safely opening non-trusted notebooks.

The current behavior when opening a notebook is to run it all. This is perfectly fine for notebooks I wrote. But when I get a notebook online, I don't feel comfortable running it right away (it could contain malicious code, or simply take a very long time to run), so I first skim it in a text editor.

The proposed new default behavior would be something like this:

1. start Pluto normally
2. from the Pluto start page, go find a notebook file and open it
3. a pop up asks you if you trust the notebook (maybe with a brief explanation why one should not automatically trust stuff downloaded from the internet)
4. if you answer yes, Pluto runs the notebook normally; but if you answer no:
   a. Pluto sets an execution barrier on the first cell of the dependency tree, so nothing will run
   b. Pluto sets all cells to visible, so you can read through the notebook code without having to un-hide every cell manually (much more comfortable reading experience than having to open the notebook in a text editor on the side)
   c. when you're done inspecting the code and want to run the notebook, you simply deactivate the execution barrier

I think this behavior would make sense as the default, so users will always have a chance to think twice before running a potentially non-trustworthy notebook. That said, it would also be convenient to have an option to start Pluto with this feature disabled, for when the user knows they will only open their own notebooks and don't want to be interrupted by the pop up every time (maybe something like Pluto.run(trust_notebooks = true), and in that case it would be useful to have a visible warning on the Pluto start page to remind the user that this instance of Pluto is in trusted mode, so opening notebooks will run them right away).

[gianmariomanca]

See also: #1344

[Guillawme]

I saw this discussion and thought about posting there, but the use case is actually different. So, even though the implementation of these two features would have a lot in common, the user interface should be different.

Thank you for linking these two discussions.

[gianmariomanca]

If you set the "Jupyter-mode" of #1344 as the default when you open the notebook, wouldn't that solve the same problem? Nothing would run automatically until you switch to reactive mode or start executing one cell at a time.

[Guillawme]

Sure, if it also automatically un-hides all cells. But I am starting to think that it should not be the default mode then, since Pluto's main feature is reactivity. It is a difficult question.

Again, I agree that technically these things are the same, but in terms of user interface they are not. "Pause all computations to let me figure out my code without delay, then let me run cell by cell if I need to, or run it all" and "let me read this notebook from an unknown origin before I allow it to run all its code" are technically achieved the same way, but they don't mean the same things. In one case you trust the notebook to not delete your files or crash your computer, in the other you don't. So I still think these two modes should be presented to the user in distinct ways. Especially, the "safely-open mode" makes sense as a setting that applies to the entire Pluto instance: an instance started in safe mode will always show a pop up to give you a chance to open a notebook without running it, so the risk of running non-trusted code from this instance is reduced to how much the user will ignore the prominent warnings (so the Pluto start page in this mode should be visually distinct, to make it obvious that it's safe to open any notebook in this instance, and I believe this mode should also be the default when starting Pluto with no options with Pluto.run()). On the other hand, the "Jupyter mode" makes more sense as a per-notebook setting: in an instance of Pluto started with safe mode turned off, you could have some notebooks running with reactivity and others in Jupyter mode (one use case would be if you have a project with several notebooks, with a notebook that is working fine and you need it to run with reactivity while you are working on fixing another notebook that you switched to Jupyter mode to make multiple modifications more easily).

In any case, the technology is already there with execution barriers. The question is how to expose it in the user interface in a way that is not confusing and enables uses cases like Jupyter mode and safely-open mode.

[gianmariomanca]

Yes. To clarify, I don't think cells should ever be hidden or hard to read. I want to be able to read and change a cell that is after an execution barrier, before I remove the execution barrier.

[Guillawme]

I haven't used the execution barrier feature yet, but what I meant by hidden cells is when you click on the eye icon on the left of a cell to toggle display of the result+code or result only. I think the safe mode should toggle all cells to visible code when opening a notebook. I have no opinion regarding what the Jupyter mode should do to cell visibility (I guess un-hiding all cells is probably what users would need in most cases).

[fonsp]

Hi! See also #259, my plan was to implement it exactly as you suggested, but between 2 and 3, you can read the notebook code. Instead of a popup, the button stays there while you read.

I think your suggested solution would be fast to implement (like you say, popup and barrier are already built in) but we should do something nicer!

[Guillawme]

Great, nice to see this feature is on the roadmap. 👍