Repository: vscode
Issue: Workspace Trust - Investigate what it means to support the notion of trust for virtual workspaces
Labels: under-discussion,workspace-trust

Started with [this PR](https://github.com/microsoft/vscode/pull/124903). However, I'm going to move some of the discussion and thinking to this issue.

# Start with Resolver API

When creating Workspace Trust, we needed a solution for handling URIs in remote windows. e.g. Dev Containers open local folders within dev containers that then have strange workspace URIs the user was asked to trust separately. To improve the user experience, we introduced the canonical URI api for resolvers. https://github.com/microsoft/vscode/blob/6a76c62232208f54bc85f22572013b382e39cf9e/src/vs/vscode.proposed.d.ts#L161-L166

The purpose of this API is to allow each resolver to provide us with a re-usable URI that we can trust. In the Dev Container example, this can be mapped to a local file path. WSL could do the same when it makes sense. Codespaces could (but does not) remap the URI to a GitHub https URI.

# Considering RemoteHub

After introducing this API to the limited set of resolvers, we saw a similar need for RemoteHub which happened to be a file system provider. RemoteHub already had internally a re-mapping exactly like the resolver API but no way to provide it to core. Hence, we created the [PR](https://github.com/microsoft/vscode/pull/124903) to introduce the same API to file system providers. Before releasing Workspace Trust, we could not take this API so late, and there were too many file system providers out in the wild that might conflict with workspace trust so we decided to handle RemoteHub in core and avoid the conflict with other virtual file system providers.

# Concerns with the File System Provider API

1. We are duplicating the API. This is true; however, currently resolvers work quite differently than file system providers in when they are loaded. For resolvers, we *need* to handle the URI transformation prior to resolution of the workspace which in turn means prior to loading other extensions. We might be able to skirt this requirement in file system providers.

2. The name of the API is confusing in a File System Provider. It does not make it clear the purpose of this API. The API is very specifically needed only for Workspace Trust and doesn't serve much other purpose. It is also not a traditional FS-type API.

3. If we do want to remap the URIs of File System Providers prior to activating extensions, we need some rethinking. Separating this API into something that can be loaded early is worth exploring.

# Updated Proposal

Rename the API to something workspace trust specific. e.g. `WorkspaceTrustUriProvider` with a function `getTrustableUri(uri)` or `getUriAlias(uri)`. These would be registered to a given scheme (not the file scheme). We could consider additional restrictions e.g. only for schemes your extension registers other providers for, only one provider per scheme, etc.

## Example Extensions

### RemoteHub

RemoteHub is the de-factor virtual workspace provider today. It allows you to connect to a GitHub repo without cloning. It would like to convert `vscode-vfs` URIs to `https` URIs.

### GitLens

GitLens doesn't exactly provide a complete workspace but adds folders to a workspace when browsing an open repository at a specific commit. It would like to convert `gitlens` URIs to local `file` URIs.

### Docker 

Docker allows you to browse and open files from a running container. The most secure approach would probably be to treat these as loose files that are not trusted.

### Kubernetes

Based on my understanding of the extension, this is similar to Docker.

### GitHub PRI

The virtual file system is intended to browse issues and does not seem to pose any risk.

### Azure Databases

The file system provides a way to update cosmos db items. It isn't a full workspace but you can open editors with contents. However, practically, this is not a security risk and you don't typically connect to arbitrary cosmos dbs.

### SSH FS

I haven't tested the URI structure, but this one would likely mimic a blend of SSH remote + RemoteHub giving a readable URI to trust and edit.

## Remote FS

Works with sftp or ftp to provide virtual file system. I doubt any remapping would be necessary, but a proper implementation would require trust.

## Gist Pad

Allows opening arbitrary gists on GitHub. Opening them is similar to RemoteHub except it follows more of a loose file flow. I would expect to be able to trust https uris. 

## Zip FS

I would expect this to resolve URIs to the local paths which really means just changing the scheme.

## DEV Community

This extension auths into dev.to communities allowing you to edit posts. Due to the auth step here, and them being your posts, I don't expect a trust prompt.