WMDE/Wikidata/Reports/2023/2023-09-18 Ramifications of IP masking on Wikidata related extensions

From Wikitech
< WMDE‎ | Wikidata

With the upcoming IP Masking feature (see IP Editing: Privacy Enhancement and Abuse Mitigation and #IP Masking), we need to look at what that means for Wikidata. A first investigation was done in phab:T328454 and this summarizes its findings.

We looked at two aspects specifically:

  • Places where Wikibase distinguishes between anonymous and registered users (phab:T343800)
  • Behavior of temporary accounts with cross-wiki API actions (phab:T343799)

Aspects that were out of scope of this particular first investigation:

  • How does this affect Wikidata Bridge (phab:T343786)
  • How does this affect the REST Api (no task created yet)
  • How does this affect Wikibase installations outside of WMF that want to enable that feature (no task created yet)


Results

Places where Wikibase distinguishes between anonymous and registered users

Results taken over from phab:T343800.

Wikibase

  • Wikibase shows an anon-editing warning when not logged-in and editing statements/terms/sitelinks
  • Special:MyLanguageFallbackChain informs about babel on the userpage for logged-in users. That is actually something temp-users can currently do, but I'm not sure if that is intended? What happens when such a temp user logs in? It works though.
    • In general: LanguageFallback taking Babel into account is difference between logged-in and anon users. Even if you would add a Babel-box to an IP-"Userpage", it would not have an effect on language fallback
  • All other Wikibase SpecialPages that allow some form of editing have a Warning only for Anon IPs, not temp users
  • Also the undo and restore dialogs of Wikibase have the anon editing warnings only for Anon IPs, not temp users
Wikibase Client
  • the jquery.Ui LinkItem widget is only shown to registered users and not Anonymous IPs. However, it is currently shown to temporary users. (See also: phab:T140661)
Broken remembering of preferences for temp users
  • Showing/Hiding the Legacy Termbox is usually remembered. For anons via a cookie, for logged-in users via a user options. Temp users do not have user options, so this feature is broken for them.
  • Similar to the above, dismissing the message informing about copyright, that shows when editing Statements or Sitelinks, is remembered in a cookie for anon IPs and a user option for proper logged-in users. This too is broken for temp-users.
  • Similar to the above, for federated Properties, we seem to show a "leave site notice"? Remembering the dismissal of that would probably be broken as well. But that is not a Wikidata concern directly.
Probably unaffected/maybe changes for the sake of clarifying the intention only
  • For Wikibase's undo and restore, we're might add the Entity to the user's watchlist, if they're logged in. But I would expect that to still work as expected with temp users (as in: do nothing)
  • \Wikibase\Repo\Store\Sql\WikiPageEntityStore::updateWatchlist has a check for the users being registered, but I don't expect that to break either

WikibaseLexeme

  • Special:MergeLexemes and the non-js fallback of Special:NewLexeme use User:isRegistered() for showing the anon user warning.
  • The Vue-based Special:NewLexme page gets that information for the same purpose via js: mw.user.isAnon().
  • The editing Statements functionality comes from Wikibase, and so the notes there apply

EntitySchema

  • Special:NewEntity, Special:SetLabelDescriptionAlias, and Editing the Schema Text, all show a warning based on the user being an anonymous IP. As far as I can tell, none of them currently trigger a temp user account creation.

WikibaseQualityConstraints

  • If the configuration to show violations to all users is disabled, then the Gadget to show the violations is loaded only for "registered" users, but not anonymous users. "Registered" in that sense includes temporary users.


Behavior of temporary accounts with cross-wiki API actions

Results taken over from phab:T343799.

At the moment, temporary accounts are enabled on beta cswiki and beta dewiki (config change, see also phab:T327420), so it was concluded that this should be investigateable this on the beta cluster reasonably well.

In a private window, a beta dewiki test page was created (and, non-anonymously, a corresponding beta enwiki one), triggering the creation of a temporary account. Then the menu in the sidebar was used to connect the dewiki page to the enwiki one. The resulting beta wikidata item was created by the temporary account. (This worked despite the fact that temporary accounts weren’t even enabled on beta wikidata yet at the time.) This seems like the wanted behavior.

It was also considered to test connecting wiki pages (like above), while not logged into a temporary account yet (which is closer to the scenario in phab:T343799#9077326), but in that case the item linking interface isn’t available in the first place – wikibase only shows that to registered users. (Whether temporary accounts should count as registered here is a question also brought up in the Wikibase client section above.)

Another important thing to test is Change Dispatching – if a temporary account makes a Wikidata edit, it should get dispatched to other wikis under that temporary account name as well. To test that, IP Masking was enabled on Beta Wikidata; subsequently, as shown in phab:T343800#9083923, edits from a temporary account on Beta Wikidata do result in the temporary account also being auto-created on client wikis subscribed to that Wikibase Entity and the changes being dispatched and properly attributed there.

The conclusion so far is that temporary accounts work just fine with cross-wiki actions: both client-side ForeignApi requests and server-side dispatch jobs can automatically create the temporary account on the other wiki (even if that wiki doesn’t have temporary accounts enabled yet) and attribute edits to them.

Observations relevant for non-WMF installations

Less related to Wikidata because it has CentralAuth, but maybe relevant to the ecosystem at large: It was noticed that linking a Wikipage to an Item on different wiki failed in a local dev setup with the user being unknown. So, if wikifarms want to enable that, they probably have to take steps to make sure that their temporary users are synced as well. (see phab:T343800#9086219)

Closing notes

The upstream implementation seems to still see very active development, so it might make sense to wait for that work to settle somewhat and not rush Wikidata development:

Retrieved from "https://wikitech.wikimedia.org/w/index.php?title=WMDE/Wikidata/Reports/2023/2023-09-18_Ramifications_of_IP_masking_on_Wikidata_related_extensions&oldid=2113718"