Where does that is supposed to log to? Logstash? On-wiki log that is accessible to functionaries (if we want to do T210919 and T209749)? If so, then the messages shall be localizable and not be hardcoded in code.

In T100373#4722366, @Tgr wrote:

There seems to be a lot of confusion around this. This is my (possibly mis-) understanding, based on some googling:

• Originally, there was the FIDO U2F standard which describes a Javascript interface between the website and the browser, various protocols (USB, NFC, Bluetooth etc) for the browser talking to the second-factor device, and a protocol for the device talking to the web server with the mediation of the browser.
• The website-to-browser and device-to-server part of the protocol is now superseded by WebAuthn, which is a W3C standard (CR) since two months ago. It also generalizes login flows - instead of a second factor, the device can now be single-factor (passwordless login) or one of multiple factors (e.g. hardware key + biometric identification device).
• the browser-to-device part is now being superseded by FIDO2 CTAP (which also supports single-factor and multi-factor). This part doesn't really concerns us.
• The FIDO U2F API is supported by Chrome and Opera (desktop only), and supported behind a feature flag (security.webauth.u2f) by Firefox. The standard is superseded, so nothing else will support it. Here's a test page.
• WebAuthn is supported by Chrome, Opera, Firefox and Edge (which un-feature-flagged it two months ago). It's also supported on mobile (caniuse claims no Chrome support but according to Chrome platform status it's supported since 70, and I can verify it works). Here's a test page.
• CTAP is backwards-compatible (it defines two protocols, CTAP1 for two-factor which is basically just U2F and CTAP2 for single-factor/multi-factor, which is not U2F-compatible), so all old devices (Yubikey etc) work with WebAuthn for second-factor but not the other flows. The Javascript part is not backwards-compatible. I'm not sure about the device-to-server protocol but I think it's also backwards compatible.

So there is not much point in integrating U2F proper (everything that supports it supports WebAuthn but not the other way around), we should do WebAuthn instead.

Up next might be compromising a steward and global lock everyone else out before losing permissions, but if you can't log in, have fun identifying yourself to operations to restore access, and deal with the attacker. Securing permissions with e.g. OATHAuth is a problem if the authenticator key gets compromised too, though that's less likely, therefore its favored that sysops be required to use OATH, IMHO

Assigning per patch uploader
Closing per SAL entry above

• If a compromised sysop blocks all other sysops/crats, there have to be ways for the other sysops to unblockself and stop the compromised account
  • Stewards don't usually deal with users of private/fishbowl wikis via userrights-interwiki . Some of the wikis (T131385) can't be managed this way. Emergency way in such a case, is having staff to promote self if on-wiki sysops aren't around
• If a sysop blocks self for any reason, there is no point to allow to unblock self. Possible way to achieve this is to look in the last log message to see if its a self action

@Pamputt please confirm if that's what you meant to do and if yes, confirm if it's working as expected

Per above.

In T149610#2791165, @Cumbril wrote:

I opened new discussion in the community. It seems that there is consensus for creating Autopatrollers group in etwiki. Going to wait for a few more days to collect opinions.

Should I open new task for this?

Yes, fallback, and is to be translated.

@TheDJ because the initial point of T132972 was to revert this site-wide special default behavior. If we're going to revert this back to T13776 's way, then it'll be as if T132972 didn't happen.

In T135521#2778278, @Dereckson wrote:

Redirect from ec.wikimedia.org to the main page issue

There is also perhaps a need to adjust the value of [[MediaWiki:mainpage]]. If that doest't work, you can create a redirection from Página principal to Main Page.

[Housekeeping]
Closing because since the special site-wide behavior was reverted in the subtask, there's no longer a special site-wide configuration other than default mode=categories that this task refers to.

In T137812#2778542, @MZMcBride wrote:

The CategoryTree extension may have behavior outside of its parser function and the Special:CategoryTree page, though this point remains unclear. I still do not understand what ?mode= in the task description is referring to. https://en.wikipedia.org/wiki/Category:Redirects_from_alternative_spellings?mode=CT_MODE_ALL doesn't do anything different for me.

Reassigning since otherwise the task will be stalled on for years if not dealt with. Months passed but there is no logo:

So to summarize, @IKhitron wants to user-override the categorytree expanders (mode=all) while browsing a category page (on the page, and not the special page, although it has the same default behavior) without setting it (mode=all) as site default for all users on the wiki while the default is mode=categories , without having to URLhack the page every time. Normal browsing case across categories.

Default is to show only categories. Per ^ a preferences option is wanted for user own override from site default option so that the user won't have to select view mode on Special:CategoryTree every time you open that special page.

@Kipod Special:CategoryTree has a setting to show only subcategories, only pages that are not files, or all pages, if you didn't notice.

There's a difference between viewing subcategories and pages outright on the category page itself (the default is indeed to expand only subcategories) and viewing the subcategories via the category view link that goes to Special:CategoryTree/desiredcategory that shows also included pages when the All pages viewing mode is selected on the same page.

@Dereckson we do allow granting by sysops on most wikis, and the relvant newiki config is here

@Cumbril much better. Point the above claim on the local community, and decide which rightset autopatrolled are going to have, if different from default (autopatrol to autopatrol own revisions). Hewiki for example let autopatrollers see Special:UnwatchedPages.

first proposed creating Autopatrollers group and right – to have some right that can be used as a flag. But then I thought, why use autopatrol right if the Mediawiki software allows creating any arbitrary right.

What are the downsides of creating a new user right (other than being useless for true security)?

@Aklapper : I chose Create Subtask straight from the parent task. Subscribers, assignees, projects were pre-filled and carried over.

Reopenng due to T149840

I referred to the variable, not you as logos-creator :D

$wgLogo doesn't eat SVG logos directly, but PNG versions of them. So create png logos for $wgLogoHD that should be clear and highres enough (cc T145017) and update commons page accordingly ;)

Deployed

Smell like another instance of what we're been already seeing with trwiki, trwikiquote (T144638), and ruwiki (T144599) asking for new permissions groups to delegate rights based on classes of editors. Remember that sensitive rights such as editinterface, gadgets-edit, gadgets-definition-edit, editusercss, edituserjs are not to be grantable by sysops . According to w:et:ListGroupRights , so-called "tools" are actually gadgets.