The Android app is a testbed for new ideas, especially controversial ones. Additionally, as many users are already logged into their Google accounts as part of phone setup (necessary to use the Play Store and Gmail), the app seems an ideal candidate to support Wikimedia account registration and login using a Google ID.
Gergő is interested in the technical implementation of this feature and may be able to help us flesh out any areas that the existing documentation needs more detail.
Legal would need to sign off on this first, due to user privacy for this to be enabled anywhere near the WMF wikis.
This has been discussed previously and unless there is large community census and any privacy policy blockers removed, it won't happen (one example is T61631: Enable Facebook login on Wikimedia wikis).
Some good questions raised by @Mholloway and @Dbrant about supporting OpenID in general, how does one log in when not on Android, and value to the user need to be answered as well before this card can be worked on.
T215046: RfC: Use Github login for mediawiki.org has lots of discussion about the privacy and community aspects of supporting external authentication in general.
Not sure if my request (T328812) was a duplicate... But as it was marked like that I will add my two cents here.
I think this path is wrong for various reasons. Don't enable just one provider at a time (don't enable just Google, just Github, or just Facebook). All reasonable auth methods should be enabled at once. Having multiple providers solves previously reported issues (concerns):
My assumption is that users choose whether they want to share their data with an external provider or leave authentication within the Wikimedia family. If that's the case, if users can just add an external provider, then most of the problems will go away. Of course, the very process of introducing such capabilities will not be trivial. Even if the existing OAuth extension is sufficient, you still need to configure the provider. But I would say this is a small cost compared to the benefits.
Note that by "reasonable auth methods" I mean mostly what @Legoktm said in the RfC in comment: T215046#4939924. I think that checklist is good and think most large providers would be OK.
In my interpretation most large providers like google, microsoft, etc. do not meet this criterion.
The external login provider is ideologically aligned with Wikimedia and MediaWiki values and principles.
#5 is because our movement is strongly based in our values, and we should be supporting our allies. There's also precedent in #5 from T61631.
I assumed that was because the RfC mentioned one provider explicitly. I don't think using many popular providers is an endorsement. It solves our problems, not theirs.
Registration is a process that has been mentioned many times during the implementation of Vector 2022. I mean that choosing a different skin is said to be difficult, because you would have to register an account. Many people suggest registration is hard so choosing a skin (or other preference) is hard.
Registration was also listed as a problem in the recent results of trying to get new users:
https://upload.wikimedia.org/wikipedia/commons/d/d8/Newcomer_experience_marketing_2022_pilot_final_report_-_Wikimedia_Foundation.pdf
We didnʼt manage to convert over 99% of the people who clicked through from Facebook and landed on our account registration page. Putting that another way, over 300k people indicated an interest in Wikipedia but dropped before registering.
Since this is by far not only a technical and legal issue, this definitely needs community support.
FWIW I agree with most of @Tgr's critique of my checklist in T215046#4945193.
Right. I don't know how workable this criterion is practice, I think Tgr's response (that I linked above) is probably right. Off-topic, but I think there's a lot of low hanging fruit from adding OSM as a login provider, and it would be reciprocal since they have a Wikipedia login option.
One thing I took away from the RfC was that adding a login provider is kind of a big deal. You need to think about how much you trust them, both in general as an organization, and specifically for this use case (e.g. what if a highly privileged Wikipedia account is connected to a low-value external account, like a Github account that doesn't own any code? If an attacker tries to social-engineer their way through the account recovery process, would that provider be cautious about it, given the low value of the account?), and over time (see e.g. Twitter). So I don't think that's a good approach.
Also I think it would be more pragmatic to first focus on an identity provider that does not trigger knee-jerk "not a social network" responses. OSM sounds like a good idea.
what if a highly privileged Wikipedia account is connected to a low-value external account, like a Github account that doesn't own any code? If an attacker tries to social-engineer their way through the account recovery process, would that provider be cautious about it, given the low value of the account?
Sure, I get this. You could maybe steal a Github account. But you could also steal Wikipedia account as well, and maybe with an easier process. You don't know if users with admin accounts use good passwords (on Wikipedia). If they use 2FA then you don't know if someone just stolen their phone with Google Authenticator. You don't know if they have a decent pin code on their phone etc, etc...
So yes, I understand some kind of security assessment would need to be done. Personally I don't know how is Github/Microsoft handling suspicious activity. I know that Google would send me a push notification upon new auth on a new device. So adding a Google account and making my Wikipedia password very long and random would make things more secure.
Also I think it would be more pragmatic to first focus on an identity provider that does not trigger knee-jerk "not a social network" responses. OSM sounds like a good idea.
Yes, adding FB could trigger something like that. But I would hope WMF would prepare for such a conversation. Preferably in advance (before deployment). First try to educate users and then prepare RFC or some other discussion. I'm a strong believer of people's voice, but voice with knowledge is just noise. People need to know what it is about before they decide. See also: https://citizensassemblies.org/
Auth and registration with different providers is about UX & security. Not about some ideology or commercials or whatever.