Open main menu
← Discussion pages Wikimedia Forums Archives →
QA icon clr.svg

The Wikimedia Forum is a central place for questions, announcements and other discussions about the Wikimedia Foundation and its projects. (For discussion about the Meta wiki, see Meta:Babel.)
This is not the place to make technical queries regarding the MediaWiki software; please ask such questions at the MediaWiki support desk; technical questions about Wikimedia wikis, however, can be placed on Tech page.

You can reply to a topic by clicking the "[edit]" link beside that section, or you can start a new discussion.
Filing cabinet icon.svg
SpBot archives all sections tagged with {{Section resolved|1=~~~~}} and sections whose most recent comment is older than 30 days.


Contents

BugMeNot shared loginsEdit

Bugmenot have disabled sharing logins for a few Wikipedias. This is good: sharing accounts is not allowed. However, they have not disabled:

  • meta
  • ar
  • ba
  • be
  • cz
  • hi
  • ja
  • no
  • pt
  • simple (simple English)
  • zh

...and those are just the ones I checked. For at least two I found shared accounts listed, and one that I tested was a functioning login. With SUL, these compromised accounts have access to any wikpedia project. Will someone from the Foundation please contact BugMeNot and make certain that sharing login information for all Wikipedias is disabled, and get a record from them of all wikipedia.org accounts which have been listed so that they can be globally locked? Thank you. BlackcurrantTea (talk) 00:14, 7 June 2019 (UTC)

BlackcurrantTea, not sure if this has been addressed, but concerns about account compromise can be dealt with at SRG, where a steward can look at locking the accounts if warranted. TonyBallioni (talk) 18:43, 20 June 2019 (UTC)
TonyBallioni, thanks for the suggestion. Unfortunately, nothing's changed. Whilst I could test each Wikipedia and report the accounts I find, new accounts can still be added, making it a Sisyphean task. Until BugMeNot changes their policy, the problem will remain. I filled in their form to remove simple.wikipedia.org before I posted the above; 18 days later they've not removed it. BlackcurrantTea (talk) 10:49, 25 June 2019 (UTC)
Just FYI - The Security Team and Trust and Safety are aware of this and there is currently a private Phab task (T227720) where we're tracking the issue. We've automated searching bugmenot.com for various wikimedia domains and are in the process of issuing takedown requests and locking any potentially affected accounts. Please feel free to reach out to security@wikimedia.org with any other questions or concerns. SBassett (WMF) (talk) 16:25, 11 July 2019 (UTC)

HiEdit

You said People of all ages can go The the meeting that means even children can go to. You are registered as a US incorporation and the COPPA law must apply for your Foundation. Fungster (talk) 06:23, 20 June 2019 (UTC)

What meeting? Ruslik (talk) 12:18, 5 July 2019 (UTC)

Encyclopedia for ChildrenEdit

Wikipedia is a great place to search for information but adult content makes it unsuitable for children. There are sites that offer this service but are limited in a few languages available. Therefore, the creation of this encyclopedia helps to spread the knowledge to young generations around world.

Omda4wady (talk) 10:31, 9 July 2019 (UTC)

Two factor for OTRS membersEdit

Can oathauth-enable be added to the OTRS members global group to allow them use two factor authentication? The OTRS members global group allows a user get around some of the editfilter checks on some of the wikis and if an OTRS members account is compromised disruptive edits by the imposter may go unnoticed. —The preceding unsigned comment was added by Morgankevinj (talk) 2019-07-10T04:12:48

@Morgankevinj: is this really a problem? I did a quick check of the first 20 OTRS people alphabetically, 18 already had 2fa enrollment access via other groups (such as yourself), 1 opt-ed in via the 'testers' group, and 1 did not have enrollment access. Any that want it can easily opt-in. — xaosflux Talk 14:09, 10 July 2019 (UTC)
This is supposed to happen by end of 2019 anyway. This this discussion and the following developer commitment -
I am an example of an OTRS agent who is not eligible for 2FA. Blue Rasberry (talk) 14:15, 10 July 2019 (UTC)
@Bluerasberry and Morgankevinj:Anyone can request this at SRGP (for connivence, direct link). TonyBallioni (talk) 18:48, 10 July 2019 (UTC)
I added 'oathauth-enable' to the OTRS group. Ruslik (talk) 20:17, 10 July 2019 (UTC)
@TonyBallioni: see also Meta:Requests for comment/Enable 2FA on meta for all users where I proposed at least enabling it here on meta-wiki, to skip the silly rubber stamping by stewards. The current process is literally show up at SRGP, reply 'yep I read it' and you get it. The RfC arguments were that it was too onerous to deal with, but it gets handed out on demand to anyone (e.g. here is a very recent account whose entire WMF global history is asking for 2FA: Special:CentralAuth/AreYouConfused2). — xaosflux Talk 20:21, 10 July 2019 (UTC)
@Xaosflux: thanks for the ping, see my comment there. I personally think 2FA for non-functionaries (and IAdmins) is in most cases overkill, but I agree that the current process for those who want it is silly, and I don't think we should stand in the way of making it easy for people to enable something they want.

For those who are considering enabling it, I hate to say this, but you likely are not a visible enough target, and having a unique password will be sufficient in the overwhelming majority of cases. There are exceptions, and I do think fairly "high-profile" members of local communities could likely benefit from this, even if they aren't sysops. TonyBallioni (talk) 20:35, 10 July 2019 (UTC)

@TonyBallioni: I agree, it is overkill and does have a lot of overhead (support wise) associated with it - but by now we should have had enough "testing" so either stop using the "testers" group for anyone or just open it up. I suggested doing it here, so that people would have to purposefully head over to meta-wiki if they wanted it - and we can put a big banner on the enrollment page as well. — xaosflux Talk 22:08, 10 July 2019 (UTC)
Yes, we're in agreement. If it gets off the ground ping me, and I'll try to help with any implementation write-up that is needed :) TonyBallioni (talk) 22:11, 10 July 2019 (UTC)

Userspace protectionEdit

I feel it would be useful to have a page protection level that permits a user to edit a page in their own userspace such as their userpage, or a userspace page that contains their PGP key or committed identity. Userspace protection would allow only the user and administrators to edit a protected page. The maximum protection level currently available to a non-admin user that allows them to edit their own page currently is semi-protection. Experienced vandals make the requisite number of edits and wait the requisite amount of time to get auto-confirmed before going rogue. MorganKevinJ(talk) 20:10, 15 July 2019 (UTC)

@Morgankevinj: a "hack" to this exists, you can create a page such as User:Morgankevinj/MyPublicKeys.css and do what you want. This works on all projects. The page will be in the "css content model", but if you just want to store some text it should be fine, just wrap it in comment code (e.g. /* Stuff goes here */). Pages in that content model in your user subpages are only editable by you and interface administrators (and some more even highly accessed rarer people). Does that help? — xaosflux Talk 15:24, 16 July 2019 (UTC)