Store all settings server-side

[skerit]

I find it quite annoying that I have to authenticate certain extensions on each device.
For example: github, copilot, gitlens, ...

The "most recent workspaces" are also different per device (or browser profile).
Same for the "Do you trust the authors of the files in this workspace?" questions.

So I guess all this data is stored in the browser's storage, but why?
Is there no way of storing all this data on the server, so my experience is identical on any device I want to work on?

[jsjoeio]

I think this was done upstream in VS Code. While I agree it's annoying, we try to stay aligned with them as much as possible. Maybe you could reproduce in Codespaces and open an issue upstream?

@code-asher can correct me if that's wrong

[code-asher]

Yeah this comes from upstream. We did patch some things to store on the server (user settings) and I wanted to do the same with user data but it was going to be a non-trivial patch.

The security angle is an interesting one. Perhaps having the option of whether to store these per-device or per-server would be ideal but I suppose that is something we would have to raise upstream.

[skerit]

I don't really get the security risk angle, because surely the same is true for every saas that interfaces with github (or any other service). How would a "skilled hacker" get the password hash anyway, let alone decode it?
And even if that happened, it depends on where code-server is running. In my case it's running on a development server at the office, as the same user that can already pull & push to git via ssh. Having someone hack in there would be a disaster anyway 😄

Though giving the user the option of where to store it seems great for people who maybe don't 100% trust the server it's running on.

[code-asher]

The trust is a great point.

The way I interpreted it was that if there was some breach in the company hosting your server your GitHub oauth token would still be safe. An attacker would not be able to push/pull while you were not connected since the token would not be available. I am not sure that Code hashes the token so I think it might be available as plain text.

But yeah if they have access to your server you are probably going to have a bad time anyway. 🤷

Like you I use SSH keys for git but I use key forwarding so they are not on the server. A similar concept, I think. So for my own usage I would probably opt to keep storing the tokens in browser storage to match. In my case it is more about trust than hackers though.

[im-coder-lg]

How would a "skilled hacker" get the password hash anyway, let alone decode it?

Don't question me, I just listed possibilities.

[im-coder-lg]

The way I interpreted it was that if there was some breach in the company hosting your server your GitHub oauth token would still be safe. An attacker would not be able to push/pull while you were not connected since the token would not be available. I am not sure that Code hashes the token so I think it might be available as plain text.

Meant this as one way, but maybe they could gain access from a client computer too, if possible.