Disallow downloading a workspace when you no longer have read access to the repository

[jankeromnes]

Is your feature request related to a problem? Please describe

Similar to #8257 for snapshots, we could restrict workspace downloads based on repository read access.

This way, former project contributors who are removed from a repository can no longer download workspaces containing the repository's source code.

Describe the behaviour you'd like

Describe alternatives you've considered

An alternative could be to allow project owners to disable workspace downloads for their entire project in their project settings, e.g.:

[ ] Disable Workspace Downloads
    Prevent current and former project contributors from downloading workspaces that contain your project's source code

Additional context

[geropl]

IMO we should think about who owns a workspace. So far, we (mostly) assumed that a user owns a workspace. That started to change recently, when we required for 1) logs and later 2) snapshots to currently be able to access the source.

The "user owns a workspace" is identical to a local machine workflow. And I think we should be careful not to take too much away from this autonomy.

I get that Teams - especially on private repos - would like to exclude past contributors to have access to their code. But maybe we could make this a project level option?

@jankeromnes Combined with your suggestion:

 - [ ] Disable Workspace Downloads
 - [ ] Require repo access for accessing Workspace/Snapshots

/cc @jldec

[gtsiolis]

❓ question: Even with all the proposed changes here a user could still simply open their workspace and copy all the code, variables, etc, right?

suggestion: Instead, what do you think of considering deleting workspaces associated to a project when removing a user from a team? We used to do that when deleting a team[1] we had workspaces grouped under teams and project but I could be wrong. We were certinaly not doing that when deleting a project[2].

1	2

❗ issue: We're still not linking to the project when there's an associated project from the workspaces list, see #5125.

❗ issue: We still do not have a confirmation modal when leaving a team or removing team members, see #4702.

💭 thought: Instead of adding a configuration to disallow workspace downloads when a user no longer has access to the repository, what if we introduced a confirmation modal when removing a user from a team that also mentions or provides the option to delete all workspaces started for projects added within that team from that specific user? Cc @jankeromnes @geropl @jldec

In a similar way, when someone removes a user from a GitHub organization, the associated linked issues, pull requests, etc for any private repository disappear from their global issues page, see screenshots below.

BEFORE	AFTER

[geropl]

@gtsiolis I like your way of thinking, and think that could be a better solution.

However, this is an even deeper problem: The idea that a user owns a workspace is ingrained very deep into the implementation. The persistence (workspace backups and logs) is all centered around a user, and also when we're doing support, we always assume the user has authorative control over their workspaces. This is the very same for the owner-token: It's only the user that can retrieved this token, never the team, nor anyone else. And the current model does not take "ownertoken withdrawal" into account, so there will always be loopholes.

I think we need to more fundamentally think about when a workspace belongs to a user, and when it does to a team, and write that down. If we want to change this it's a product decision at the end.
Moving too quickly here we:

• a) break a lot of users's expectation we so far encouraged all around ("I own all of my workspaces"), and
• b) easily generate a false sense of security

Being pragmatic here IMO we should:

• raise the "who owns a workspace" question with product and have a broader discussion (because this is a important gap, and opportunity)
• for now assume starting a workspace is the same as git clone a repo locally 🧘

@jankeromnes I will close the issue for now because for the reasons just mentioned (warrants broader discussion beforehand), and it not being actionable enough, yet.