Thanks, @Blake - this is approved from our side. @sbassett could you add @Blake?

If this is chosen we may still want a technical measure preventing them from remove 2FA from users with advanced right.

Personally, I'd rather we put effort into eliminating port 80.

Just flagging that we are tracking this bug - thanks for documenting it here. Our initial team discussion about it suggests this is an unintended byproduct of running enwiki in 100% passive mode, and that it will be addressed when we move to 99.9% passive mode (which is scheduled for tomorrow morning, Monday).

Thanks @Clement_Goubert - could you give some more detail about the kind of security issues your work will need access to?

Yay for deleting code!!

In T408592#11390152, @ATitkov wrote:

Who will be responsible for security review, when this is sharing important top level domains ?

@TheDJ Could it be possibly handled or at least initiated by me and the Reader Experience team?

I am working together with the Reader Experience team to deliver a Mediawiki extension for the same initiative, which will also requires a security review. We have been told to make an initial security review ourselves, and schedule an official review by the security team for whenever possible, as they are overloaded with review requests and have a waiting list of a couple of months.

To add on, what about the maintenance of package.json and the dependencies that it pulls in?

@BCornwall For the first 2 months after publishing the website - it will be me. After that period, I will hand over to the Reader Experience team.

In T409911#11392339, @hector.arroyo wrote:

Note that concerns have been raised about the inability of sending the form if the connection is lost after loading the edit form but before the used interacts with it (i.e. before there is a chance to load hCaptcha's SDK). This discussion is blocking merging that patch.

In T410386#11385995, @Urbanecm wrote:

Switching to my volunteer Steward Liason role: We should be extra careful here before we make it happen. Assuming the rate limit between named and temporary accounts is not shared, switching to regular accounts when temporary ones are exhausted (or vice-versa) is the quickest way to bypass Six Account Limit (and make it a Twelve-Account-Limit instead). I'm not 100% sure how to account for this, but we should consider this risk and incorporate it into the decisions we make here.

CC @EMill-WMF @Tchanders, as I'm fairly certain enwiki would consider this extra risk for their usage as well (that said, I'm not an enwiki user, so...).

Hope this makes sense!

I do think both is the correct answer - I posted in https://phabricator.wikimedia.org/T406281 with some thoughts there.

To be clear, I don't mean implementing all of those things as part of this ticket. I mean that I assume that it might make sense to create a post-login point that checks a variety of conditions that might trigger an interstitial, so that it's pretty straightforward to add those other sorts of examples going forward.

In T406281#11370978, @sbassett wrote:

This functionality is likely only necessary under the single recovery code model which, as has been noted, is not the current configuration within Wikimedia production and likely never will be again.

@Peter Could you put some more rationale on the ticket here, about why work related to IP blocking of Beta cluster involves needing access to security tickets on phabricator?

Yes, this change makes sense to me from a product and user safety perspective.

Good points on the accordion - I was not thinking at all about other languages. I defer to what you think best. Among the above visual proposals, I like the accordion version, and the rightmost version (the smallest text) the most.

For the message, I would remove the "Why do I need an account?" subheader and expander/collapser, and say something in active voice. (Also, we don't like to say "anonymous editing", as registering a user account is, if anything, more privacy-protective.)

I think this would also be an opportunity to have a UWER-focused message to add as many options/passkeys as possible.

@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):

In T101017#11285755, @sbassett wrote:

Just FYI (and likely many years beyond relevance at this point), but we now have #acl_release_security_pre_announce, which is used to subscribe trusted mediawiki operators to high/critical MediaWiki bugs prior to their release. Folks can request to be added to this group (via a new, Security-Team -tagged Phabricator task) and they will then be vetted by the Product Safety and Integrity team.

To follow up, and with apologies for the conflicting comments in the two tasks, the policy is as I described above - the group is not open for applications, and has no guarantees associated with it. I'll add a comment to the other task to clarify there as well.

To note here, hCaptcha is now running in production for Special:CreateAccount on English Wikipedia, test2wiki, and several other production wikis. We encourage folks on this thread interested in improving accessibility to try it out. For example, we'd be interested in hearing what the screen reader experience is like. test2wiki is likely the most appropriate place for testing that actually creates new accounts.

To note here, hCaptcha is now running in production for Special:CreateAccount on English Wikipedia, test2wiki, and several other production wikis. We encourage folks on this thread interested in improving accessibility to try it out. For example, we'd be interested in hearing what the screen reader experience is like. test2wiki is likely the most appropriate place for testing that actually creates new accounts.

Just to mention here as well - https://phabricator.wikimedia.org/T407167 is resolved, since we have reverted back to 10 user codes. The goal had been to simplify the recovery code experience, and we relaxed the reauth timer to go along with these changes to reduce lockout risk, but this just wasn't a good enough solution. We'll be more cautious before adjusting this again.

We had briefly discussed this last quarter, and I had suggested 100. That's still my suggestion - something impractical for normal usage to reach, but still a normal system operations cap.

In T407666#11292535, @A_smart_kitten wrote:

In T407666#11292201, @EMill-WMF wrote:

@RheingoldRiver I am sorry to give you a disappointing answer here, but the acl*release_security_pre_announce group is not open for applications.

For the record, I feel like the point should be made that this seems to conflict with what was said in T101017#11285755 a few days ago (my emphasis added):

In T101017#11285755, @sbassett wrote:

Just FYI (and likely many years beyond relevance at this point), but we now have #acl_release_security_pre_announce, which is used to subscribe trusted mediawiki operators to high/critical MediaWiki bugs prior to their release. Folks can request to be added to this group (via a new, Security-Team -tagged Phabricator task) and they will then be vetted by the Product Safety and Integrity team.

@RheingoldRiver I am sorry to give you a disappointing answer here, but the acl*release_security_pre_announce group is not open for applications. It is extremely small, rarely used (just once so far), and invite-only. It does not have any SLAs/SLOs -- we make no promises around it, and it may or may not ever become a formal process. We could make this more clear in the description for the group, so we will do that to avoid mismanaging expectations.

@sbassett Yep.

@sbassett Thanks - I spoke with @Samwalton9-WMF (who we recently granted access to), and confirmed that @jsn.sherman is the tech lead for that project and has a similar need for access as Sam does. Thumbs up from me.

In T406281#11242364, @Catrope wrote:

In T406281#11240577, @AAlhazwani-WMF wrote:

are we suggesting to show this message to everyone? or for instance, if a person has already 1/2/... 2FA methods does it make sense to give them this advise?

I think it does, yes. You could have 15 2FA methods set up, but if you logged in with a recovery code, that probably means you don't have access to any of them. That might be OK because that lack of access might be temporary (e.g. you left your security key at home), which is why we shouldn't be extremely aggressive about it, but we should still encourage them to set up a new factor because that's the surest way for them to avoid locking themselves out.

among those ideas, my suggestion would go for 3 to sequence the communication.

With #3 I worry that people will miss it, especially on desktop where it's relatively small compared to the rest of the UI. I think toast notifications are good for success/confirmation messages where it's OK if the user doesn't see them, but for this I would prefer something more prominent like #1c or #2 (but with a warning message instead of an info message, and without the dismiss icon).

i've also included other type of communications like the "copied to clipboard" confirmation. if we find it too intrusive we could also consider using the cdx-tooltip instead of a cdx-message.

I think the copied confirmation is fine as you've designed it.

I like this. @AAlhazwani-WMF or @KColeman-WMF what do you think?

Yes, I can see the dashboards I was intending to now! Thank you very much for everyone who helped resolve my issue, and apologies for my difficulty understanding some of the finer points around our access management.

In T404903#11195771, @Dzahn wrote:

The docs say membership in wmf should be enough to log into superset. Can you not log into it?

Or can you log into it but this request is specifically about seeing more private data including PII ?

@Aklapper This: https://www.mediawiki.org/wiki/Product_Analytics/Superset_Access#Requesting_access Specifically, the this Phabricator form link.

I am not actually certain if I have shell access or not. My account at https://idm.wikimedia.org says my shell username is ericmill, but I don't recall specifically requesting shell access.

This is part of an initiative to make our on-wiki 2FA system more accessible and useful for a broader, less technical audience than is currently able/required to use 2FA today. As part of that, we're trying to remove as much technical nomenclature (including protocol names) from the copy and UX of the site. The users who would recognize the terms TOTP and WebAuthn are also the least likely to need help with this in the first place, so I think we should proceed with Authenticator app and Security key.

That initiative was just about 2FA access, not retroactively re-evaluating anything else, so I think we should proceed and re-enable.

@EMill-WMF will decide that based on T401742.

To be clear, the main goal here is to remove the risk of unexpected changes (including compromise) of the part of the JavaScript that necessarily has access to the parent document context before establishing the iframes that the rest of the code is then loaded into.

In T401772#11151390, @Tgr wrote:

Would it makes sense to pre-fill this with something generic ("authenticator app") for the user's first TOTP key, to reduce friction? (The names will eventually be editable, right?) Or make it clearly optional?

In T403683#11146339, @Bugreporter wrote:

Security key

This term can instead mean any 2FA token regardless of type. Also it is too similar to "security code" proposed in T159915: Remove the word "CAPTCHA" from all Wikimedia user interface strings (though I oppose the latter task).

Let's focus conversation on the most technically reasonable way to reflect a user's choice to remove lat/long (and other data extracted from the EXIF) at upload time from the form, and reflect those choices in the EXIF data of the resulting publicly available image.

@karapayneWMDE Just being a developer on a significant project isn't enough to grant full security issue access, which cuts much wider than any one project. (To be clear, this is the position we're maintaining for WMF as well.) If you're experiencing issues in your work, feel free to reach out separately to discuss it.

This is clearly nice, though I think it would be bearable for this feature to show up post-launch if we needed to descope something.

What about (in addition) redirecting https://en.wikipedia.org/wiki/Special:Manage_Two-factor_authentication (and other non-auth domain URLs to this same page on other wikis) to the auth domain version of it at https://auth.wikimedia.org/wiki/Special:Manage_Two-factor_authentication ?

In T401008#11073176, @zoe wrote:

If that's the threshold I think I probably don't meet it. I can keep being manually added to tickets on a need-to-know basis.

From the Security side, we're good to go on this - @Samwalton9 leads product development on moderator tools that a heavy overlap with security and privacy efforts.

From the Security side, we're good to go on this - @MMoss_WMF works closely with us on security and privacy issues and may need access to tickets on a regular basis to support their work.

We'll also need significantly more context to support approval than is present on this ticket. Please include a more detailed rationale (while remembering that this is a public ticket).

Before this can be approved, I would like some more context on this ticket to support the request. What security ticket was fielded? Why do we think it will be so recurring that manual adding will be a big hassle?

I believe we should always prioritize WebAuthn. If a user has a phishing-resistant option registered, we should be encouraging them to use it -- and also making it more noticeable if they actually do end up at a phishing site (which will not be able to offer a working WebAuthn UI). This will be especially important for users with extended rights and WMF staff that may be targeted for phishing. We can make it pretty easy for the user to select to use an alternative method to log in. I'm open to user feedback, and/or seeing it show up in analytics that users are switching to alternative methods more than we might expect and which seems high-friction, but I think we should start from a posture of WebAuthn-first.

In T399664#11034345, @Bugreporter wrote:

Affected users should somehow be awared that they can enable 2FA.

Thank you, @Jly !

+1 as well - good solution.

In T396155#10896926, @KStoller-WMF wrote:

In T396155#10894941, @AAlhazwani-WMF wrote:

i'd say that reviewing both the copy nor the design of those (echo) notification emails is out-of-scope for this task.

Agreed. I think simple improvements (like the parent task that stalled out in 2019) often go unaddressed because we get caught up in the broader scope of the full project and all the related enhancements we might eventually want to pursue.
I suggest we take a lightweight, agile approach here: let’s focus on making some quick copy improvements and measure their effect. This allows us to make meaningful progress without getting stalled by the larger, more complex set of changes that we may not have capacity to tackle right away.

In T368224#10896416, @Jly wrote:

I've posted the results in P76908, and we will proceed with the removals sometime this week

In T58074#10890604, @Dreamy_Jazz wrote:

Have we considered providing an Special:InvalidateEmail link in the email?

I suggest it because if the email used is not associated with the account, then I'm not sure how someone would opt-out of the emails without logging in to the account or confirming the email address. Confirming the email is the opposite of what they want to do and managing email preferences is impossible without knowing the account password.

The MediaWiki-extensions-CentralAuth extension used such a link for emails generated by sendConfirmAndMigrateEmail.php.

As such, I would strongly recommend providing this link in the email version to avoid a situation where an LTA could repeatedly send emails to a user they want to annoy by creating loads of accounts that have the email address of the user they want to annoy.

In T396155#10890356, @Michael wrote:

1. Should we pursue implementation of BIMI (Brand Indicators for Message Identification), and if so, what are the technical and policy requirements?

I only have glanced at the requirements, but it seems it will require some changes to our DNS records or something? This will definitely involve more teams, not sure which exactly. Traffic? serviceops? SRE? Figuring out the correct team and talking to them will be part of answering this question.

It would good to see if there are precise criteria that we could identify and use to separate accounts into tiers of how likely/known they are to be good-faith accounts. Ideally we would get enough confidence to handle those accounts programmatically differently during authentication, recovery, moderation, and other functions in the wikis.

In T220057#10856440, @kostajh wrote:

I think a notification similar to T58074: Echo: Generate periodic web notification to nudge users to confirm an unverified email address would be helpful. Alternatively, we could do something like GitHub does, where after login you're taken to an interstitial page to review your details and mark them as confirmed.

I think something got lost in the shuffle here - the first bullet is implying they might get locked out during EmailAuth (which is only true for accounts with emails that remain unconfirmed), but where we started is saying that if they lose account access, we cannot recover them (which is true for both email-less accounts and accounts with unconfirmed emails. The first bullet implies that the user won't be able to login from an unrecognized device or location as a matter of policy unless they have a confirmed email, but that is not our policy.

In T390780#10831371, @sbassett wrote:

@EMill-WMF - So just to confirm, did you want to mask all domains, or is there a list of popular domains you'd prefer to leave unmasked? The former is the simpler solution, but if there's a list of popular domains you'd like to leave unmasked, can you confirm that list here? @Tgr had suggested some options in T390780#10712923.

In T150898#10845230, @Sdrqaz wrote:

This needs messaging to the communities before it's made live.

For the record, it seems like individual CU/OS were not notified directly despite the change being in effect.

In T390780#10829467, @kostajh wrote:

@EMill-WMF could you please let us know if you think the domain needs to also be masked? The proposed patch only masks the local part of the email address.

Someone may register with a valid email owned by someone else, and it would be spammy to send those notifications periodically without a way to opt-out from them.

In T365525#10807887, @JWheeler-WMF wrote:

@sbassett is it possible to prioritize and / or escalate the CommunityRequests Extension security review?

In T393615#10814201, @sbassett wrote:

In T393615#10804789, @Tgr wrote:

In T393615#10801595, @taavi wrote:

FWIW, it'd be great if whatever you come up with here is usable for T391699: Add functionality to disallow bureaucrats who do not have 2fa enabled to grant certain privileged rights/groups as well :-)

The problem with that is that it's almost entirely useless as described. An attacker can take over a bureaucrat account, set up 2FA, and then grant interface-admin - it is barely a slowdown.

It's far from perfect security, but this was also viewed as a way to nudge a significant number of bureaucrats into setting up 2fa for their accounts. At least that was one of my hopes.

I've enabled MFA.