Wikivoyage talk:Interface administrators
Add topicInactivity policy
[edit]I was compiling a general permissions overview list for this wiki and I'm surprised to learn we have no inactivity policy for interface admins. I find this to be pretty insane given that this is one of the most high-risk permissions (even with 2FA mandated).
Given the high-risk nature, the inactivity policy should be far stricter than both the inactivity policy for both sysop and bureaucrat. This we can safely do without hassle since the English Wikivoyage does not require a renomination (for interface admins, only a confirmation that 2FA is enabled), which essentially nullifies the argument for having a more lax inactivity policy.
I propose the following, but I'd love to hear other suggestions:
- must make at least 1 edit or logged action in the last 3 months.
- must use their interface admin tools at least once in the past 6 months.
--SHB2000 (t | c | m) 00:51, 1 August 2024 (UTC)
- Are there regular needs for such changes in the interface? I assume what matters is that they are available when need arises. For that, any activity at WMF projects would suffice. For security, I see no reason to think that a less active interface administrator is a bigger risk than a more active one, as long as they follow their account's activities. On the other hand, having more people with those rights increases the risk, so we need people who are actually available, not to need to have many. I think being able to replace a retiring or pausing interface administrator with little fuzz is important – when they tell they won't be active and we can find somebody else, not a year after a de facto retirement. –LPfi (talk) 05:49, 1 August 2024 (UTC)
- Would you suggest replacing "edit" with "global edit" then? --SHB2000 (t | c | m) 23:19, 1 August 2024 (UTC)
- I believe the approach used at the English Wikisource is that nobody keeps IA. You enable it when you need it for a specific project, and then you disable it when you are finished what that project. Especially if this is rarely needed, it might be a good idea to adopt their model. WhatamIdoing (talk) 16:56, 20 August 2024 (UTC)
- Could work, but the issue on our wiki is that Andyrom75 and Jdlrobson use their permissions quite frequently so it would be quite a pain for both of them to obtain it every single time they use IA. --SHB2000 (t | c | m) 23:27, 20 August 2024 (UTC)
- So make them buros and let them self-assign IA whenever they need the privs. WhatamIdoing (talk) 00:02, 21 August 2024 (UTC)
- I don't think that's particularly intuitive over them just keeping the perms for an extended period of time. --SHB2000 (t | c | m) 00:09, 21 August 2024 (UTC)
- It's not a question of what's intuitive. It's a question of what's better security. Running with all your privs lit up at all times is a bad idea. If you're familiar with Unix systems, having IA enabled constantly is like typing sudo in front of every command. It often won't matter, but it'd be better if you didn't. WhatamIdoing (talk) 03:40, 21 August 2024 (UTC)
- My 2 cents on this topic.
- being a buro will solve the issue to obtain quickly the IA role when needed, because sometimes it's urgent. However, a real buro should have different skills and knowledge of a specific wiki.
- if a wiki account is hacked, I don't see a big difference in terms of risk between an IA account or a buro account that can auto-assign the IA role
- That said, whatever will be the choice of en:voy community, I'll be more than glad to follow it. Andyrom75 (talk) 15:16, 21 August 2024 (UTC)
- A bureaucrat needs to have extensive knowledge of Wikivoyage policies and guidelines and making IAs bureaucrats is bad because 2 of them aren't even admins. And as Andyrom75 mentioned, it makes no difference if the account has been compromised with IA or 'crat perms that can assign IA whenever needed. There is a good reason why this unwieldy approach hasn't been adopted by most larger wikis. -SHB2000 (t | c | m) 06:56, 24 August 2024 (UTC)
- Buros need to have enough sense to not meddle with things that they don't understand. Just because someone has a set of buttons doesn't mean they have to use all of them.
- Andyrom does not say that there is "no difference". There are two differences, only one of which involves a compromised account:
- If you keep IA off by default, you can't accidentally edit the 'wrong' page. It's very easy to have a hundred tabs open and accidentally paste your text into the live page instead of the sandbox page. That can't happen when you have your privs turned off.
- If your account is compromised through a pre-written malicious script, and your privs are turned off, then the script may not be able to use your account. A knowledgeable human might turn on the privs and then hack the site, but a script is going to get an error message about not having the privs and exit without doing any damage.
- Additionally, if you don't have it set 24x365, then your account is less likely to be targeted by hackers in the first place, because Special:ListUsers/interface-admin will be empty and they'll go look for a different wiki. WhatamIdoing (talk) 20:07, 24 August 2024 (UTC)
- Do you have any underlying evidence that clearly supports why your proposal works or is this just a case of "trust me bro"? You still haven't answered why this approach isn't used by many of the larger wikis which have far more expertise on meta matters like this than a medium-sized wiki like us. --SHB2000 (t | c | m) 10:21, 1 September 2024 (UTC)
- I don't know why other wikis haven't thought more about how to apply the w:en:Principle of least privilege in computer security to this aspect of editing. The principle says that if you don't need IA enabled right now, you shouldn't have IA enabled right now. WhatamIdoing (talk) 18:02, 1 September 2024 (UTC)
- Yeah, nah, so you don't have any underlying evidence other than a mostly-uncited Wikipedia article. I'm going to formally oppose your proposal. --SHB2000 (t | c | m) 21:46, 1 September 2024 (UTC)
- I'm not even sure what "evidence" would mean in this context. Do you need someone to screw up a wiki first, so you can see the problems, before you believe that it's possible to cause problems? Or do you need to live through a round of account hacking before you believe that happens? Jimmy Wales account was among the accounts hacked in 2016. That round was targeting WMF folks and accounts with advanced privileges. IA didn't exist then, but I would expect it to be high on the list of targets in the future. WhatamIdoing (talk) 06:47, 2 September 2024 (UTC)
- Evidence as in why the largest wikis who have far more knowledge and expertise have chosen what they have over a single user with arguments on the basis of "trust me". --SHB2000 (t | c | m) 09:38, 2 September 2024 (UTC)
- The last time I checked, Wikisource is not "a single user with arguments on the basis of 'trust me'."
- The Wikisource IAs have a particularly high level of technical skill, including someone who was a m:Steward for four years and a long-time WMF developer. The largest wikis have more people with technical skills, but a lower average skill level. WhatamIdoing (talk) 19:30, 2 September 2024 (UTC)
- "The Wikisource IAs have a particularly high level of technical skill, including someone who was a m:Steward for four years and a long-time WMF developer." – as do all the larger wikis, who have far more skill and expertise. I still oppose your proposal. --SHB2000 (t | c | m) 23:41, 3 September 2024 (UTC)
- Because the Wikisource IAs are a small group, they don't have a bunch of low-skill people that can outvote them.
- You're welcome to oppose it. That doesn't mean it's a bad idea. It's literally "Security 101" – as in, a concept taught to first-year comp sci students. WhatamIdoing (talk) 02:03, 4 September 2024 (UTC)
- Probably because most wikis are sane enough not to discount the opinions of what you call "low-skill people" (which is subjective anyway) unlike the English Wikisource and being a small/medium-sized wiki, which could probably get away with it. --SHB2000 (t | c | m) 07:07, 4 September 2024 (UTC)
- "The Wikisource IAs have a particularly high level of technical skill, including someone who was a m:Steward for four years and a long-time WMF developer." – as do all the larger wikis, who have far more skill and expertise. I still oppose your proposal. --SHB2000 (t | c | m) 23:41, 3 September 2024 (UTC)
- Evidence as in why the largest wikis who have far more knowledge and expertise have chosen what they have over a single user with arguments on the basis of "trust me". --SHB2000 (t | c | m) 09:38, 2 September 2024 (UTC)
- I'm not even sure what "evidence" would mean in this context. Do you need someone to screw up a wiki first, so you can see the problems, before you believe that it's possible to cause problems? Or do you need to live through a round of account hacking before you believe that happens? Jimmy Wales account was among the accounts hacked in 2016. That round was targeting WMF folks and accounts with advanced privileges. IA didn't exist then, but I would expect it to be high on the list of targets in the future. WhatamIdoing (talk) 06:47, 2 September 2024 (UTC)
- Yeah, nah, so you don't have any underlying evidence other than a mostly-uncited Wikipedia article. I'm going to formally oppose your proposal. --SHB2000 (t | c | m) 21:46, 1 September 2024 (UTC)
- I don't know why other wikis haven't thought more about how to apply the w:en:Principle of least privilege in computer security to this aspect of editing. The principle says that if you don't need IA enabled right now, you shouldn't have IA enabled right now. WhatamIdoing (talk) 18:02, 1 September 2024 (UTC)
- Do you have any underlying evidence that clearly supports why your proposal works or is this just a case of "trust me bro"? You still haven't answered why this approach isn't used by many of the larger wikis which have far more expertise on meta matters like this than a medium-sized wiki like us. --SHB2000 (t | c | m) 10:21, 1 September 2024 (UTC)
- My 2 cents on this topic.
- It's not a question of what's intuitive. It's a question of what's better security. Running with all your privs lit up at all times is a bad idea. If you're familiar with Unix systems, having IA enabled constantly is like typing sudo in front of every command. It often won't matter, but it'd be better if you didn't. WhatamIdoing (talk) 03:40, 21 August 2024 (UTC)
- I don't think that's particularly intuitive over them just keeping the perms for an extended period of time. --SHB2000 (t | c | m) 00:09, 21 August 2024 (UTC)
- So make them buros and let them self-assign IA whenever they need the privs. WhatamIdoing (talk) 00:02, 21 August 2024 (UTC)
- Could work, but the issue on our wiki is that Andyrom75 and Jdlrobson use their permissions quite frequently so it would be quite a pain for both of them to obtain it every single time they use IA. --SHB2000 (t | c | m) 23:27, 20 August 2024 (UTC)
Interface administrator inactivity requirements
[edit]Just bumping the discussion at Wikivoyage talk:Interface administrators on inactive interface admins. --SHB2000 (t | c | m) 08:27, 20 August 2024 (UTC)
Any interface admin around?
[edit]Could one of you take care of User:Nothing I Can't/common.js – this is a JS page for a username that doesn't exist (never moved when the user was renamed). Thanks. --SHB2000 (t | c | m) 00:50, 3 November 2024 (UTC)
- Same with User:Alexlur/common.css. --SHB2000 (t | c | m) 00:51, 3 November 2024 (UTC)
- I don't seem to be able to remove those... -- andree 18:37, 3 November 2024 (UTC)
- That's interesting – @Andyrom75:, are you able to delete those? I hope it doesn't require a sysadmin. --SHB2000 (t | c | m) 03:05, 4 November 2024 (UTC)
- I was able to delete it. —Granger (talk · contribs) 04:24, 4 November 2024 (UTC)
- Interesting how I was able to just delete the second one. Must've been some glitch/connection issues on my side earlier. Thanks for deleting the first page. --SHB2000 (t | c | m) 05:01, 4 November 2024 (UTC)
- I was able to delete it. —Granger (talk · contribs) 04:24, 4 November 2024 (UTC)
- That's interesting – @Andyrom75:, are you able to delete those? I hope it doesn't require a sysadmin. --SHB2000 (t | c | m) 03:05, 4 November 2024 (UTC)
- I don't seem to be able to remove those... -- andree 18:37, 3 November 2024 (UTC)