In T102254#1360842, @Glaisher wrote:

From https://gerrit.wikimedia.org/r/#/c/154432/

loginwiki has $wgAllowUserJs and $wgAllowUserCss set to false, so the extension wouldn't do anything anyways, so there's no point in enabling it there.

I understand it is a special wiki and the vast majority of users just need to go there to set cookies on login. Maybe those with global 'edit' or 'editusercssjs' could be allowed to have some scripts there just for work? @csteipp

@MarcoAurelio, can you describe what stewards are doing on loginwiki? The wiki has a very specific purpose, and probably shouldn't be used for managing users. But if that's what it's being used for, then there's probably a gap somewhere else.

It's used as a "global CU wiki" by stewards. 1 2

I don't think it was actually intended for that? Perhaps we should disable that extension there too.

You can ask @Jalexander but I can tell you that LCA approves such use.

In T102254#1363083, @MarcoAurelio wrote:

You can ask @Jalexander but I can tell you that LCA approves such use.

Yeah, unfortunately regardless of what that now-nonexistent department may have (or may not have) said, that doesn't mean it's necessarily supported/intended by the developers or sysadmins. :)

In T102254#1363085, @Krenair wrote:

Yeah, unfortunately regardless of what that now-nonexistent department may have (or may not have) said, that doesn't mean it's necessarily supported by the developers or sysadmins. :)

Disabling checkuser there would be a significant set back for the stewards and the work against global spam and vandalism. I would fight any action to do so without a replacement already in stone (said replacement would essentially have to be global checkuser from meta). This is not a new thing, checkuser has been actively used and important since soon after loginWiki was created and has been discussed many times both on and off phabricator.

@csteipp asked me about the possibility of a couple trusted gadgets being allowed on. @MarcoAurelio I know that's not perfect but allowing full global scripts is concerning, do you think that could address most of the concerns however?

Last time I checked it was WMF who hired and paid their staff, not vice
versa :-) Does it really matter that LCA is now called just CA? Perhaps is
we were provided better tools to counter vandalism and spam we would not be
in need of using this workarounds to get the job done.

In T102254#1363114, @Krenair wrote:

In T102254#1363098, @MarcoAurelio wrote:

Last time I checked it was WMF who hired and paid their staff, not vice
versa :-) Does it really matter that LCA is now called just CA? Perhaps is
we were provided better tools to counter vandalism and spam we would not be
in need of using this workarounds to get the job done.

You've missed the point entirely. And this is still invalid, you need a separate task because this discussion does not need to be private, only the creator's email address.

I'm trying to get the email address removed, but I see no reason to create a brand new ticket at this point. The security level may be inappropriate (would you feel better if it was marked as an "other confidential issue" instead of security?) but the request is completely valid.

In T102254#1363118, @Jalexander wrote:

In T102254#1363114, @Krenair wrote:

In T102254#1363098, @MarcoAurelio wrote:

Last time I checked it was WMF who hired and paid their staff, not vice
versa :-) Does it really matter that LCA is now called just CA? Perhaps is
we were provided better tools to counter vandalism and spam we would not be
in need of using this workarounds to get the job done.

You've missed the point entirely. And this is still invalid, you need a separate task because this discussion does not need to be private, only the creator's email address.

I'm trying to get the email address removed, but I see no reason to create a brand new ticket at this point. The security level may be inappropriate (would you feel better if it was marked as an "other confidential issue" instead of security?) but the request is completely valid.

The reason that this is private is that the requester did not mean to share their email address. The discussion itself should not be private, so the ticket is invalid. Opening up to WMF-NDA would not fix this issue.

The request itself seems valid, so I encourage you to create a new ticket to work out whether it is able to be resolved, or (possibly) declined.

Maybe I'm just blind, but where is this email? I don't see a public email address anywhere. @Jalexander, did you succeed in removing it?

The issue is that "From Email" field at the top of the object info, below Author and above Subscribers. There's some email address to which you can send in new tasks for creation in Phabricator... We should probably clarify or remove it from docs etc. if it's going to be publicly displaying people's addresses without them being aware/being able to remove the address.

(In the mean time, Mukunda restricted visibility of email addresses in tasks. We're discussing how to move forward.)

In T102254#1364258, @Aklapper wrote:

(In the mean time, Mukunda restricted visibility of email addresses in tasks. We're discussing how to move forward.)

I can still see the email address here, is there some sort of policy for seeing them? Is this discussion in Phabricator somewhere?

In T102254#1364264, @Krenair wrote:

In T102254#1364258, @Aklapper wrote:

(In the mean time, Mukunda restricted visibility of email addresses in tasks. We're discussing how to move forward.)

I can still see the email address here, is there some sort of policy for seeing them? Is this discussion in Phabricator somewhere?

It's restricted to WMF-NDA at the moment (hence why you can see it) currently the discussion is off phabricator. I imagine it will move here at some point.

In T102254#1364296, @Jalexander wrote:

It's restricted to WMF-NDA at the moment (hence why you can see it)

I'd kind of prefer if it was just set to No One. I don't think any of us really need/want to see it, it can only cause confusion (given this is very unclear, you probably shouldn't expect it to actually be treated as private by other WMF-NDA members who aren't reading this)...

In T102254#1364312, @Krenair wrote:

In T102254#1364296, @Jalexander wrote:

It's restricted to WMF-NDA at the moment (hence why you can see it)

I'd kind of prefer if it was just set to No One. I don't think any of us really need/want to see it, it can only cause confusion (given this is very unclear, you probably shouldn't expect it to actually be treated as private by other WMF-NDA members who aren't reading this)...

I agree, it's not my preference either, it was somehow easier to do it too a group for now but we're talking both filing something upstream as well. If hiding it to a group is the right move I wonder if just creating an empty one is the right move for the interim.

Ah thanks. That explains why I can't see it.

So, can this task be made public now?

Okay, public now that the email address issue is taken care of.

From a GlobalCssJs perspective, this is declined. We're not going to add any hacks or workarounds in the extension because user JS/CSS are all disabled on loginwiki. If Chris decides that setting $wgAllowUserJs = $wgAllowUserCss = true is ok, then GlobalCssJs will just work, but I doubt he will.

I would recommend instead that you look into solutions like greasemonkey or scriptish which allow you to add custom JS from your browser. I can assist if you need help setting it up.

From a GlobalCssJs perspective, this is declined. We're not going to add any hacks or workarounds in the extension because user JS/CSS are all disabled on loginwiki. If Chris decides that setting $wgAllowUserJs = $wgAllowUserCss = true is ok, then GlobalCssJs will just work, but I doubt he will.

I would like to avoid that if possible.

The alternatives seem to be,

1. We add Ex:Gadgets, and have a small number of reviewed gadgets that stewards can turn on
2. We implement global CU
3. Add a feature to CU on meta to run CU on another wiki (i.e., loginwiki)
4. Setup something on tools to run the checks via OAuth

For #1, if we can come up with a list, I think we can (within a week or so) do the reviews and get those installed. Global CU has been blocked on sul finalization (too many issues with logging and identities). Now that it's pretty much done, might be time to draw up plans for it. That will be longer than a couple week project however. #3 might be slightly less work than global CU, while keeping loginwiki clean.

#4 I wouldn't be a huge fan of, but if someone has time, there's no technical reason it can't be setup by anyone right now.

I think it would be wise to avoid inserting any sort of non-code-reviewed JavaScript onto loginwiki.

@csteipp Is #4 really OK at all? Isn't there some sort of restriction of storing private data on non-production? (Even if there isn't, I agree it's not a great idea.)

Personally I think that the Gadgets option is the best one in the short term. Talking to Marco it looks like we could come up with a relatively small set of gadgets that would be useful. I think a global checkuser tool would also be useful but is a longer term project.

I have a tiny version of #4 I use within the team (pretty shitty, but not on labs on an internal system) so certainly possible but would prefer against it.

Thank you for taking care of the mistake I made. Sorry for all the fuss.

Regarding the scripts, as I've told James, I was thinking basically on:

• useful links from @hoo, and
• Lupin's popups.

I don't know if those scripts would compromise the security of the wiki. Hoo's useful links would cover pretty much our needs IMHO, by having direct links to CentralAuth and Global IP block; which is what we mostly need. Maybe popups ain't needed after all.

I insist, if this is going to compromise the security of the project, then shut this ticket down and please accept my apologies.

Best regards.

I can say that I only use login.wmf for checkuser checks, and predominantly as a reverse check for checking whether users are going to be affected by a global block on webhost range.

I personally don't need tools on the site, though could understand those working on one screen may find it useful.

In terms of useful scripts
//tools-static.wmflabs.org/meta/scripts/pathoschild.stewardscript.js

What is the problem with allowing user css/js on loginwiki?

In T102254#1371220, @MF-Warburg wrote:

What is the problem with allowing user css/js on loginwiki?

The problem is because it allows unreviewed JavaScript code to be executed in the browsers of users. This is a problem across all wikis, but considering the sensitive nature of the loginwiki, we should be stricter with it than other wikis.

At face value, I don't see that the data is any more precious than any
other wiki. The wiki contains one-touch data for three months for new user
accounts. Compared to big wikis that contain data on all edits for those
wikis. One would think that enWP would beat it easily.

I am not arguing that we should allow all users access to run scripts,
pointless argument for users who don't need it. We are looking to a special
case of allowing stewards to have functionality of tools that they can run
on every other open wmf wiki which they can use around CU tools /
investigations.

On the larger question of should we install Gadgets on that wiki, I need to look more into the current state of the extension. Let me get back to you on that one.

For this particular script, agree, it looks safe. Should that be added to the CU extension, for wikis that also have CentralAuth and the user has appropriate rights?

In T102254#2195633, @csteipp wrote:

(...) Should that be added to the CU extension, for wikis that also have CentralAuth and the user has appropriate rights?

Adding that script to the CU Extension is the best, I think, because:

• No need for gadgets
• No need to look if other gadgets get installed
• Problem with multi lock / CU solved
• and general useful for the extension checkuser.

In T102254#2195821, @Luke081515 wrote:

In T102254#2195633, @csteipp wrote:

(...) Should that be added to the CU extension, for wikis that also have CentralAuth and the user has appropriate rights?

Adding that script to the CU Extension is the best, I think, because:

• No need for gadgets
• No need to look if other gadgets get installed
• Problem with multi lock / CU solved
• and general useful for the extension checkuser.

Yeah, if it's moderately easy to add to checkuser that would be best on multiple fronts. There is also a (different but obviously related) desire to have that functionality in checkuser anyway :) .

In T102254#2195633, @csteipp wrote:

For this particular script, agree, it looks safe. Should that be added to the CU extension, for wikis that also have CentralAuth and the user has appropriate rights?

Problem might be with the "appropriate rights", because since on loginwiki we just hold CU rights and the others being imported from the steward's global group. Do you think that'll work? If so, can we arrange to have this installed as is, and look later on installing Ex:Gadgets there if at all necessary?

Problem might be with the "appropriate rights", because since on loginwiki we just hold CU rights and the others being imported from the steward's global group. Do you think that'll work? If so, can we arrange to have this installed as is, and look later on installing Ex:Gadgets there if at all necessary?

Yeah, it's a little messy. Let me see if I can figure out a way to do that nicely..

@csteipp What about adding the script at loginwiki:MediaWiki:Group-checkuser.js? Stewards have local CU rights there, and scripts used on that page will just load for users in the checkuser group. Just an idea to have this working for now instead of having to load this on rECHU extension-CheckUser which might be harder (although it's what's desired in the long run).

In T102254#2203252, @MarcoAurelio wrote:

@csteipp What about adding the script at loginwiki:MediaWiki:Group-checkuser.js? Stewards have local CU rights there, and scripts used on that page will just load for users in the checkuser group. Just an idea to have this working for now instead of having to load this on rECHU extension-CheckUser which might be harder (although it's what's desired in the long run).

$wgUseSiteJs is also set to false on loginwiki so it probably won't work (haven't checked, just guessing). Instead of checking for the centralauth-lock right (which is not assigned to the stewards global group) to load the JS, maybe we could check whether the user is in the global steward group? Not particularly elegant but it works and would make things simple. Another option to workaround it is to assign the right to the global group to make the code a little better but I guess people won't like it.

In T102254#2203699, @Glaisher wrote:

$wgUseSiteJs is also set to false on loginwiki so it probably won't work (haven't checked, just guessing).

I checked includes/resourceloader/ResourceLoaderUserGroupsModule.php - you're right, it won't work.

What about setting wgUseSiteJs to true again? It's not like anyone who is not a steward could insert code to it.

I probably could as a global interface editor

In T102254#2205003, @Krenair wrote:

I probably could as a global interface editor

Yeah, you can. But we can solve this: For all groups which got the "edit" permission change the wikiset from "None, applies to all wikis." to "All existing wikis". That would solve the problem too I think.

I have submitted https://gerrit.wikimedia.org/r/#/c/283840/

It has also been switched on Wikimedia's CentralAuth wikis. (rOMWCc340b3c237014c3f0) The CheckUser change hasn't yet been deployed on the cluster but it will reach loginwiki tomorrow (if there are no further issues).