Could you share more about the purpose of the study, why it needs to live-connect in the client to Cornell's servers, and the roadblocks you encountered in porting it to Toolforge?

We're focused right now on platform-based protections (namely re-authentication), rather than introducing more social coordination. That's a development focus for us for the next few months.

I am designing a gadget that will make a request to one of the allowed hosts in the CSP! Can you clarify whether *.wmcloud.org are intended to remain allowed in the enforced CSP long-term, or whether the report-only policy is expected to become stricter in a way that would block these requests later?

It's fine with me to make this public if there's no longer any security issue, and it's starting to be referenced in other public tickets.

After reviewing the community discussion, and the domains in the list, we don't think this is a compelling case to add to the allowlist. We recommend exploring alternative approaches to hosting content first, as was also raised by community members in that discussion.

In T419265#11740324, @Sj wrote:

Is it possible to generate a list of requested domains that are being blocked by the CSP, in some browsable way?

Rather than requiring every tool-user to figure out how to find phab and report the problem, we should be able to track down which tools are still blocked and proactively unbreak ones that are pinging trusted domains or using otherwise known services; or at the least reach out to tool-maintainers whose tools are broken to streamline a resolution.

We are generally trying to unbreak things, but this is a pretty heavy set of domains. Could someone provide a little rationale for why all of these domains need to be pulled in live client-side?

@andritolion Thanks - we do have https://phabricator.wikimedia.org/T416159 for this, as a subtask here. It is planned at some point, we plan to lean more heavily on passkeys over the next few months.

@andritolion What kind of authenticators are you using?

Sharing this schema, used in some 2018 research.

Yeah, to be clear the idea here is to collect data on all (or at least above some popularity threshold) outbound citation links, not just ones to a particular service.

In T197160#11698961, @Nux wrote:

In T197160#11697639, @EMill-WMF wrote:

However, I still think in most situations a password should be enough. Typically, the second factor is used to establish trust between the service (here Wikipedia) and the user's browser.

That's not how we think about the security model for two-factor authentication - it's there, and required for users with various kinds of powerful rights, because of the plausibility that someone's username and password becomes known by an attacker. Last year's account compromise incident was a reminder of how widespread stolen credentials are (whether from other breached services where passwords were reused, or compromised laptops someone logs in from, or other).

Yes, password can be stolen, and that is why you establish trust to the the user's browser, not only to his password. You don't need to re-confirm trust on each page view or even on each login. The trust token can be saved in a long term secure cookie (not readable from scripts).

However, I still think in most situations a password should be enough. Typically, the second factor is used to establish trust between the service (here Wikipedia) and the user's browser.

I have two PCs and one laptop from which I contribute. I also use two phones. Passkeys are not that great for such a situation, to say the least. Password managers solve most problems that passkeys solve (2FA solves the rest of them) and support more setups.

Just wanted to link to my comment in https://phabricator.wikimedia.org/T197160#11685043 for this thread as well, about how we've been thinking about re-auth -- which is definitely more streamlined than what people are currently experiencing with the quick patch we rolled out last week.

In T197160#11679885, @RoySmith wrote:

In T197160#4281158, @Bawolff wrote:

If we make too many things require reauth then we run the risk of annoying users. We also run the risk of making entering your password a common occurance which could aid phising attacks

@Bawolff 's point is entirely valid, and was even more so when it was written 8 years ago. But...

In a previous job, the setup was that 2FA was via a Yubikey. We had those cute little things that plugged into a USB-A port and just had a nubbin sticking out. One lived in a port on my laptop all the time so re-authing was as simple as reaching out with a fingertip and tapping. Now we're in 2026 and this sort of tech has become ubiquitous even on consumer-level hardware. Right now, I'm working on my personal machine with Touch-ID, so basically the same setup.

Did functionality break, or are you just noting the error in the console? The error messages describe that these are report-only violations, so no further action was taken besides logging it.

It is better to open a separate ticket (but you could include all of them at once in it).

We plan to re-enable this via the allowlist, thanks for flagging.

We plan to unbreak this by updating our allowlist - thanks for flagging.

We plan to add support for http://localhost - thanks for flagging this.

I shared some broader thoughts on https://phabricator.wikimedia.org/T419234#11682841 - from that:

Feel free to open a ticket to describe what broke and how you were using it. But just to be clear, our goal isn't to allow infinite developer flexibility here in pulling dynamically from third-party hosts (and we're not going to allowlist IP addresses, for instance, which change hands even more fluidly than domain names).

To describe the two mitigations we put in place yesterday, I'll share here what I just posted on the Meta talk page:

Deleting these notes is not not primarily a technical issue, but rather a social or ethical issue. Can I request that someone from the Wikimedia Foundation who feels empowered to speak on social and ethical issues in community governance please identify themselves, make themselves a point of contact for social questions, and make a statement on deleting this content?

In T418484#11655548, @Xaosflux wrote:

Taking a look at myself ( https://meta.wikimedia.org/wiki/Special:CentralAuth/Xaosflux ) - were it not that I had a global group, I would all of a sudden become un-autoconfirmed on ~591 projects, I don't think that is improving things.

No, I don't think this is resolved - please remove the current dump as well.

@STei-WMF Reach out to us on Slack to work it out. We'll need to be precise about it, because...

Just flagging that I made some edits to the table to remove references to Trust and Safety Product - it had some wikitext markup around phab tags, so mentioning here in case something needs updating.

In short, this is a technical exploration of MediaWiki as a trust anchor for external tools, without shifting any cryptographic or safety burden onto the Foundation.

Just to add my voice here - I would recommend we remove this dump. Given what Phabricator contains, I think the user benefit would at least need to be obvious and ongoing, and it doesn't sound like it is. I've certainly been involved in tickets that didn't start out appropriately access restricted, and it got noticed and done later - I'm sure others have had the same experience. Let's remove it, and if use cases come out of the woodwork that we should support, perhaps there are safer and more tailored ways to support them.

Hi @valcio - thanks for opening this to get our thoughts. I want to be upfront that, while we of course believe in the availability of E2EE communication as a general matter, we're very unlikely to support Wikipedia offering an E2EE messaging system of its own. That would be a very significant area for the platform to expand in to, with both high technical and cryptographic complexity, and non-technical challenges to user safety, that organizations with a primary focus on private messaging are better suited to undertake. It's not just a matter of needing code to implement it. Not trying to tell you not to work on this, or projects like it - just that it is not something we would expect to devote resources to supporting here.

Just to +1 something @Ladsgroup said above, but hasn't been the main focus of the discussion:

Yes, @hashar you're right that this is a downside of the change we made to accommodate DMARC enforcement. Hopefully the context above (our list announcement, and the Mailman technical limitations) helps to explain why we made this choice.

In T414014#11502878, @Joe wrote:

Indeed T391397 is the cause of that other rule. I think we should just ban their UA completely.

@Novem_Linguae Thanks for your patience. Your request is approved.

Also, given the apparent lack of interest by the security team, whom should it be discussed with?

@Taylor No. This is not a venue for distributing any software to end users, malicious or benevolent. Do not post any further executables here.

Ah, I see @KStoller-WMF moved the discussion to T413130, sorry for extending this unnecessarily. As you can see there, we did adjust the language in a way that keeps things simple, while also partially resolving some of the points raised (it still has "Confirm email" on the button, but uses "confirm your email address" for context in the narrative above).

It's not a matter of brevity v. precision. It's a matter of something that doesn't make sense v. something that does. The current wording doesn't make sense. At en.WP's village pump, another editor suggests "Your Wikipedia account setup is almost complete". That would work too.

@MLechvien-WMF This is approved - as @sbassett said, thanks for your patience.

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 @Blake - 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).