Page MenuHomePhabricator

Allow anonymising of unregistered users ("IP editors")
Open, Stalled, LowPublic

Description

Please allow true anonymous IP editing. Currently, unregistered users' edits always make their IP addresses public in page history.

Splitting this discussion from the mailing list so that the people may submit the patches.


Previous discussions: https://www.mediawiki.org/wiki/Requests_for_comment/Exposure_of_user_IP_addresses#Previous_discussions
Merged tasks: T2556, T7486, T64979, T92366. (This manual list is necessary due to T883/T887. Please don't remove.)

Details

Reference
bz18981

Event Timeline

bzimport raised the priority of this task from to Low.
bzimport set Reference to bz18981.
bzimport added a subscriber: Unknown Object (MLST).

Clarified bug summary.

hanno wrote:

mediawiki-1.15.0rc1-anonymize-v2.patch

Attached:

09:02 < flyingparchment> you can't just encrypt it, you need something cleverer
09:02 < flyingparchment> i suggest doing it how unreal ircd does it
09:02 < flyingparchment> you get a fake "IP" that looks like this: 32FFF7DC.3A716EB8.7D3F1A12
09:03 < flyingparchment> if you ban that, it's the same as one IP; if you ban 32FFF7DC.3A716EB8.*, it's like banning the /24, etc
09:03 < flyingparchment> that way you hide the ip, but you don't lose the administrative flexibility

I agree, too.

Also, your patches should be against trunk, not against 1.15-rc1.

hanno wrote:

Current patch applies also to trunk, I'll provide a new one if neccessarry.

About more intelligent solutions: Nothing against that, but it's not really trivial to do it in a sane way. Considering the sense of the whole thing is anonymity would require that also the administrator or someone else with administrative privileges is not able to find out the IP afterwards. So solutions with a fixed salt or something like that won't work.

But anyway, if someone wants to do such a thing, it wouldn't hurt imho to provide both options.

The problem is that this provides extra privacy at the expense of creating a major gap in security. You can no longer block abuse from individual IPs, you can only block every anon editor or none of them. You wouldn't be able to use the "autoblock" feature when blocking an account, because it would just block everyone. Given the option between this and just not allowing anon editing, I don't see why people wouldn't choose the latter, as this makes it virtually impossible to control abuse.

(In reply to comment #4)

About more intelligent solutions: Nothing against that, but it's not really
trivial to do it in a sane way. Considering the sense of the whole thing is
anonymity would require that also the administrator or someone else with
administrative privileges is not able to find out the IP afterwards. So
solutions with a fixed salt or something like that won't work.

If you put the salt in the config file, then only people with access to the server could know it, and if you can't trust them, then you have bigger problems than this.

*Bulk BZ Change: +Patch to open bugs with patches attached that are missing the keyword*

demon added a comment.Sep 30 2011, 3:37 PM

-need-review +reviewed.

I couldn't see this getting applied in its current form. If we do this, it should definitely be done as outlined in comment 3.

Note that a feature that hashes and consistently salts the ip enabling blocks to still be applied would still disable the ability to range block.

hanno wrote:

As I tried to explain above, using a static salt and hashing with that is not the same as anonymizing the IP.

Consider this:
If someone breaks into a server running a mediawiki installation (by hacking the server, by raiding the server location or whatever), he can de-anonymize everything that happened in the past. This can happen afterwards, the attacker does not need to have access at the time the edit is happening.
This is something completely different than the case if someone has permanent access to the server.

A solution to that would be a regularly-changing salt, maybe once a week.

(In reply to comment #9)

As I tried to explain above, using a static salt and hashing with that is not
the same as anonymizing the IP.

Consider this:
If someone breaks into a server running a mediawiki installation (by hacking
the server, by raiding the server location or whatever), he can de-anonymize
everything that happened in the past. This can happen afterwards, the attacker
does not need to have access at the time the edit is happening.
This is something completely different than the case if someone has permanent
access to the server.

A solution to that would be a regularly-changing salt, maybe once a week.

What is the point of storing anything at all if you're hashing and salting it in ways that preclude the ability to do blocks or attribution?

Also rather than a fixed salt salting with something like the revision id would be better. I think...

demon removed a subscriber: demon.Dec 16 2014, 6:10 PM
Nemo_bis updated the task description. (Show Details)Apr 5 2015, 8:03 PM
Nemo_bis changed the task status from Open to Stalled.
Nemo_bis set Security to None.
Nemo_bis added a subscriber: CristianCantoro.
Ricordisamoa added a subscriber: Ricordisamoa.
sumanah removed a subscriber: sumanah.Apr 5 2015, 10:34 PM
MZMcBride updated the task description. (Show Details)Apr 6 2015, 3:28 PM
awight added subscribers: tstarling, Nemo_bis.EditedApr 6 2015, 6:57 PM

There are two very different issues here, let's try to address them separately:

  1. Many people will be more comfortable if IP addresses are not revealed on public pages.
  2. CheckUser admins and antivandalism bots should be able to continue their work, but maybe there is a way to hash the IP addresses before we store them in our database?
Nemo_bis renamed this task from Allow anonymising of IP editors to Allow anonymising of unregistered users ("IP editors").Apr 6 2015, 8:19 PM
Nemo_bis updated the task description. (Show Details)
Nemo_bis updated the task description. (Show Details)
Nemo_bis updated the task description. (Show Details)Apr 6 2015, 8:24 PM

(Thanks for the task fixes, Nemo!)

Risker added a subscriber: Risker.Apr 29 2015, 2:25 PM
DoRD added a subscriber: DoRD.Apr 29 2015, 2:35 PM
Melos added a subscriber: Melos.Apr 30 2015, 5:49 PM
Nirmos added a subscriber: Nirmos.Sep 9 2017, 7:20 AM
Ltrlg added a subscriber: Ltrlg.Jun 14 2018, 6:40 AM