There have been various discussions about the problem of not being able to sign in to different pods, and the confusion caused when someone follows a link to a post on another pod and then tries to interact with it.
I have a simple idea that I don’t think has been put forward before:
I use pod.name, and I’ve unwittingly followed a link to a post on otherpod.name. I try to interact on it and am taken to a sign-up screen. I try to sign in and can’t. Result: confusion.
My idea:
Rather than just giving the error ‘Invalid user name or password’, add a tip: ‘Please try entering your full diaspora ID (e.g. username@podname.org).’
(For security purposes, the screen should probably disable the password field to avoid a user entering their password to another pod, in case of evil podmin.)
I enter me@pod.name. The pod takes that domain and checks it by going to https://pod.name/nodeinfo/1.0
If that page exists and software:name = "diaspora", redirect to https://pod.name/users/sign_in; if I’m already signed in, hopefully bypass this page.
It can also check for other software types and redirect to the relevant sign-in screen for Friendica, Hubzilla, Socialhome or Ganggo (or whatever else).
What would be really good if is the guid of the post or profile I was trying to interact with was sent as a token, so that when I’ve been redirected to my own pod (and signed in if necessary), I’m taken straight to that post or profile and can interact with it.
I think this is one of the very first issue I opened on github. In my opinion, if the users know their full ID (xxx@podname.org) they will also know what their pod is. So your proposition will only help a few users.
We can still display a more meaningful message anyway, but we also need to be careful as it is also possible to log in with your email. Then, how to tell if the users are entering their ID or their email? It could even be an evil case where I’m logging at diasp.org using fla@diaspora-fr.org which could also be my email
Dammit, I might have known it wouldn’t be so simple.
Would this approach work?
Rather than directing straight to the sign-in page when someone tries to interact with a page when not signed in, we could do the following:
Pop up a pane (or redirect to a page) which reads 'You are currently not signed in to pod.name. If you have an account on this pod, sign in [link]. Otherwise, enter your pod domain here [link].
Clicking the second would redirect that that page on your own pod. If the guid is not yet recognised by that pod, the content can be federated so that you’ll never get a 404 as a result.
This sounds like an issue we should solve the other way, and in fact, we already started. Rather than handling attempts to sign in, we should provide an “interact with this post/cat gif/person on your pod” link, and a very good way to approach this is by leveraging the powers of diaspora:// URIs.
As for your main suggestion, handling sign-in attempts at the wrong pod, is probably not worth the effort if we actually look at the number of instances this would be useful. However, a thing we could do without too much effort, is improving the handling of failed authentications attempts in general. Instead of showing the “Invalid username or password” toaster, we could add a red box above the login form, stating the same. This would also allow us to place a nicely written “if you are sure your credentials are correct, please ensure you are trying to sign into the right pod” notice.
How does this help a good diaspora experience? IMO you need to be redirected automagically either to the login of your own pod or better, when you already are logged in, to the federated post on your own pod.
I do think failed login attempts on other pods are a security risk and should be avoided at all times. It might be an option to have a staged login: first enter your id/email. Hit enter. Then, if necessary, you are redirected to your own pod and presented with the password field. This way you never enter your password on the wrong pod.
How does magically redirecting help a good UX? My email address is test@exmaple.com, and as diaspora* allows me to sign in with my email address, but I also have a pod running at example.com. However, I do have a brand account at otherexample.com, and I want to use my email address to sign in. What happens?
If the applications behavior is unpredictable and users have to guess, then the application has an issue.
Right, and you are not solving anything by implementing magical redirects. There are two possible kinds of users here:
The kind of user that looks at the address bar - in which case they will not enter their credentials on a foreign pod anyway.
The kind of user that does not look at the address bar, which would be vulnerable to the theoretical attack you’ve outlined. However, you’re missing some important pieces.
You claim the application should redirect users away. Since the user in question does not look at the address bar, they also won’t look at the address bar after the redirect. If anything, they’ll notice a reload, or something that looks like a reload, and think they are at home.
Podmins generally don’t log submitted credentials, unless they are malicious. On a regular, non-malicious pod, there is no security issue. However, a malicious attacker can set up something that looks like the login page, but is, in fact, an application that logs credentials. All they have to do is to act like a redirect is happening. Since your solution taught folks it’s completely okay to enter the username as they will get redirected to “the right pod”, they will enter the username with even less consideration, and after they’ve seen the simulated redirect, they’ll even enter their password.
Let me play the “I am not a coder” card then. I obviously don’t ‘think like a coder’, so don’t expect my suggestion to be a solution. If there are serious flaws in my suggestion, I am the first to drop them as not useful. On the other hand, my remark that logging in on a different pod is a security risk since credentials will be sent to that pod and could be intercepted by the podmin of that different pod.
It’s the unless that worries me. Of course the majority will not log credentials and even if credentials are logged, they will not (ab)use them. For now diaspora* is still a small and cosy platform for the exiled privacy fancying minority in social media land. It is just a question of time when the first rogue pods arrive and IMO we better prepare for that…
As @denschub already said: If there is a evil pod, it just wouldn’t redirect you way, it would just redirect you back to the evil pod. So once a user is on an evil pod and tries to login there, it’s the users problem, there is nothing we can help them to get back to safety from there, because everything we could try could be prevented from the evil podmin.
