FYI: My current opinion on this is we should drop the wordlist thing. I think most of the time the combining two words results in a string that is not recognizable as a word, and it probably helps computers more than humans.

Just wondering, is there a reason for the doing the new SiteMapper stuff, instead of using core's WikiMap (and related) class? (I haven't looked at WikiMap in a while, so the answer might just be that WikiMap really sucks)

This Google doc (accessible to all WMF staff) has all our project notes to date (again, we just started) and I've added a summary of your comments. I will publish an update on our cross-department program's Meta page about blocking tools.

I think any conversation that starts from a place of "Lets stop all abuse" is not going to go anywhere. There's lots of different types of abuse on the wiki, involving different methods, motives and sophistication. Solutions are not going to be one size fits all and it will probably be a poor solution if it doesn't start from a place of usecases.

That said, probably couldn't hurt to mention cookies as a possibility in that error message.

So looking at the code (I assume we are talking about login here):

In T155087#4876952, @Nemo_bis wrote:

Inaccurate rationale for closure.

In T21322#4875189, @Iniquity wrote:

If it is difficult to change the scheme, then I think it is quite possible to create a DB (something like MediaWiki:Admin-bots) with users which we can to hide.

In my defense, look at the default values in old versions of the official docs: https://web.archive.org/web/20151002085202/https://secure.php.net/manual/en/function.file-get-contents.php

I guess worst case scenario, we could add a post-processing step

I'm not sure which malicious actors we're worried about here - The primary questions seem almost certainly ethical & technical (does the mechanism actually work, what is the false positive rate, what is the false negative rate, etc).

In T177765#4822198, @Tgr wrote:

Reading Infrastructure is about to take over the service, and one thing I'd like to get a clearer picture on (asking here as I'm sure this came up during the security review) is what level of network isolation the service is working at. Let's say an attacker can put malicious content into the wiki page, and Chromium executes that while rendering the page, and that causes it to send a bunch of requests. Will those requests be routed through Varnish etc. as if they came from the internet? What happens with e.g. .wmnet URLs?

I personally have no strong feelings about this, as long as there is a clear policy which is documented in a way that allows people on github to understand what assumptions they can make about members of the wikimedia project.

In T213131#4862801, @Halfak wrote:

@JBennett may have some thoughts on this from security's point of view.

As an addendum:

Just set the mailing list to not allow html email. That's really the only fool proof way to get what you're asking for.

@Sophivorus To give further context, to move this forwards, this really needs a champion with deploy access to push it forward. @greg can help you in determining what other requirements beyond security review are needed in order to get this deployed.

Ok, its Jan 7. Making this public

If you make an existing security task be a child task of a public task, it will only show up when people have rights to view, so it all works out fine.

In T6845#4856993, @Thryduulf wrote:

So the question is why has work not been put aside to fix an issue of recognised high importance that will, 13 years after first being raised, resolve an issue that results in us discriminating against people who are (in many jurisdictions) a legally protected minority?

In T6845#4852632, @Cameron11598 wrote:

Would giving the user the ability to switch to a math based captcha if they are unable to read the regular captcha be a possible solution?

Do you think you should still be a member of the wikimedia "organization" on github? What are you using this membership for?

On a related note, recaptcha isn't just a concern about FOSS, there are also concerns about privacy and security of allowing a third party to run JS on our sites.

On a related note, given WMF has now started to abandon the old and highly restrictive policy of only ever using free and open source software, alternative CAPTCHA services can now be considered.

So one big table holding the data for all the wikis is probably not a good idea as you'd be creating just a big massive table.

I suspect its caused by a7cbc776ba7

In T212667#4845229, @Stashbot wrote:

Mentioned in SAL (#wikimedia-operations) [2018-12-28T15:28:05Z] <bawolff@deploy1001> Synchronized private/PrivateSettings.php: Attempt to adjust captcha settings for T212667 (duration: 00m 46s)

Ah, according to php docs: https://secure.php.net/manual/en/function.dirname.php it sounds like dirname( '/' ); will maybe output \ on windows, so that's probably where its coming from.

Hmm, maybe this is from line 37 of index.php:

$scriptPath is supposed to be the path for a URL. So / would be correct even on windows.

Sorry for being negative, but...

Note, there was some relatively recent changes to the schema for change tags - T185355

In T211550#4825302, @Incnis_Mrsi wrote:

In the context of Unicode discussions “characters” is an ill-advised term because some code points—such as U+FFFE—are explicitly defined as “non-characters” .

Also, what about passwords which are not valid UTF-8 strings? Will something containing \300 or \301 be rejected on this ground?

In T205482#4700947, @Liuxinyu970226 wrote:

Why not just archive it?

So this has now been marked as secret for 22 months. I appreciate that some of the lesser issues still aren't fixed, but security tasks are intended to only be kept secret for a limited amount of time to allow for fixes to be applied. Tasks like these are not supposed to be kept confidential indefinitely.

Sorry, for the confusion of the instructions. The bug is only present for certain log types, such as: newusers, renameuser, block, rights, gblblock, globalauth, massmessage.

The internet also claims grapheme_strlen is a thing - https://secure.php.net/manual/en/function.grapheme-strlen.php but it didn't seem to work when i tested locally...

using mb_strlen instead of strlen would probably get us 60% of the way to something reasonable.

In T150826#4808282, @Billinghurst wrote:

I tell you what I find truly infuriating about this implementation

1. A solution to a problem at enWP became everyone's solution whether they had the problem or not;
2. There is nothing new about the problem, it has been known like "forever", however due to the problem at enWP, everyone got the solution and got it immediately;
3. Because the solution fits for enWP, and their circumstance, it was imposed upon everyone without consideration whether it was the right solution for those wikis, but don't worry about it, we will fix that later.

In T205378#4802463, @Liuxinyu970226 wrote:

@Krenair @Bawolff @jcrespo Wondering if we can enable QUIC support on our server clusters instead? I've heard that the github Googlehosts is providing the QUIC access to Google HK.

Hmm, http://www.123seminarsonly.com/Seminar-Reports/008/47584359-captcha.pdf has some advice about eliminating characters that look alike (e.g. 1 and l)

I kind of think maybe we should just go with random letters. I don't think the combining two words thing helps users very much since usually they are weird enough words its not identifyable as a word. But it does probably help attackers quite a bit.

It was pointed out to me that this might not be the best idea, because if an attacker compromises an account that has temporarily removed 2FA, the attacker can just enroll into 2FA to get back access.

CheckUsers have unlogged access to IP addresses via the AbuseFilter API

So the code (ApiQueryBase::showHiddenUsersAddBlockInfo) was introduced in 27c61fb1, but its probably just showing up now since comment migration was set to read new on group 0 on nov 29 (T166733)

Ok, so its doing the query

SELECT  user_id,user_name,user_real_name,user_email,user_touched,user_token,user_email_authenticated,user_email_token,user_email_token_expires,user_registration,user_editcount,user_actor.actor_id,ipb_deleted,ipb_id,ipb_expiry,ipb_timestamp,ipb_by,ipb_by_text,NULL AS `ipb_by_actor`,comment_ipb_reason.comment_text AS `ipb_reason_text`,comment_ipb_reason.comment_data AS `ipb_reason_data`,comment_ipb_reason.comment_id AS `ipb_reason_cid` 
FROM `user`
LEFT JOIN `actor` `user_actor` ON ((user_actor.actor_user = user_id))
LEFT JOIN `ipblocks` ON ((ipb_user=user_id) AND (ipb_expiry > '20181203070920'))
JOIN `comment` `comment_ipb_reason` ON ((comment_ipb_reason.comment_id = ipb_reason_id)) 
WHERE user_name = 'Quiddity'  ;

It seems like minimal reproducible test case is: https://test.wikipedia.org/w/api.php?format=jsonfm&formatversion=2&action=query&list=users&usprop=blockinfo&ususers=Quiddity

imported https://codein.withgoogle.com/tasks/5193222952321024/

Imported https://codein.withgoogle.com/tasks/6561852751347712/

Disable custom JavaScript. We probably can't get away with disabling all of it, since some workflows involving sensitive functionality make heavy use of user scripts, e.g. steward or checkuser tools, but we should at least limit user-contributed scripts to the least insecure types, such as gadgets; and prevent the loading of user scripts belonging to different users, and scripts from another domain.

I didn't think it was, but after a long (albeit, heated) discussion it seems like that is exactly the threat model of the same-origin policy. At least for credential-less cross-origin requests, but the browser will not send credentials cross-origin, so it is a matter of intranet sites.

In T210791#4788124, @dbarratt wrote:

In T210791#4787819, @Bawolff wrote:

On one hand, I kind of feel like its a browser issue - Should they really allow globally routed internet apps make requests to private IP space intranet app. But that's probably kind of impossible.

That's the purpose of the same-origin policy. Our software is providing an exception to that policy.

Note previous discussion on T62835 - perhaps it was unnecessarily paranoid.

On one hand, I kind of feel like its a browser issue - Should they really allow globally routed internet apps make requests to private IP space intranet app. But that's probably kind of impossible.

The gci task is already accepted - we cant force the student to do more work (we can of course ask nicely)

On the subject of rate limits: i guess it could make sense if they only applied when blocking a user with the ability to block other accounts. I still think the block user who blocked you is a better mitigation

Fwiw: on the subject of unblockself rights - even if all admins have that the attacker could still just immediatly (via an automated script) reblock anyone who unblocks themselves as soon as they do so, before they can block attacker. Sure eventually a defender could write a script to win the race condition, but it would probably take longer to do that then just fetch a steward. So i dont think removing unblockself significantly increases the risk of an attacker blocking all other admins.

In T150826#4778848, @Adotchar wrote:

In T150826#4778796, @Bawolff wrote:

There's discussion on enwiki about also having a rate limit on blocking users. Seems like a reasonable enough idea, but we'd want it high, as we really only want it in cases of truly malicious users.

Please, please, please do not do this globally without a meta RfC or some form of other discussion. (and should require every wiki’s community to be notified, or for it to be handled on a wiki-by-wiki basis)

I am strongly opposed to this, and I’m sure many others are as well who are not watching this ticket.

There's discussion on enwiki about also having a rate limit on blocking users. Seems like a reasonable enough idea, but we'd want it high, as we really only want it in cases of truly malicious users.

In T150826#4776502, @Majora wrote:

Why was this done globally instead of just to enwiki as requested? No other project requested this as far as I'm aware. To remove unblockself from all wikis, especially smaller ones where there are only one or two admins, raises a bunch of problems. It would be better if the devs only did this on the projects that requested it instead of extending the massive paranoia to every single project.

 In T150826#4775305, @Tgr wrote:

[...]

    Allow blocked admins to block the user who blocked them (but not others). That removes first-mover advantage on small wikis - in case of >serious trouble the admins will lock each other out and things will mostly be at a standstill until stewards come and clean things up.

This patch doesn't seem to apply cleanly

patching file includes/api/ApiQueryAbuseLog.php
Hunk #1 FAILED at 56.
Hunk #2 FAILED at 66.
Hunk #3 FAILED at 95.
Hunk #4 FAILED at 190.
Hunk #5 FAILED at 283.
5 out of 5 hunks FAILED -- saving rejects to file includes/api/ApiQueryAbuseLog.php.rej

If you have 2 honest admins, they can just unblock each other.