I am not the original author of https://www.mediawiki.org/wiki/Wikimedia_Labs/Agreement_to_disclosure_of_personally_identifiable_information, but I was the person who added similar information at https://wikitech.wikimedia.org/w/index.php?title=MediaWiki:Signupstart&diff=1768528&oldid=557530 to be displayed on the wikitech account creation screen.

The wording on the current account creation screen hopefully makes the exposed data slightly more clear.

• Email addresses are exposed because they are stored in the LDAP directory used by wikitech.wikimedia.org, Cloud-VPS, Gerrit, Phabricator, and other services related to developer accounts.
• IP addresses of SSH sessions are recorded by the operating system as a part of utmp data. This data can be seen by other users of the same system using native unix tools such as w.

We use a reverse HTTP proxy to hide the IP address of Toolforge webservice users from the maintainers of Toolforge tools. We have a similar IP stripping reverse HTTP proxy that is used by most *.wmcloud.org servers, but there is a process where users of that proxy can request an exemption that lets their backend HTTP server see end-user IPs rather then just the IP of the proxy (T135046). Some projects also have their own public IP addresses (https://beta.wmflabs.org/ is one example) which allow them to setup webservers and other services that are not behind any anonymizing proxy of any kind.

The additional claims covered by Ryan's draft agreement relate to who runs the "servers" in Toolforge and the other 170+ Cloud VPS projects. Each project has its own set of administrators who could be anyone with a developer account. In the draft these are "Cloud Services volunteers". Server administrators have wide ranging powers to view and record data. This is just a fact of unix computing.

Thank you, bd808. That's much clearer.

I don't recall seeing that warning when first using Phab in 2019. If having a Phab acocunt means that my e-mail address is viewable to others, that explicitly contradicts what I was told when I registered an account: "A valid email address will also be required for verification, but not shown to other users." See T214251 .

This seems to me to be a serious issue. Wikimedia editors have recently been arrested and threatened with long prison terms for their editing. If personally-identifiying information is going to be released if an editor performs certain actions, whether creatign a dev account or using certain tools, that needs to be very, very clear.

Only for people with LDAP accounts which is one of the 2 ways you can link your wikimedia account to your phab account.

You only have a mediawiki account linked so this is not an issue.

In T320585#8310012, @HLHJ wrote:

I don't recall seeing that warning when first using Phab in 2019. If having a Phab acocunt means that my e-mail address is viewable to others, that explicitly contradicts what I was told when I registered an account: "A valid email address will also be required for verification, but not shown to other users." See T214251 .

In T320585#8310170, @RhinosF1 wrote:

Only for people with LDAP accounts which is one of the 2 ways you can link your wikimedia account to your phab account.

You only have a mediawiki account linked so this is not an issue.

@RhinosF1 is correct. Phabricator itself does not expose your email address publicly. A developer account does as I described in T320585#8309947. A developer account is one of the two possible methods for authenticating to our Phabricator instance. This authentication path is the connection between Phabricator and a potentially public email address. The exposure does not happen through Phabricator itself; instead it is a side effect of having a developer account.

That's great, if these exposures only apply to developer accounts, not the default accounts, they are much better notified. Apologies for my confusion, and thank you all for clarifying.

For making dev accounts more pseudonymous, would it be possible to provide a wiki-domain e-mail alias for developer accounts, and have that recieve-only e-mail address forward everything to the dev's actual registered address? (or equivalent, related: T241039).

Proxying the SSH via some server with more restricted access sounds more complex.

Additional gmail accounts (or a (free) domain and cloudflare free email routing) is probably a decent way.

You're quite right, for most cases. But the people who really need to keep their identities private may well be living in countries where free e-mail providers like Gmail are blocked, and registering a domain is not the easiest task to do anonymously. These approaches have their own attack surface. Private, individual countermeasures to control e-mail leaks are also more complex for the user to implement.

I'm suggesting that the default setup not leak e-mails, thus bringing it in line with what editors on other projects generally expect.

Trying to not release IPs by default would also align with T133452.

In T320585#8318772, @HLHJ wrote:

For making dev accounts more pseudonymous, would it be possible to provide a wiki-domain e-mail alias for developer accounts, and have that recieve-only e-mail address forward everything to the dev's actual registered address? (or equivalent, related: T241039).

There is not currently anywhere to store that "actual registered address" that is not exposed. Developer accounts are records in an LDAP directory and that directory is readable from inside the Cloud VPS environment so that it can be used as an NSS source for user and group information. More elaborate systems could be invented to change all of this, but that also opens up questions of what the return on investment is for the movement generally on building, securing, and maintaining those systems indefinitely.

In T320585#8319008, @HLHJ wrote:

Trying to not release IPs by default would also align with T133452.

Very few things in computing are categorically impossible, but it is extremely difficult to setup a unix server such that interactive users of that server are not able to determine who else is connected and what IP the are connecting from. Recording the remote IP of an interactive shell user is a pretty low level functionality of these systems. My biggest concern in attempting to hide IPs would be the many ways that protection might fail and expose someone who would be put at risk. I think it is far better to tell everyone using these systems that their IP addresses will be exposed and allow them to decide if that is something they are willing to allow (or attempt to mitigate on their own by using a VPN or other means of hiding their true origin IP address from the Cloud Services systems).

Thank you for the explaination. So it'd need an entirely seperate server to relay the mail, and proxy the IPs, and it would be unreliable and probably not worthwhile?