Page MenuHomePhabricator

Investigate: Which WMF deployed code might be affected by IP Masking?
Open, Needs TriagePublic

Description

The table gives a rough look at features that might be affected by IP Masking.

The search results cover Wikimedia deployed code, but not third party code or on-site gadgets.

Caveats:

  • There may be more ways in which features are affected, to be added to the table below
  • Some methods have very generic names, so conventional variable names are used in the searches (e.g. $user->getName)
  • The searches may miss places (or find false positives) where variables are named unconventionally
  • There may be false positives, where the features don't need updating for temporary accounts
Use caseSearch termsCodesearch
Fetaure checks whether a user is registered->isAnon, ->isRegistered, mw.user.isAnon, mw.user.getId, mw.user.getRegistrationsearch results
Feature checks a user name (possibly then checking if it is registered)mw.user.getName, $user->getName, $user->getRealNamesearch results
IP address utility functions are imported/used (IP addresses may be found via an anonymous username)use Wikimedia\IPUtils, mw.util.isIPAddresssearch results
Feature renders a user name::userLink, ::revUserLink, ::revUserToolssearch results

Related Objects

Mentioned In
T357410: Prepare Campaigns extension for IP Masking
T355377: Update MediaWiki Platform team owned products for IP masking
T349219: [M] Investigate: Which workflows create an IP actor?
T339244: Update Moderator Tools-owned products that may be affected by IP Masking
T338836: How should blocks treat temporary users?
T331752: Investigate: Update CheckUser for IP Masking
T331751: Investigate: Update GlobalBlocking for IP Masking
T331750: Investigate: Update SecurePoll for IP Masking
T331749: Investigate: Update AntiSpoof for IP Masking
T331653: Investigate: Update AbuseFilter for IP Masking
T331637: Update features in MediaWiki core for IP Masking
T331579: Email defaults for Temporary account should match those for anon users
T331578: File upload defaults for Temporary account should match those for anon users
T330815: Disallow preference setting by temporary users
T331576: Rate limits for Temporary account should match those for anon users
T331573: Disable Preferences for Temporary users
T324603: The CheckUser extension should provide IP addresses of temporary account users, for IP Masking
T331089: Rate limits for temporary users should be the same as those for IP/unregistered editors
T329459: [L] IP Masking Considerations: MachineVision
T329458: [SPIKE] IP Masking Considerations: WikimediaEditorTasks
T329457: IP Masking Considerations: services/parsoid
T329456: IP Masking Considerations: parsoid/deploy
T327677: Investigate: Which features display user links?
T327570: [SPIKE] Document the changes IP Masking will require the Editing Team to make
T326956: Evaluate the effects of IP Masking on Analytics
T326943: Update Fundraising Tech-owned products that may be affected by IP Masking
T326941: Prepare GlobalWatchlist extension for IP Masking
T326940: Prepare ProofreadPage extension for IP Masking
T326939: Prepare WikimediaIncubator extension for IP Masking
T326937: Prepare CentralAuth extension for IP Masking
T326936: Prepare Collection extension for IP Masking
T326935: Prepare Nuke extension for IP Masking
T326934: Prepare FlaggedRevs extension for IP Masking
T326933: Prepare WikimediaMessages extension for IP Masking
T326932: Prepare WikimediaMaintenance extension for IP Masking
T326931: Prepare WikiLove extension for IP Masking
T326930: Prepare UploadsLink extension for IP Masking
T326929: [SPIKE] Investigate TitleBlacklist extension to see if changes are required for IP Masking
T326928: Prepare TemplateSandbox extension for IP Masking
T326927: Prepare SandboxLink extension for IP Masking
T326926: Prepare Renameuser extension for IP Masking
T326925: Prepare OATHAuth and WebAuthn extensions for IP Masking
T326924: Prepare Newsletter extension for IP Masking
T326923: [SPIKE] Investigate MassMessage extension to see if changes are required for IP Masking
T326922: Prepare LiquidThreads extension for IP Masking
T326921: Prepare LdapAuthentication extension for IP Masking
T326920: Prepare GlobalUserPage extension for IP Masking
T326919: Prepare GlobalCssJs extension for IP Masking
T326918: Prepare DismissableSiteNotice extension for IP Masking
T326917: Prepare BounceHandler extension for IP Masking
T326916: Prepare BetaFeatures extension for IP Masking
T326915: Prepare VipsScaler extension for IP Masking
T326911: Update Web Team-owned products that may be affected by IP Masking
T326910: Update Wikimedia Cloud Services-owned products that may be affected by IP Masking
T326909: Update Wikipedia Library products that may be affected by IP Masking
T326908: Update WMDE Engineering-owned products that may be affected by IP Masking
T326884: [XL] Update Structured Data Team-owned products that may be affected by IP Masking
T326883: Update Search Platform Team-owned products that may be affected by IP Masking
T326882: Update Product Infrastructure-owned products that may be affected by IP Masking
T326881: Update Platform Engineering-owned products that may be affected by IP Masking
T326880: Update Performance Team-owned products that may be affected by IP Masking
T326879: Update Language Team-owned products that may be affected by IP Masking
T326878: Update Inuka Team-owned Wikistories for IP Masking
T326877: [Epic] Update Growth Team-owned products that may be affected by IP Masking
T326876: Update Editing Team-owned products that may be affected by temporary users
T326875: Update Data Engineering-owned products that may be affected by IP Masking
T326874: Update Content Transform Team-owned products that may be affected by IP Masking
T326873: Update Community Tech-owned products that may be affected by IP Masking
T326872: Update Campaigns Team-owned products that may be affected by IP Masking
T326871: Update Security Team-owned products that may be affected by IP Masking
T326869: Update TSP-owned products that may be affected by IP Masking
T326816: Update features for IP Masking
Mentioned Here
T339874: Show more helpful messages when temporary users can't access features
T341228: Update action API to handle temporary users
T344276: Should SpecialPages that return true for ::requireLogin allow access to temporary users?
T337103: Decide a standard approach for classifying temporary, IP and registered users
T338836: How should blocks treat temporary users?
T337042: Temporary account users should have the same ParserOptions as anonymous users
T332411: Make some authentication APIs unavailable to temporary users
T330815: Disallow preference setting by temporary users
T330816: [Epic] Temporary users should not be assigned to user groups
T331576: Rate limits for Temporary account should match those for anon users
T331578: File upload defaults for Temporary account should match those for anon users
T331579: Email defaults for Temporary account should match those for anon users
T331637: Update features in MediaWiki core for IP Masking
T300294: [Epic] Temporary account block workflow
T327888: Create a function that checks if a username is a temporary user in JS
T327317: Create a function that checks if the global session user is a temporary user in JS
T326816: Update features for IP Masking

Event Timeline

There are a very large number of changes, so older changes are hidden. Show Older Changes
Use caseSearch termsCodesearch
Fetaure checks whether a user is registered->isAnon, ->isRegistered, mw.user.isAnon, mw.user.getId, mw.user.getRegistrationsearch results
Feature checks a user name (possibly then checking if it is registered)mw.user.getName, $user->getName, $user->getRealNamesearch results
IP address utility functions are imported/used (IP addresses may be found via an anonymous username)use Wikimedia\IPUtils, mw.util.isIPAddresssearch results
Feature renders a user name::userLink, ::revUserLink, ::revUserToolssearch results

Potentially affected repos, according to these searches:

repoMaintainer
AbuseFilterAnti-Harassment Tools
AntiSpoofAnti-Harassment Tools
CheckUserAnti-Harassment Tools
GlobalBlockingAnti-Harassment Tools
IPInfoAnti-Harassment Tools
SecurePollAnti-Harassment Tools
SimilarEditorsAnti-Harassment Tools
CampaignEventsCampaigns Product team
CampaignsCampaigns Product Team
ArticleCreationWorkflowCommunity Tech
CodeMirrorCommunity Tech
GlobalPreferencesCommunity Tech
LoginNotifyCommunity Tech
TemplateWizardCommunity Tech
MachineVisionContent Transform Team
parsoid/deployContent Transform Team
services/parsoidContent Transform Team
WikimediaEditorTasksContent Transform Team
EventBusData Engineering
EventLoggingData Engineering
CodeEditorEditing team
ConfirmEditEditing team
DiscussionToolsEditing team
TemplateDataEditing team
VisualEditorEditing team
WikiEditorEditing team
CentralNoticeFundraising tech
DonationInterfaceFundraising tech
LandingCheckFundraising tech
EchoGrowth team
GrowthExperimentsGrowth team
NewUserMessageGrowth team
PageTriageGrowth team
StructuredDiscussions (aka Flow)Growth team
ThanksGrowth team
WikistoriesInuka team
BabelLanguage team
ContentTranslationLanguage team
TranslateLanguage team
TranslationNotificationsLanguage team
UniversalLanguageSelectorLanguage team
WikimediaEventsPerformance Team
OAuthPlatform Engineering Team
TorBlockPlatform Engineering Team
TrustedXFFPlatform Engineering Team
WikimediaApiPortalPlatform Engineering Team
ContactPageProduct Infrastructure
ReadingListsProduct Infrastructure
CirrusSearchSearch Platform
StopForumSpamSecurity Team
GWToolsetStructured Data team
ImageSuggestionsStructured Data team
MediaSearchStructured Data team
MultimediaViewerStructured Data team
SearchVueStructured Data team
UploadWizardStructured Data team
WikibaseMediaInfoStructured Data team
CologneBlueWeb Team
MinervaNeueWeb Team
MobileFrontendWeb Team
MonoBookWeb Team
NostalgiaWeb Team
PopupsWeb Team
QuickSurveysWeb Team
TimelessWeb Team
VectorWeb Team
OpenStackManagerWikimedia Cloud Services
TheWikipediaLibraryWikipedia Library team
AdvancedSearchWMDE Engineering
EntitySchemaWMDE Engineering
FileImporterWMDE Engineering
RevisionSliderWMDE Engineering
TwoColConflictWMDE Engineering
WikibaseWMDE Engineering
WikibaseLexemeWMDE Engineering
WikibaseQualityConstraintsWMDE Engineering
BetaFeaturesNo WMF team
BounceHandlerNo WMF team
CentralAuthNo WMF team
CollectionNo WMF team
DismissableSiteNoticeNo WMF team
FlaggedRevsNo WMF team
GlobalCssJsNo WMF team
GlobalUserPageNo WMF team
GlobalWatchlistNo WMF team
LdapAuthenticationNo WMF team
LiquidThreadsNo WMF team
MassMessageNo WMF team
NewsletterNo WMF team
NukeNo WMF team
OATHAuthNo WMF team
ProofreadPageNo WMF team
RenameuserNo WMF team
SandboxLinkNo WMF team
TemplateSandboxNo WMF team
TitleBlacklistNo WMF team
UploadsLinkNo WMF team
VipsScalerNo WMF team
WebAuthnNo WMF team
WikiLoveNo WMF team
WikimediaIncubatorNo WMF team
WikimediaMaintenanceNo WMF team
WikimediaMessagesNo WMF team

Maintainers mostly as listed on https://www.mediawiki.org/wiki/Developers/Maintainers. In a very few cases, unowned repos have been assigned despite not being listed there, e.g. anti-vandalism extensions to AHT, Campaigns extension to the Campaigns Team, etc.

Tasks have been made for all of these - see subtasks of T326816: Update features for IP Masking

  • Work for WMF-owned products is delegated to the owning teams
  • Work for unowned products is currently assigned to AHT

Other affected repos:

  • MediaWiki core - To do: Investigate which teams own affected parts of MediaWiki core
  • operations/mediawiki-config - To do: Does this config need to be updated?
  • a couple of other obvious false positives e.g. vendor, etc.

It would be very helpful if, along with the list of "potentially bad" methods in codesearch, there was also documentation about what exactly should be done -- what methods should replace these, what patterns to look for, etc.

It would be very helpful if, along with the list of "potentially bad" methods in codesearch, there was also documentation about what exactly should be done -- what methods should replace these, what patterns to look for, etc.

Hi @cscott! It's honestly difficult to know all the ways in which various things will be affected, but the major one we've identified is that there are now three "types" of user, rather than two. Whether features need updating and how will depend on whether temporary account users should be treated the same as registered users, the same as anon users, or in a different way altogether. Feature owners should make those decisions (though we can help, and cross-team co-ordination may be needed with some things, and also there's a wealth of un-owned products that we're still trying to figure out how to approach...)

Examples of what should be done in some situations:

Your code was checking...You want...Your code should now...
$user->isRegistered()to treat temp users the same as registered usersno change needed
$user->isRegistered()to treat temp users the same as anon userscheck $user->isNamed()
$user->isAnon()to treat temp users the same as registered usersno change needed
$user->isAnon()to treat temp users the same as anon userscheck !$user->isNamed()
$user->isRegistered() or $user->isAnon()to treat temp users differently from registered users or anon usersadd another check for $user->isTemp()

The equivalents in JavaScript don't seem to exist yet, but we're implementing them in T327317: Create a function that checks if the global session user is a temporary user in JS and T327888: Create a function that checks if a username is a temporary user in JS. (Please bear with us while we catch up! We didn't implement the temporary user accounts so we're figuring out as we go too.)

We included the other search terms in order to cast the net widely, to err on the side of finding cases rather than missing them.

  • For mw.user.getName, $user->getName, $user->getRealName, we reason that any uses of these could be checking whether a user is registered via inspecting the name
  • For use Wikimedia\IPUtils, mw.util.isIPAddress, we reason that the IP address may have been obtained via the user name (which will not be possible for temp accounts)
  • For ::userLink, ::revUserLink, ::revUserTools, we reason that any feature that displays a user name may want to treat registered / temp / unregistered users differently.

Does that help at all?

MediaWiki core - To do: Investigate which teams own affected parts of MediaWiki core

There were lots of hits, some spurious, some fixed, and some that may need fixing. Here's a summary of places that may need fixing.

See T331637: Update features in MediaWiki core for IP Masking for all tasks.

Product questions

Some questions raised about those features that may need fixing, broken into: general questions that may need consistent answers throughout the software, features that are unowned according to https://www.mediawiki.org/wiki/Developers/Maintainers , and features that are owned by particular teams.

General questions

Questions about ownerless features, or general questions that span many features.

Preferences T330815: Disallow preference setting by temporary users

  • Should the infrastructure (UserOptionsManager, UserOptionsLookup subclasses, etc) be updated to prevent preferences for temporary users?
  • Should features that work via preferences (e.g. Mute, search form options, etc) be unavailable to temporary users?

Notifications

  • Which notifications features should temporary users be able to access?

Uploading T331578: File upload defaults for Temporary account should match those for anon users

  • Should this be available to temporary users?

Email T331579: Email defaults for Temporary account should match those for anon users

  • Should this be available to temporary users?

User groups T330816: [Epic] Temporary users should not be assigned to user groups

  • Should it be possible to assign temporary users to user groups?

Rate limits T331576: Rate limits for Temporary account should match those for anon users

  • Rate limits are configured per user type. What rate limits should we apply to temporary users? (Same as anon? Same as logged in? A new category?)

Statistics T341228: Update action API to handle temporary users

  • Where user edits are counted differently for different users (e.g. recent changes, ApiQueryContributors, ApiQueryUserInfo, etc), how should temporary users be counted?

API T341228: Update action API to handle temporary users

  • Where APIs have a user parameter, should there be a separate type for temporary users? (See UserDef::PARAM_ALLOWED_USER_TYPES)
  • Where APIs have an assert parameter, used to check the type of accessing user, should there be a separate type for temporary users?

Flags T341228: Update action API to handle temporary users

  • Where different user types are flagged differently (some APIs, some logs), how should temporary users be flagged?
Team-specific questions

Questions of various sizes that I encountered while trawling through files. (Unlikely to be exhaustive, in that other teams' products in core may well be affected in ways not discovered here!)

Blocks (AHT) T338836: How should blocks treat temporary users?

  • Should blocked IPs defined in DnsBlacklistUrls and SoftBlockRanges apply to temporary account users?
  • Should it be possible to suppress a temporary account user? (It's not possible to suppress an IP user.)
  • How should autoblocks work for temporary accounts? (Blocked on community consultation as commented here: T300294#8476287)
  • If the "Apply block to logged-in users from this IP address" is unchecked, should it block temporary account users?
  • Should BlockDisablesLogin prevent a user from making a temporary account?

Growth

  • Should Watchlist be available to temporary users?

ContentTransform

  • Should ParserOptions for temporary account users be the same as for anonymous users?

Yes - T337042: Temporary account users should have the same ParserOptions as anonymous users

Editing

No, it can stay as is.

Performance/Security

No, can stay as is.

Web

  • Should ResourceLoaderClientPreferences be used for temporary users?

Technical fixes needed

Authentication T332411: Make some authentication APIs unavailable to temporary users

The following should be unavailable to temporary users:

  • ApiChangeAuthenticationData
  • ApiRemoveAuthenticationData
  • ApiLinkAccount

Technical debt

  • Fix some classes to be in sync with the User and Linker classes

Further investigations needed

UI messages T339874: Show more helpful messages when temporary users can't access features

  • Various messages have separate versions to display to anonymous vs registered users. Which of these should also have versions for temporary users?

Special pages T344276: Should SpecialPages that return true for ::requireLogin allow access to temporary users?

  • Special pages can specify that only logged-in users can use the special page (SpecialPage::requireLogin) - this currently allows temporary users. It's also possible to specify that only named (i.e. registered, non-temporary) users can user the page (SpecialPage::requireNamedUser). Some special pages may need updating to require named users. (Affects core and extensions.)