Explore notebook trust + workspace trust

[roblourens]

Continuing the discussion from #106747

[vscode-triage-bot]

Pinging notebook topic followers: @claudiaregio @rchiodo @greazer @DonJayamanne @jilljac

[DonJayamanne]

Let us know if there's anything you need. Thanks

[roblourens]

First, what are we trying to do by observing workspace trust?

• It sounds like in vscode's workspace trust model, if the user starts a debug session, that is an explicit action by the user, and we will not make them trust the workspace to do this. Is that right @sbatten? If so it seems like executing a notebook/cell is essentially the same, so do we have any reason to require the workspace to be trusted to do this?
• Do we care about renderers executing code in outputs, when they are sandboxed in the webview?
  • To be clear we are differentiating between "extension trust" and "workspace trust", only talking about "workspace trust" here. So I am not thinking about evil or compromised renderers. But if a renderer loads code from your workspace and executes it in order to render, then that extension is responsible for checking workspace trust, just as the TS extension is responsible for checking workspace trust before executing code out of node_modules/typescript/....
  • The question is, outside of that case, is there any reason for vscode to prevent a renderer from running in an untrusted workspace where it is loading data (not code) from a cell output, processing it, and rendering it in the webview?
  • It's possible that some carefully constructed output data could trigger a vulnerability in a renderer and make it do bad things. Is that in our threat model?

[sbatten]

There are currently 2 thought models on workspace trust and explicit actions.

1. Explicit actions are out of scope. We only talk about browsing a repository and any explicit action is known to the user, so we don't request trust. (i.e. we allow it and do nothing)
2. Explicit actions are signals of workspace trust and we take this as a signal to trust the workspace. In this model we still must confirm the user wants to mark the workspace as trusted and is only presented with a limited set of options to continue or cancel.

At present, one is not chosen over the other, but hopefully this scopes the discussion.

[jrieken]

The question is, outside of that case, is there any reason for vscode to prevent a renderer from running in an untrusted workspace where it is loading data (

• 💯 I share this. Event tho that data can be JavaScript/Html source code it is still running in a sandbox (webview or iframe) and that is isolated from the renderer and has no "dangerous", like NodeJS, apis. To me that makes it similar to the embedded browser that we are building and I don't believe we wrap that into a trust model

[roblourens]

Renderer code can send messages outside of the webview which gives it a potential real impact, but still it seems like the responsibility is on the renderer - if it's going to send a message which could result in a bad impact based on data in the output, it should check workspace trust.

[jrieken]

Renderer code can send messages outside of the webview which gives

Ideally those messages go straight to the extension host and aren't rerouted via the renderer. I believe there was some exploration to use message channels that enables that.

[sbatten]

@lszomoru for awareness