I would like to know why bureaucrats should not be allowed to revoke IA
rights.

I am still unconvinced why 2FA comes into picture for IAs.

In T282624#7082657, @Tks4Fish wrote:

As for the whole "you should make the function not work if 2FA isn't enabled" there's a huge BEANS complication here, so not going to go deeper.

The check only works in the moment, yes, but there's work on the pipelines for regular audits of 2FA status for users that should have it enabled.

Due to that, 'crats can't also remove the flag, as stewards doing the audit would be overstepping the boundary when removing it due to lack of 2FA, and 'crats can't check it due to the above.

I'm also reopening this task as this comes from the office and thus doesn't need consensus.

How would bureaucrats removing 2FA from the request of the user (or abuse unrelated to 2FA) be an issue? I don't think 'crats need to check for 2FA when removing access; the only reason for stewards to remove should be for the lack of 2FA and nothing else according to the proposal. And yes, it may be an office decision, but you know what happens when office actions are implemented without proper discussion (hello WP:FRAM), and hence I still think discussion is needed at the very least. But I won't revert your action.

Also, if you don't explain why "you should make the function not work if 2FA isn't enabled", us users can't understand why that's not an option (I'm not sure what BEANS has to do with that either, unless I am missing something).

What a strange proposal here. WMF should just implement the sensible option everyone is waiting for for years already, namely, that a user who doesn't have 2FA can't be granted 2FA-requiring rights or is prevented from exercising them (and loses them when he disables 2FA).

In T282624#7082821, @MF-Warburg wrote:

What a strange proposal here. WMF should just implement the sensible option everyone is waiting for for years already, namely, that a user who doesn't have 2FA can't be granted 2FA-requiring rights or is prevented from exercising them (and loses them when he disables 2FA).

T197137 and T150898 have been around for a while that could address this.

In T282624#7082771, @Leaderboard wrote:

How would bureaucrats removing 2FA from the request of the user (or abuse unrelated to 2FA) be an issue? I don't think 'crats need to check for 2FA when removing access; the only reason for stewards to remove should be for the lack of 2FA and nothing else according to the proposal.

<small>Bureaucrats would remove IA, not 2FA, think you mixed up the names.</small>'Crats won't check 2FA when removing access. What I'm referring to is a regular audit for 2FA status of IAs. If they don't have it enabled, the access is removed after a warning and a period to reenable it. The issue starts because, when stewards do that, local 'crats would say that stewards are overstepping their boundary, and that is why it'd the removal is also being removed from 'crats.

In T282624#7082771, @Leaderboard wrote:

Also, if you don't explain why "you should make the function not work if 2FA isn't enabled", us users can't understand why that's not an option (I'm not sure what BEANS has to do with that either, unless I am missing something).

Discussing why is saying "hey, do this and that and you can go over our security", that's why WP:BEANS was invoked.

In T282624#7083009, @Tks4Fish wrote:

In T282624#7082771, @Leaderboard wrote:

How would bureaucrats removing 2FA from the request of the user (or abuse unrelated to 2FA) be an issue? I don't think 'crats need to check for 2FA when removing access; the only reason for stewards to remove should be for the lack of 2FA and nothing else according to the proposal.

<small>Bureaucrats would remove IA, not 2FA, think you mixed up the names.</small>'Crats won't check 2FA when removing access. What I'm referring to is a regular audit for 2FA status of IAs. If they don't have it enabled, the access is removed after a warning and a period to reenable it. The issue starts because, when stewards do that, local 'crats would say that stewards are overstepping their boundary, and that is why it'd the removal is also being removed from 'crats.

In T282624#7082771, @Leaderboard wrote:

Also, if you don't explain why "you should make the function not work if 2FA isn't enabled", us users can't understand why that's not an option (I'm not sure what BEANS has to do with that either, unless I am missing something).

Discussing why is saying "hey, do this and that and you can go over our security", that's why WP:BEANS was invoked.

The typo is regretted. If this proposal passes you can always make a note like "stewards will remove the interface admin irrespective of the presence of bureaucrats if 2FA is not enabled". Or better still, ask the bureaucrats to remove IA and remove it manually only if the bureaucrat does not take action (within say a week).

As for the second part, I think some more detail should be provided beyond what's there right now for sure, personally I have no idea why that's a bad idea.

The issue starts because, when stewards do that, local 'crats would say that stewards are overstepping their boundary, and that is why it'd the removal is also being removed from 'crats.

Huh? But local crats can remove admin on request, and so can stewards, but crats don't criticise the stewards for removing it (or do they?)

Discussing why is saying "hey, do this and that and you can go over our security", that's why WP:BEANS was invoked.

I also don't see how it could possibly be a bad idea. Lots of big sites enforce security requirements technically.

The current requirement is that one has to have 2fa enabled at the time when IA rights are applied, but there is neither a policy (is it?) nor a technical reason not to disable 2fa at any time later. Will stewards review or monitor this in any way?
A more simple approach from the bureaucratic point of view would be to technically check the 2fa status by the software at the time the group rights are to be used, so that IA (or say CU) features can only be used when 2fa is enabled at that time. This of course would require a software change, but it appears to be a much more reasonable and flexible way to me.

In T282624#7083246, @jrbs wrote:

Hi all. Thanks for your input. I apologise for the hasty implementation here.

Taking into account the feedback provided here, T&S will put together a more comprehensive communications plan around this change.

In T282624#7081664, @Leaderboard wrote:

Also, I am not happy with the practice of WMF delegating everything it wants to stewards - why can't the WMF do it themselves if it's really that important? Remember that stewards are often overworked (T162297).

I would like to clarify that this change was not made alone. We have been discussing this with the Stewards for months. This is not a case of a random decision by a rogue staffer, it's just a staffer who made some communications mistakes.

In any case - please allow us some time to come up with a better way to communicate how this change will happen, what it will look like from a practical perspective, etc. I would like to ask @Quiddity to remove or potentially reword the Tech News item about this task too please. :)

A couple of notes:

• Why were only stewards consulted in this proposal, to begin with? After all, the plan affects everyone, and I see no sign of anything that requires a "top-secret" plan like what I'm seeing here.
• It's a question of "if", not "how"/"when". You haven't addressed the other questions (yet?), such as why the alternative of having the software check for 2FA is not better. Not sure if this is part of your "communication" plan.

I'm also just in general concerned with the continuous increase in requirements to edit JS/CSS. I understand the security complications, but we're approaching the point where for all but the main 10 or so sites, you might as well disable JS editing completely. And considering how important gadgets still are.... that's seems unwise to me. The gadgets and user scripts are a big part of what made Wikipedia. We need to balance value with security here.

I don't think that this would be wise to do, local bureaucrats are responsible to local communities, they have the mandate of the project they operate on and the chance of abuse is really small. I highly doubt that this would improve anything, in fact the opposite might happen.

In T282624#7083246, @jrbs wrote:

Hi all. Thanks for your input. I apologise for the hasty implementation here.

Taking into account the feedback provided here, T&S will put together a more comprehensive communications plan around this change.

In T282624#7081664, @Leaderboard wrote:

Also, I am not happy with the practice of WMF delegating everything it wants to stewards - why can't the WMF do it themselves if it's really that important? Remember that stewards are often overworked (T162297).

I would like to clarify that this change was not made alone. We have been discussing this with the Stewards for months. This is not a case of a random decision by a rogue staffer, it's just a staffer who made some communications mistakes.

In any case - please allow us some time to come up with a better way to communicate how this change will happen, what it will look like from a practical perspective, etc. I would like to ask @Quiddity to remove or potentially reword the Tech News item about this task too please. :)

@jrbs If this has been in discussion with stewards for months, then why hasn't it been in discussion with the community for weeks? What makes it now urgent to implement? If there is clear security issue then fix it, not leave it open and talk with stewards. Run audits, impose sanctions on those who are not complying, Instead, what do we have here? Secret squirrel business.

I understand the requirement for WMF to make and implement security changes, zero issue.

It is not WMF's role to make community's operational decisions, as in what stewards alone can do. T&S does a disservice to the community when it so simply ignores the years of community operation. The stewards were not set up to be, and should not be, your sole point of community consultation on these matters. Read the scope of their role. For matters of this significance it is simply wrong for WMF to think that they get to impose their solutions, especially only in consultation with stewards. I am a little disappointed that stewards are not kicking back on this issue telling you that this is not for their decision, and saying that the community needs to be consulted.

WHAT ARE WE DOING HERE IN PHABRICATOR??? That we are having to have this discussion on a phabricator speaks volume to the problem of staff isolating from community on general matters, and increasingly on so many matters. Do you not see this particularly as an issue? This is a technical forum, not the place for our social conversations.

I ask that you bring the social issues to metawiki. Set out the problem, set out the exact principles, set out the non-negotiables, and then what is negotiable. Please stop the change the methodology of benevolent dictatorship. I, personally, don't mind temporary measures to fix immediate concerns, but if this is months of existing discussion, it seems that you lost that opportunity.

[Speaking with the hat of a former steward, and someone with IA rights]

In T282624#7087006, @Billinghurst wrote:

It is not WMF's role to make community's operational decisions, as in what stewards alone can do. T&S does a disservice to the community when it so simply ignores the years of community operation. The stewards were not set up to be, and should not be, your sole point of community consultation on these matters. Read the scope of their role. For matters of this significance it is simply wrong for WMF to think that they get to impose their solutions, especially only in consultation with stewards. I am a little disappointed that stewards are not kicking back on this issue telling you that this is not for their decision, and saying that the community needs to be consulted.

WHAT ARE WE DOING HERE IN PHABRICATOR??? That we are having to have this discussion on a phabricator speaks volume to the problem of staff isolating from community on general matters, and increasingly on so many matters. Do you not see this particularly as an issue? This is a technical forum, not the place for our social conversations.

I ask that you bring the social issues to metawiki. Set out the problem, set out the exact principles, set out the non-negotiables, and then what is negotiable. Please stop the change the methodology of benevolent dictatorship. I, personally, don't mind temporary measures to fix immediate concerns, but if this is months of existing discussion, it seems that you lost that opportunity.

Please calm down. I think I made it quite clear that this was a misstep. I am human and make mistakes.

My opinion as a crat on dewiki: I think the granting/revoking should stay with the crats. That is because they know their local community and can assess wether a user is trustworthy from a security standpoint but also wether someone actually has the technical knowledge to use the IA rights. For example: On dewiki there are some folks who I would consider trustworthy for IA but they don't have the technical knowledge to use it. And vice versa. If one of our dewiki tech gurus says that he needs IA to fix some of the many broken scripts I will gladly grant IA to him. Leave decisions like these to the local communities.

Does only the technical implementation (rights assignment) move to the stewards, or also the decision the rights are to be assigned?
Do local policies remain in place, or are they overridden by a new global policy?

In T282624#7087964, @XenonX3 wrote:

My opinion as a crat on dewiki: I think the granting/revoking should stay with the crats. That is because they know their local community and can assess wether a user is trustworthy from a security standpoint but also wether someone actually has the technical knowledge to use the IA rights. For example: On dewiki there are some folks who I would consider trustworthy for IA but they don't have the technical knowledge to use it. And vice versa. If one of our dewiki tech gurus says that he needs IA to fix some of the many broken scripts I will gladly grant IA to him. Leave decisions like these to the local communities.

As far as I have understood this proposal correctly, the requests for this user rights and the decision as to whether a user should receive them should continue to take place in the local community and only the actual technical allocation should be carried out by the stewards, similar to the Importer rights.

see

In T282624#7080531, @jrbs wrote:

'crats can still make use of their usual processes and policies, they'd just have to file a request on SRP for the technical step to be completed.

In T282624#7087157, @jrbs wrote:

In T282624#7087006, @Billinghurst wrote:

It is not WMF's role to make community's operational decisions, as in what stewards alone can do. T&S does a disservice to the community when it so simply ignores the years of community operation. The stewards were not set up to be, and should not be, your sole point of community consultation on these matters. Read the scope of their role. For matters of this significance it is simply wrong for WMF to think that they get to impose their solutions, especially only in consultation with stewards. I am a little disappointed that stewards are not kicking back on this issue telling you that this is not for their decision, and saying that the community needs to be consulted.

WHAT ARE WE DOING HERE IN PHABRICATOR??? That we are having to have this discussion on a phabricator speaks volume to the problem of staff isolating from community on general matters, and increasingly on so many matters. Do you not see this particularly as an issue? This is a technical forum, not the place for our social conversations.

I ask that you bring the social issues to metawiki. Set out the problem, set out the exact principles, set out the non-negotiables, and then what is negotiable. Please stop the change the methodology of benevolent dictatorship. I, personally, don't mind temporary measures to fix immediate concerns, but if this is months of existing discussion, it seems that you lost that opportunity.

Please calm down. I think I made it quite clear that this was a misstep. I am human and make mistakes.

Joe, I was perfectly calm.

I am not blaming any individual. This is a system and process failure. You have a whole team of people with whom you work, and you were working with a team of steward. There were numbers of points of failure where there should have been people asking these questions.

Yes, I piled on some reflections of my working with the WMF as an involved volunteer, and the changing dynamics. If some of us have reflections of how tools and processes used to be and how they are less successful now, what would you like us to do?

When it is only in phabricator that these matters can be raised and get any real interaction with staff and totally reactively, please don't come and tell us to calm down. Get your colleagues out into the wikis working with us there. If that is not going to happen, then come out and say that, so we can utilise our representatives to the board to put forward our points of view.

In T282624#7083372, @Krd wrote:

The current requirement is that one has to have 2fa enabled at the time when IA rights are applied, but there is neither a policy (is it?) nor a technical reason not to disable 2fa at any time later. Will stewards review or monitor this in any way?
A more simple approach from the bureaucratic point of view would be to technically check the 2fa status by the software at the time the group rights are to be used, so that IA (or say CU) features can only be used when 2fa is enabled at that time. This of course would require a software change, but it appears to be a much more reasonable and flexible way to me.

Indeed, if we implement this feature and leave the assignment/revocation of right to local 'crats, would that not solve the all issues discussed above? 'crats would not need to check 2FA status, a user who gets the access and then turns off 2FA will not be able to use this feature and therefore pose risk, and communities would not have to do much differently. We just have to notify the communities that IAs who don't have 2FA will need to enable it. I need 2FA (and the specific implementation of it used on WMF) has some haters, but I think this is a low-cost solution that can be more easily justified than a complete overhaul of the process.

I am also thinking of this approach (to further reduce concerns about 2FA status by using 2LA, see below ):

Is it possible to mark the changes made by an IA with some "Requires review" flag so that all other users keep seeing/using/loading the latest approved version before that change. When someone with adequate permission approves the change, it will become active and visible worldwide. Hence we achieve a two-layer approval (2LA)

In T282624#7101559, @Alfa80 wrote:

I am also thinking of this approach (to further reduce concerns about 2FA status by using 2LA, see below ):

Is it possible to mark the changes made by an IA with some "Requires review" flag so that all other users keep seeing/using/loading the latest approved version before that change. When someone with adequate permission approves the change, it will become active and visible worldwide. Hence we achieve a two-layer approval (2LA)

That would be more trouble than necessary (and would be a pain if by "adequate permission" you mean stewards, and even if it's IA it would be harder in smaller wikis), and I don't think it would be needed.

Note that there is a simple way to make every one happy, who wants to become interfaceadmin make a request in their local community (e.g. bureaucrat noticeboard, or where they did it in the past) and if the bureaucrats are agreed with the request then this request is addressed to the Stewarts who can perform the technical procedure. Conversely if bureaucrats, for local reasons or local policies, thinks the right should be removed to someone, they address the removel request to Stewarts who can again perform the technical procedure. In that way Bureaucrats (and therefore the local communities) still keep a part of that power, and the security aspect is managed by the Stewarts. Someone who need interfaceadmin right will need the agreement of both, the Bureaucrat and the Stewarts.

In T282624#7163881, @ChristianFerrer wrote:

Note that there is a simple way to make every one happy, who wants to become interfaceadmin make a request in their local community (e.g. bureaucrat noticeboard, or where they did it in the past) and if the bureaucrats are agreed with the request then this request is addressed to the Stewarts who can perform the technical procedure. Conversely if bureaucrats, for local reasons or local policies, thinks the right should be removed to someone, they address the removel request to Stewarts who can again perform the technical procedure. In that way Bureaucrats (and therefore the local communities) still keep a part of that power, and the security aspect is managed by the Stewarts. Someone who need interfaceadmin right will need the agreement of both, the Bureaucrat and the Stewarts.

There is no benefit to adding this extra step. These are decisions and actions that can, and should, be made locally. No rationale has been given in any part of the discussion as to why there is any value at all in including an unrelated group in the granting of this permission. Local interface administrator is not similar in any way to CU or OS because it does not have global implications or access to nonpublic personal information. The core problem is the shoddy 2FA process which is unsupported by the WMF, and this does nothing to solve it.

Change 689321 abandoned by Zabe:

[operations/mediawiki-config@master] Limit IA granting/revoking to stewards only

Reason:

https://gerrit.wikimedia.org/r/689321