Sam, could you take a look at this one?

I'm presuming that the wiki falls under "private"...

'private' => array( 'Main Page', 'Special:Userlogin', 'Special:Userlogout', '-', 'MediaWiki:Monobook.css', 'MediaWiki:Monobook.js' ),

Some of the strange behavior being exhibited here is due to "Main Page" being whitelisted, but on this particular wiki, that page is a redirect (to "Main page").

CC'ing Phillippe as this is happening on arbcomwiki

Thanks, Reedy. Can we un-whitelist the Main page? Understanding that I'm a technical moron, and may not know the full implications of that....

We can remove the main page from the whitelist on wikis that want that. Some private wiki main pages actually contain useful information for the public, so I wouldn't want to just do it on all of them.

When I look at this:
http://arbcom.en.wikipedia.org/w/index.php?title=Main_Page&action=history

I see "(username removed)‎" and "(edit summary removed)". Is that because someone took some manual action in this case?

I'm going to assume that since this at least has a workaround, this is normal priority. It'd be helpful to have an idea of what the "right" solution is, since it's not obvious to me.

(In reply to comment #7)

I see "(username removed)‎" and "(edit summary removed)". Is that because
someone took some manual action in this case?

Yes.

I'm going to assume that since this at least has a workaround, this is normal
priority. It'd be helpful to have an idea of what the "right" solution is,
since it's not obvious to me.

The simple (conceptually, if not in implementation!) solution would be to make $wgWhitelistRead only whitelist reading (and only the current version of a page).

I think the weirdness I originally noted with "/w/index.php?title=" vs. "/wiki/" had to do with whether the content (of the redirect target?) was displayed. I assume http://arbcom.en.wikipedia.org/w/index.php?title=Main_Page&diff=next&oldid=1797 was a work-around for that. (There must also be some separate caching going on: the sidebar still looked different for one than the other until I purged the cache for the page.)

(In reply to comment #8)

The simple (conceptually, if not in implementation!) solution would be to make
$wgWhitelistRead only whitelist reading (and only the current version of a
page).

I don't know whether that would be acceptable for other private wikis. There may be cases where it's desirable to have version information available for public pages, and presumably it's fairly rare for private wiki users to have secret usernames.

Hi Sam / Tim,

Trying to understand what (if anything) needs to happen for this bug. It sounds like Tim doesn't think Emufarmer's suggesting that $wgWhitelistRead only allow reading is desirable, and I would agree. I sounds like the issue that spawned the discussion should have been solved by strong passwords and blocking ip's that attempt to brute force. So sites that really want to keep their usernames secret should be pretty rare.

But is this something that we would want to implement as an extension, for sites that want it?

(In reply to comment #10)

I sounds like the issue that spawned
the discussion should have been solved by strong passwords and blocking ip's
that attempt to brute force.

We require a captcha for IPs that attempt brute force password guessing. It seems to be effective, and avoids the collateral damage that can happen when shared IPs are blocked.

(In reply to comment #11)

We require a captcha for IPs that attempt brute force password guessing. It
seems to be effective, and avoids the collateral damage that can happen when
shared IPs are blocked.

Very cool. I was hoping something like that existed, but hadn't come across it yet.

(In reply to comment #8)

The simple (conceptually, if not in implementation!) solution would be to make
$wgWhitelistRead only whitelist reading (and only the current version of a
page).

So in response to this recommendation specifically, it sounds like an enhancement that would be nice to have for sites that want some extra security through obscurity. Should we classify this as an enhancement request, and add it to the backlog?

(In reply to comment #12)

So in response to this recommendation specifically, it sounds like an
enhancement that would be nice to have for sites that want some extra security
through obscurity. Should we classify this as an enhancement request, and add
it to the backlog?

Yes.

If/when a distinction is made for actions, I assume all non-view actions will become restricted. Just for the record, the current visibility is not limited to action=history, it applies to others as well, such as action=info, and edit notices on action=edit.

• https://office.wikimedia.org/w/index.php?title=Main_Page&action=history,
• https://office.wikimedia.org/w/index.php?title=Main_Page&action=info,
• https://office.wikimedia.org/w/index.php?title=Main_Page&action=edit.

Change 747573 had a related patch set uploaded (by Reedy; author: Legoktm):

[mediawiki/core@REL1_35] SECURITY: Require 'read' right for most actions

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

Change 747580 had a related patch set uploaded (by Reedy; author: Legoktm):

[mediawiki/core@REL1_36] SECURITY: Require 'read' right for most actions

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

Change 747587 had a related patch set uploaded (by Reedy; author: Legoktm):

[mediawiki/core@REL1_37] SECURITY: Require 'read' right for most actions

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

Change 747598 had a related patch set uploaded (by Reedy; author: Legoktm):

[mediawiki/core@master] SECURITY: Require 'read' right for most actions

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

Change 747573 merged by jenkins-bot:

[mediawiki/core@REL1_35] SECURITY: Require 'read' right for most actions

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

Change 747587 merged by jenkins-bot:

[mediawiki/core@REL1_37] SECURITY: Require 'read' right for most actions

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

Change 747580 merged by jenkins-bot:

[mediawiki/core@REL1_36] SECURITY: Require 'read' right for most actions

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

Change 747598 merged by jenkins-bot:

[mediawiki/core@master] SECURITY: Require 'read' right for most actions

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

Yeah, you're right. I've been brainstorming on splitting out diffs into a separate action (action=diff), which would then require the 'read' right, mostly as a way of reducing the attack surface and complexity of action=view. But then you could still brute force oldids to get history, so I'm not really sure this is a solvable problem, or at least I'm not sure we care enough to fully solve it.