Why is this created as a restricted task? Is there anything private?

In T269509#6671463, @Urbanecm wrote:

Why is this created as a restricted task? Is there anything private?

I was told that javascript was not allowed due to security concerns

I don't think we need to be that secretive Danny. Security tasks are usually used to prevent current vulns from being abused. In this case, even if loginwiki global user JS/CSS introduces a vuln, it can't be abused as of now. I personally vote for publishing, but let's wait for @sbassett or @Reedy to comment on that.

In T269509#6671465, @DannyS712 wrote:

In T269509#6671463, @Urbanecm wrote:

Why is this created as a restricted task? Is there anything private?

I was told that javascript was not allowed due to security concerns

It's widely disabled for that reason, yes. But at the same time, loginwiki isn't a wiki most people will visit/use/whatever, so for >99% of people, enabling JS there has no benefit.

If we re-enable it, it will obviously be public, both in config, and in the JS pages being created.

I don't see any reason this task needs to stay private. It's not disclosing a security issue.

I imagine if we want to do this, we want to have it for a limited local user group (where users already have probably global elevated rights, so probably have 2FA enabled) with people added to it, and conditionally allow them in wmf-config to have User JS enabled. I don't think that should be an issue, but might be worth double checking with Perf

Probably needs some wording around it, what is allowed in this case (ie don't enable all your usual user JS). Maybe worthy of a mini risk assessment type thing

In T269509#6671479, @Reedy wrote:

I imagine if we want to do this, we want to have it for a limited local user group (where users already have probably global elevated rights, so probably have 2FA enabled) with people added to it, and conditionally allow them in wmf-config to have User JS enabled. I don't think that should be an issue, but might be worth double checking with Perf

Probably needs some wording around it, what is allowed in this case (ie don't enable all your usual user JS). Maybe worthy of a mini risk assessment type thing

I was thinking, since most people can't edit on loginwiki, something like

• enable gadgets
• add a gadget, default off, that imports the user's loginwiki.js subpage from meta
• allow users to define, eg, https://meta.wikimedia.org/wiki/User:DannyS712/loginwiki.js and enable the gadget to allow importing

That way you wouldn't need to deal with user group management, etc., at the expense of not being able to easily limit who uses the gadget (though you can require rights for gadgets, I'm not sure if that works for rights from global user groups...)

In T269509#6671479, @Reedy wrote:

In T269509#6671465, @DannyS712 wrote:

In T269509#6671463, @Urbanecm wrote:

Why is this created as a restricted task? Is there anything private?

I was told that javascript was not allowed due to security concerns

[...]
If we re-enable it, it will obviously be public, both in config, and in the JS pages being created.

I don't see any reason this task needs to stay private. It's not disclosing a security issue.

Published then.

[...]

@DannyS712 IIRC, you use a script that somehow works with Special:Log/newusers at loginwiki, to fight with spambots, etc. Considering that all new usernames also get created at meta and mediawikiwiki, perhaps you can use one of those wikis instead, and thus remove the need for scripts at loginwiki?

On the other hand, some stewards use scripts to easily copy CU results, so perhaps allowing gadgets would be beneficial?

In T269509#6671802, @Urbanecm wrote:

all new usernames also get created at meta and mediawikiwiki

Minor correction: they are only created on meta and loginwiki, not on mediawiki.org. See $wgCentralAuthAutoCreateWikis

T102254 is definitely an interesting related history. I think it's likely a good idea to keep global css/js and userjs disabled on loginwiki, though I agree with @Reedy's conclusion above that it's reasonable to consider allowing userjs for the stewards or maybe a handful of trusted technical contributors. I'm not entirely sure if there's precedent for anything like that or if a new right/group is warranted. Enabling Gadgets seems like a potentially larger can of worms (and not offering much additional sanity in this specific case) and I'm not sure how any of this works with nobody currently having edit rights on loginwiki. @DannyS712 - are there any regular users of loginwiki besides yourself and maybe @MarcoAurelio who would be very interested in having this functionality enabled in some way?

@sbassett Note the stewards do have the ability to edit loginwiki, as well as edit site CSS/JS through our global group. We can assign the edit rights to sysop group and interface-admin group.

However, after some thoughts on this one, there's only one legitimate usecase I can remember. Loginwiki CU is used to CU new accounts (semi)globally. Ladsgroup wrote a script that allows the results to be copied elsewhere, which would be useful for cooperation among CUs. Other CU-related scripts could be of use as well at loginwiki.

That being said, people who're not loginwiki CUs (by definition, only stewards and authorized staff members can have this permission) probably won't really need to do stuff directly at loginwiki.

So, I feel it should be opened up a little bit, perhaps by letting the stewards to veto scripts injected to loginwiki (ie. enabling gadgets)?

In T269509#6680683, @Urbanecm wrote:

@sbassett Note the stewards do have the ability to edit loginwiki, as well as edit site CSS/JS through our global group. We can assign the edit rights to sysop group and interface-admin group.

Ok, but there currently aren't any sysops or int-admins for loginwiki, right? Aside from AF? I'm not even sure how that approval process would work or if we even want to venture down that road :)

That being said, people who're not loginwiki CUs (by definition, only stewards and authorized staff members can have this permission) probably won't really need to do stuff directly at loginwiki.

@DannyS712's use case seems legitimate to me and doesn't involve CU. But I agree it's more a convenience issue than anything else, so it ends up being a judgment call.

So, I feel it should be opened up a little bit, perhaps by letting the stewards to veto scripts injected to loginwiki (ie. enabling gadgets)?

That would be an advantage of going that route, sure, but it de facto introduces a new workflow to an already-overworked group of users, which I think should be avoided, if possible. With plain old userJS, that administration wouldn't occur, but we'd obviously want to limit a new right (or whatever guarded against this) to as few people as possible so as to allow for potential audits, quick revocations, etc.

In T269509#6680731, @sbassett wrote:

In T269509#6680683, @Urbanecm wrote:

@sbassett Note the stewards do have the ability to edit loginwiki, as well as edit site CSS/JS through our global group. We can assign the edit rights to sysop group and interface-admin group.

Ok, but there currently aren't any sysops or int-admins for loginwiki, right? Aside from AF? I'm not even sure how that approval process would work or if we even want to venture down that road :)

No (excluding stewards), but stewards could then grant such right to Danny, who would then be able to use it for his use case (or anyone else with similar issue to solve).

That being said, people who're not loginwiki CUs (by definition, only stewards and authorized staff members can have this permission) probably won't really need to do stuff directly at loginwiki.

@DannyS712's use case seems legitimate to me and doesn't involve CU. But I agree it's more a convenience issue than anything else, so it ends up being a judgment call.

Well, it's legitimate, but it can be solved without loginwiki. All accounts should be autocreated at meta and loginwiki (cf mediawiki-config. Or, am I missing someting?

So, I feel it should be opened up a little bit, perhaps by letting the stewards to veto scripts injected to loginwiki (ie. enabling gadgets)?

That would be an advantage of going that route, sure, but it de facto introduces a new workflow to an already-overworked group of users, which I think should be avoided, if possible. With plain old userJS, that administration wouldn't occur, but we'd obviously want to limit a new right (or whatever guarded against this) to as few people as possible so as to allow for potential audits, quick revocations, etc.

Well, it'd be the stewards anyway who would de-facto maintain it, either by granting the new "enable user-js" group, or by approving a script, except the latter is probably more secure (personally, I'm not aware of any security issues that could arise, but obviously, you're the expert on this). Anyway, userJS works for me too, I'm not opposing it :).

In T269509#6682695, @sbassett wrote:

So after discussing this a bit more, I'm going to decline this for now. I think the current alternatives of running any scripts locally via a developer console or whatever and/or just using metawiki are acceptable for now, given what appear to be extremely limited use cases. If demand increases for using loginwiki data, we can likely revisit some of the solutions suggested above.

I use loginwiki because for some reason not all accounts are created on meta (not sure why, doesn't appear to be abuse filter)

MariaDB [centralauth_p]> SELECT login.lu_name AS 'loginwiki name', meta.lu_name AS 'meta name', gu.gu_id, gu.gu_name, gu.gu_home_db, gu.gu_locked, gu.gu_registration FROM localuser login LEFT JOIN localuser meta ON (login.lu_name = meta.lu_name AND meta.lu_wiki = 'metawiki') JOIN globaluser gu ON gu.gu_name = login.lu_name WHERE login.lu_wiki = 'loginwiki' AND meta.lu_name IS NULL ORDER BY gu.gu_id DESC LIMIT 5;
+----------------+-----------+----------+------------+------------+-----------+-----------------+
| loginwiki name | meta name | gu_id    | gu_name    | gu_home_db | gu_locked | gu_registration |
+----------------+-----------+----------+------------+------------+-----------+-----------------+
| AkrepFa        | NULL      | 64843331 | AkrepFa    | trwiki     |         0 | 20201210175136  |
| Maxoma1405     | NULL      | 64843313 | Maxoma1405 | NULL       |         0 | 20201210174941  |
| Phainh         | NULL      | 64842788 | Phainh     | NULL       |         0 | 20201210165414  |
| Mianmianyu     | NULL      | 64842180 | Mianmianyu | NULL       |         0 | 20201210155818  |
| Kaunolu        | NULL      | 64841854 | Kaunolu    | trwiki     |         0 | 20201210152919  |
+----------------+-----------+----------+------------+------------+-----------+-----------------+

but the reverse does not appear as common (at least for new accounts, there are plenty of old accounts that exist on metawiki but not loginwiki, but I'm concerned with monitoring new account creations)

MariaDB [centralauth_p]> SELECT login.lu_name AS 'loginwiki name', meta.lu_name AS 'meta name', gu.gu_id, gu.gu_name, gu.gu_home_db, gu.gu_locked, gu.gu_registration FROM localuser meta LEFT JOIN localuser login ON (login.lu_name = meta.lu_name AND login.lu_wiki = 'loginwiki') JOIN globaluser gu ON gu.gu_name = meta.lu_name WHERE meta.lu_wiki = 'metawiki' AND login.lu_name IS NULL ORDER BY gu.gu_id DESC LIMIT 5;
+----------------+--------------------+----------+--------------------+------------+-----------+-----------------+
| loginwiki name | meta name          | gu_id    | gu_name            | gu_home_db | gu_locked | gu_registration |
+----------------+--------------------+----------+--------------------+------------+-----------+-----------------+
| NULL           | Francesca Banderas | 64843797 | Francesca Banderas | NULL       |         0 | 20201210183753  |
| NULL           | FilmEditors        | 64843453 | FilmEditors        | NULL       |         0 | 20201210180446  |
| NULL           | FilomenaIllingwo   | 64835118 | FilomenaIllingwo   | NULL       |         0 | 20201210002257  |
| NULL           | Daria Ciani        | 64665152 | Daria Ciani        | NULL       |         0 | 20201124135532  |
| NULL           | Dakhil.outsider    | 64596700 | Dakhil.outsider    | arwiki     |         0 | 20201117230313  |
+----------------+--------------------+----------+--------------------+------------+-----------+-----------------+

In other words, there are some accounts missing from both loginwiki and metawiki, but metawiki has more missing and thus loginwiki has a more complete, and thus more useful, log of new accounts

^ previously this was just something I suspected, but replicas and toolforge appear to confirm it

There has to be a reason - possibly local meta blocks. CentralAuth is configured to autocreate the accs:

[urbanecm@mwmaint1002 ~]$ mwscript shell.php enwiki
Psy Shell v0.10.4 (PHP 7.2.31-1+0~20200514.41+debian9~1.gbpe2a56b+wmf1+icu63 — cli) by Justin Hileman
>>> $wgCentralAuthAutoCreateWikis
=> [
     "loginwiki",
     "metawiki",
   ]
>>> ^D
Exit:  Ctrl+D
[urbanecm@mwmaint1002 ~]$

In T269509#6683232, @Urbanecm wrote:

There has to be a reason - possibly local meta blocks. CentralAuth is configured to autocreate the accs:

[urbanecm@mwmaint1002 ~]$ mwscript shell.php enwiki
Psy Shell v0.10.4 (PHP 7.2.31-1+0~20200514.41+debian9~1.gbpe2a56b+wmf1+icu63 — cli) by Justin Hileman
>>> $wgCentralAuthAutoCreateWikis
=> [
     "loginwiki",
     "metawiki",
   ]
>>> ^D
Exit:  Ctrl+D
[urbanecm@mwmaint1002 ~]$

So ip blocks on meta prevent the creation of local meta accounts, but since there aren't those blocks on loginwiki accounts are indeed autocreated there?