Thanks ... but I can't see a method to disable this behaviour. I do not want to enable 2FA (a huge security risk), and of course I do clear the history whenever I am done online. Also I access my account from several places and several devices, making the suggestion "preserve the cookie" inapplicable. Generally, I do not want let any third party collect my personal data when I use wikis. Is the only way to fix this removing my email address, or would that result in immediate loss of my account?

Indeed I have exactly this problem:

• https://www.mediawiki.org/wiki/Project:Support_desk/Archive_23#Obligatory_security_rules_that_users_cannot_decide
• https://meta.wikimedia.org/wiki/Tech/Archives/2025#Obligatory_security_rules_that_users_cannot_decide

There is nothing inherently wrong with clearing cookies, and there is nothing inherently wrong with accessing one's account from several places. Also I do not want to login into my email every time I log in into wiki, bringing the risk to lose both my email and my wiki account at same time. Please allow users to disable this nonsense.

In T408383#11311576, @Taylor wrote:

Thanks ... but I can't see a method to disable this behaviour. I do not want to enable 2FA (a huge security risk),

Can you elaborate on the security risks associated with enabling 2FA?

and of course I do clear the history whenever I am done online. Also I access my account from several places and several devices, making the suggestion "preserve the cookie" inapplicable. Generally, I do not want let any third party collect my personal data when I use wikis. Is the only way to fix this removing my email address, or would that result in immediate loss of my account?

You can remove your email address, but we don't recommend that. If you forget your password, or your account is compromised, it's unlikely that T&S would be able to help you recover your account.

elaborate on the security risks associated with enabling 2FA?

Collection of personal data via moron phone, plus big risk of loss of your account. What happens if both your moron phone and the paper with 10 recovery codes burn up in same fire? Not everybody owns 3 castles. Please allow non-luxury users to opt-out from this.

• https://www.mediawiki.org/wiki/Help:Two-factor_authentication
• http://www.nongnu.org/oath-toolkit dead or very slow link, unclear what to download

I cannot find a feasible "client". 60 MiO download size requiring a 64-bit processor for the only purpose of logging in into wiki (that had always worked out of the box for 9 years) is not a feature, it is new trouble. The "client" can break any time, and I lack the ability to debug several 100 MiO of bloat. Many users access their wiki accounts from public computers where you cannot run any client at all, and you do not want to unnecessarily log in into your email. And of course, not everybody wants to be permanently online for the only purpose to avoid being locked-out forever. The idea to lock one's wiki account to a single piece of hardware that you and only you must own, and that can break or get lost or stolen at any time is brain-dead.

I have lost several email accounts though false "security improvements", "verification required" or "Is it really you?"-questions. And I do not want that possible loss of my email account automatically results in loss of my wiki account as well: https://en.wikipedia.org/wiki/Single_point_of_failure .

Thank you for your understanding, a wiki contributor, soon probably ex-contributor :-(

@Taylor As I said in my reply on https://www.mediawiki.org/wiki/Project:Support_desk/Archive_23#Obligatory_security_rules_that_users_cannot_decide - we do understand that email checks add real imposition for users who routinely clear cookies and change IPs. To clear up some things I think you may not understand about the two options I described there (keeping a cookie, and 2FA):

• The loginnotify_prevlogins cookie is independent from your login cookie. You can clear your session cookies but allowlist this cookie. It is much less sensitive than a login cookie.

• Or, you can set up two-factor authentication. We have added support for multiple authenticators, so you can register as many as you like. So you could, for example, use a traditional authenticator app like Authy or Google Authenticator, as well as a cloud service like 1Password (which can act as a TOTP device), or anything else you want. You can avoid a single point of failure.

• You can also remove your email, which is sort of a form of opting out but it is basically accepting the risk of account loss, as you should not expect us to be able to recover an account without an email if you lose your password or the account is taken over even briefly.

I do recognize you are also objecting on principle - but requiring email-based checks for non-2FA accounts are just where Wikipedia needs to be right now. We added it in response to very real attacks on user accounts, and it is quite common on other services. Further, the risk of takeover/misuse of user accounts is not just one that you, the user, are accepting - the integrity and reputation of Wikipedia depends on keeping a tolerably high bar for authorized use of its user accounts. This is a security measure that, like our password policies and other site-wide measures, is not something users can opt-in or -out of.

@Taylor I also can't quite tell if you are reporting a specific bug in email deliverability or how our EmailAuth messages work. If your concern is that you are just having to deal with a lot of these checks, for the reasons described above that's not an issue we're going to address here (but you have options above to ameliorate it). If you are seeing the feature not work as described, please provide some more detail and we'll be happy to take a look at it.

Thank you for that answer. Now I start understanding how this ie activation of "Extension:EmailAuth" could happen. Still, there are several false assumptions:

• that email is an inherently secure thing that every wikimedian has available and guaranteed for life
  • fact is: Email in inherently insecure. It can be hacked or stolen (ie ZERO security gain for WMF), and even worse, one can lose access to one's mail at any time. With "Extension:EmailAuth", this causes an immediate and unrecoverable permanent ban from one:s wiki account. Not so funny, is it? I have had my wiki account for 9 years, and until ca one month ago had never had major trouble logging in. During that time, I lost several email accounts, ZERO by forgotten password, ZERO by stolen password, and many by false accusations "Is it really you Taylor? You account has been locked due to dubious activity".

• that every wikimedian is permanently online and permanently logged in into eir email account, thus "Extension:EmailAuth" just adds ca 3 seconds into the login process: look at your email bubble, copy 6 digits into the login field, done
  • fact is: Some users are offline most of the time (good security practice), and keep their accounts separate (good security practice, security through separation, as opposed to https://en.wikipedia.org/wiki/Single_point_of_failure. This exclusive "improvement" pressures the user to additionally login into eir email at every login into wikimedia, substantially increasing the risk to lose the email account. There is no security gain for WMF with this. If someone can steal my password when I login into wiki, ey will steal my email password at the very same occasion with the very same method. The attacker will pass the email validation and do eir mess on WMF wikis. No gain for WMF, big loss for me.

The loginnotify_prevlogins cookie is independent from your login cookie. You
can clear your session cookies but allowlist this cookie. It is much less
sensitive than a login cookie.

I clear everything in one strike, not single cookies one at a time. And there does not seem to be a good way to export and import cookies from FireFox.

We have added support for multiple authenticators, so you can register as
many as you like. So you could, for example, use a traditional authenticator
app like Authy or Google Authenticator

Thanks ... but I have a strict ZERO-Gugl policy. Most probably Gugl is among the 10 worst threats against both our planet and our freedom (or the current leftover of those two resources).

cloud service like 1Password (which can act as a TOTP device),
or anything else you want. You can avoid a single point of failure

Can you point me to the very simplest authentificator (commandline, algorithm) free of interference from for-profit companies? Letting for-profit companies collect my personal data or my bucks when logging in into wiki is absolutely unacceptable.

You can also remove your email, which is sort of a form of opting out but
it is basically accepting the risk of account loss

I do not silently accept account loss, in particular not through "Extension:EmailAuth" and for-profit companies promoted by it. I do consider removing my email address. I also added "Committed Identity" to my account (that could be dead already tomorrow, due to "Extension:EmailAuth" and bad security practices of others).

My password (NOT posted here) is well above the minimal requirements stipulated by https://meta.wikimedia.org/wiki/Password_policy . On that page I can read:

For exceptions to this policy contact security@wikimedia.org

I really do not need an exception for a poor password. But I do need to maintain my security through separation of accounts, and keeping mass surveillance companies out of my life.

WMF has the possibility to issue a Global Foundation Ban: https://meta.wikimedia.org/wiki/WMF_Global_Ban_Policy . It is very rare, and requires hard evidence of substantial guilt. It results in the targeted user being deprived of eir wiki account. The email account of the user is not affected however.

"Extension:EmailAuth" is worse than a Global Foundation Ban. The user gets deprived of both eir wiki account and eir email account in one strike. But where is the guilt? The "guilt" elaborated here so far includes:

• clearing browser history (incl cookies) when done online (good security practice, not a valid reason for ban)
• not being permanently online (good security practice, not a valid reason for ban)
• not being permanently logged into your email account (good security practice, not a valid reason for ban)
• separation of accounts (good security practice, not a valid reason for ban)
• contributing from several places or ISP:s (neither good nor bad, but a fact for some users, ultimately not a valid reason for ban)

added it in response to very real attacks on user accounts

Lacking insight into the relevant data, I cannot claim this to be untrue. Maybe it is very true and very real. Most probably this is due to poor passwords (like "moskva1") or malware. I have a good password, and do not buy malware.

Further, the risk of takeover/misuse
of user accounts is not just one that you, the user, are accepting - the
integrity and reputation of Wikipedia depends on keeping a tolerably high
bar for authorized use of its user accounts. This is a security measure

This is a perfectly valid point. I fully understand that WMF want to do the utmost to minimize cases of privileged accounts causing a mess with someone subsequently claiming "this was not me, someone must have hacked my account". Still, making the wiki account inherently dependent from one's email account (owned by a totalitarian company, namely Gugl for ca 99.99% of users) does not serve this purpose. It serves dubious for-profit companies trying to take total control of the complete population. This "Extension:EmailAuth" blatantly violates WMF's own policies on privacy:

https://wikimediafoundation.org/public-policy wrote:

Privacy enables people to engage and share knowledge freely, without fear
of someone watching their online lives. We defend everyone's right
to privacy and challenge mass surveillance.

Well written! I absolutely do not want any for-profit company to collect my personal data or my bucks when I login to or use public WMF wikis. Even less I want any for-profit company to have a right of veto against my login, or a right to ban me from my wiki account. To me my objections seem perfectly inline with WMF:s privacy principles declared at https://wikimediafoundation.org/public-policy . Yet "Extension:EmailAuth" does exactly what I object against: give for-profit companies control over my access to WMF wikis.

EMill-WMF (Eric Mill) wrote:

it is quite common on other services

Indeed ... many services incessantly require validations of not only email address, but also the moron phone number, assuming everybody would have a moron phone. But given WMF:s own commitment to privacy quoted above, the fact that others behave badly is not a good reason for WMF to behave badly themselves. What comes next after "Extension:EmailAuth" for the sake of "security"? Login through Gugl only? Login via FSB's https://www.wikidata.org/wiki/Q58792 "security app" only?

I do not understand how this bug is fixed given that in my preferences I still can opt-out from:

Notification on Failed login attempts
Notification on Login from an unfamiliar device

but not from "Extension:EmailAuth".

EMill-WMF (Eric Mill) wrote:

I do recognize you are also objecting on principle

...

if you are reporting a specific bug in email deliverability
or how our EmailAuth messages work

Indeed I object on principle against:

• not being able to login despite providing correct password
• this huge security breach and privacy breach
• giving for-profit companies control over my access to WMF wikis
• losing both my wiki account and my email account soon
• blaming users with good security practices for behaviour of users with bad security practices, and pressuring the former group to drop their good practices
• random false accusations of me not being myself (as elaborated above, I had been affected by this several times before)
• mass surveillance

and therefore I object on principle against "Extension:EmailAuth" itself and would like to opt-out from it. "Extension:EmailAuth" goes against WMF:s own ambitions on privacy, and therefore I deliberately had tagged this task as BUG.

I have no opinion about how "Extension:EmailAuth" affects the security level for users with bad security practices ie users who are permanently online and permanently logged in into their email accounts. Still, for users having own strict security policies "security though offline" and "security though separation" this is a devastating idea NOT bringing any gain for WMF. Maybe 95% of all wikimedians are permanently online and permanently logged in into their email accounts (preferably Gugl, the gold standard). But then, those 5% who are not permanently online and not permanently logged in into their email accounts, should be able to opt-out from "Extension:EmailAuth" in an official, respectable and safe manner.

In T408383#11324051, @Taylor wrote:

I clear everything in one strike, not single cookies one at a time. And there does not seem to be a good way to export and import cookies from FireFox.

Browsers like Firefox allow you to define exceptions for certain cookies not to be deleted whenever you clear your cookies. That's a one-time change in your browser settings?

Thanks ... but I have a strict ZERO-Gugl policy. Most probably Gugl is among the 10 worst threats against both our planet and our freedom (or the current leftover of those two resources).

cloud service like 1Password (which can act as a TOTP device),
or anything else you want. You can avoid a single point of failure

Can you point me to the very simplest authentificator (commandline, algorithm) free of interference from for-profit companies? Letting for-profit companies collect my personal data or my bucks when logging in into wiki is absolutely unacceptable.

https://meta.wikimedia.org/wiki/Help:Two-factor_authentication#Enabling_two-factor_authentication lists several open source apps and also points to https://en.wikipedia.org/wiki/Comparison_of_OTP_applications – there should be applications that fit your criteria.

added it in response to very real attacks on user accounts

Lacking insight into the relevant data, I cannot claim this to be untrue. Maybe it is very true and very real. Most probably this is due to poor passwords (like "moskva1") or malware. I have a good password, and do not buy malware.

EmailAuth got implemented as a response to https://meta.wikimedia.org/wiki/Wikimedia_Foundation/March_2025_discovery_of_account_compromises and similar incidences. The risk of Wikimedia accounts being targeted by malicious actors – especially accounts with advanced permissions like yours – has increased a lot with Wikipedia's increased importance.

That's a one-time change in your browser settings?

I usually do this from outside of the browser. Plus this does not help with different devices or only different browsers. I cannot find a simple "export&import cookies" feature in FireFox. Probably it got dropped at some time in favor of AS (Artificial Stupidity) summary, DRM (Digital Restrictions Management) and other nonsense pirated from BigTech owned by right fascists.

EmailAuth got implemented as a response to https://meta.wikimedia.org/wiki/Wikimedia_Foundation/March_2025_discovery_of_account_compromises and similar incidences.

I see ... almost 40'000 accounts got globally banned ... but as WMF admits, essentially no damage had occurred except the discovery that the mass ban tool did not work: T389728: Locking hundreds of accounts with Special:MultiLock results in 0 locks . It is a perfectly legitimate effort for WMF to prevent account hijacking and abuse. This activity and the "Extension:EmailAuth" should however not boost the power of BigTech, nor "automagically" lock out users without proven guilt.