New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow "anonymous" sign ins #3

Closed
Chuxel opened this Issue Sep 20, 2017 · 6 comments

Comments

Projects
None yet
3 participants
@Chuxel
Collaborator

Chuxel commented Sep 20, 2017

Currently the preview requires anyone with an invite link to sign in to join a collaboration session to ensure that the person starting the collaboration knows who is actually connected to the session. However, this adds an extra step for guests joining the collaboration session and may not be desirable in scenarios like open source projects.

Introducing an anonymous permissions level would resolve this problem where a participant could join the collaboration session without signing in (and then opt to sign in later). The invite link is non-guessable which increases the overall security of the approach.

@pltrant

This comment has been minimized.

pltrant commented Jun 9, 2018

This would be extremely useful. I work with a number of non-professional coders, so many don't have Microsoft or GitHub accounts. Using Live Share is a great tool to assisting them when they ask questions, but the required account is one more hurdle to using it.

@lostintangent

This comment has been minimized.

Collaborator

lostintangent commented Jun 9, 2018

@pltrant Out of curiosity, what’s the use case you have in mind? This feature is something we’ve heard a decent amount of interest in, and I just want to make sure we’re accounting for all scenarios this could potentially benefit 👍

@pltrant

This comment has been minimized.

pltrant commented Jun 9, 2018

I work on a product that has a custom scripting language. It's simple enough that any employee who wishes to utilize it can, but it can also be complex at times, depending on what's trying to be accomplished. I wrote a VSCode extension for it and assisted many of our employees in switching to it. We also routinely have new employees every year and offer a brief training session on learning the scripting language and going forward, learning to utilize it with VSCode and the extension for it. In such scenarios when these users ask for help or we want to show them something, we want the path to least resistance for jumping in and helping them. Having to install the Live Share extension itself and reload VSCode for the first session is one big hurdle by itself, but a necessary and understandable step. But for signing in, most of these users are not actual programmers and don't have such accounts already, so we also have to ask them to perform that step too. It's about reducing the time for setup and actual use.

@lostintangent

This comment has been minimized.

Collaborator

lostintangent commented Jun 9, 2018

@pltrant Thanks for sharing that detail! We definitely want the barrier for collaboration to be low, and this is a great example of why allowing anonymous guests would be valuable.

@Chuxel

This comment has been minimized.

Collaborator

Chuxel commented Aug 23, 2018

Merging in #784 from @leidegre


Would it be possible to launch a VS Live Share session without an account? Simply by sending a one time use only link to a colleague or friend over, say Slack?

It would greatly lower the barrier of entry and encourage people to try the feature. I really don't like the idea that I have to sign in to use an extension which otherwise seem like a really nice thing.


It is not possible today to do this, the very purpose of liveshare is for collaboration with different user identities, to remove user identities from the collaboration experience amounts to anonymous access to your source code, and running programs on your machine.


@Priya91 obviously, you would 1.) not send an invite to someone you do not trust and 2.) not accept that they join the session if you do not trust that they are who they say they are.

Identities (that can be verified) can be provided in a multitude of ways, a Microsoft account is not the only way to do that nor is it necessary to have an external identity provider in the mix. You could just as easily set a password to protect the session, if you are really worried about the wrong person getting access.

As a final example, let use ssh. If I my colleague sent me a public SSH key we could use that as his identity. The burden lies on us to make this exchange in a secure manner but that doesn't seem like a big deal to me. Regardless, I'm assuming that I have to accept that my workspace is accessed before it actually is.

@lostintangent

This comment has been minimized.

Collaborator

lostintangent commented Dec 5, 2018

This has been addressed in the latest Live Share update 🚀 By default, when a guest tries to join a session, and they aren't already signed-in, they will be given the option to continue as a read-only guest, and then enter a name. The host will get a notification asking if they'd like to accept their join request or not (which is important, since we can't guarantee the guest's identity).

After the host accepts the request, the guest will only be given read-only access to the files/terminals/etc. If the guest wants to elevate to read/write access, they can simply sign-in.

We'd love to hear feedback/questions/thoughts on this experience. Otherwise, thanks again for all the feedback here!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment