Page MenuHomePhabricator

Audit anti-abuse API calls and determine if they should be publicly visible
Open, LowPublic

Description

Take a look at these publicly available APIs and see how much information we give away without authentication.

Write a proposal of which should be restricted to trusted ("privileged") users only.

Thanks to @MER-C for this suggestion

Event Timeline

Restricted Application added subscribers: MGChecker, Aklapper. · View Herald TranscriptMar 5 2019, 12:26 AM
Krenair added a subscriber: Krenair.EditedMar 5 2019, 12:28 AM

dunno about antispoof (it probably just runs some public normalisation rules against the public user list?) but I expect the first two are just convenience validation against https://en.wikipedia.org/wiki/MediaWiki:Titleblacklist and https://en.wikipedia.org/wiki/MediaWiki:Spam-blacklist

MER-C added a comment.EditedMar 5 2019, 7:50 PM

Yes, that is true. But I argue that:

  1. most of the title blacklist should not be publicly visible for that exact reason
  2. the title blacklist should be private anyway to stop harassing usernames being broadcast publicly
  3. the whole point of the anti-abuse effort is to make it as inconvenient as possible - i.e. force them to go through the GUI and test them one by one, tripping up rate limits and triggering CAPTCHAs as they go along. After all registering harassing usernames requires validating them against the blacklist.

The same logic applies to T212718 - we no longer give this information away to non-autoconfirmed and logged out users who use the GUI, so why should we do so via the API?

Titleblacklist, spamblacklist and antispoof use data from public wiki pages.
One could manually parse the wikitext, extract the regex and apply them locally.

Thus, I don't see the need to restrict these API calls.

TBolliger triaged this task as Low priority.

If we're going to remove this from the API we should also remove them from the public wiki page, and obfuscate them to some degree