| Peachey88 | |
| May 28 2009, 8:56 AM |
| F5844: mediawiki-1.15.0rc1-anonymize-v2.patch | |
| Nov 21 2014, 10:42 PM |
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.
See: T262321: IP Masking
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.)
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Open | None | T95144 Avoid exposure of user IP addresses (tracking) | |||
| Duplicate | None | T20981 Allow anonymising of unregistered users ("IP editors") |
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*
-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...
https://www.mediawiki.org/wiki/Requests_for_comment/Exposure_of_user_IP_addresses
This task is a great find to expand my new RFC!
There are two very different issues here, let's try to address them separately:
The previous comments don't explain who or what (task?) exactly this task is stalled on ("If a report is waiting for further input (e.g. from its reporter or a third party) and can currently not be acted on"). Hence resetting task status, as tasks should not be stalled (and then potentially forgotten) for years for unclear reasons.
(Smallprint, as general orientation for task management:
If you wanted to express that nobody is currently working on this task, then the assignee should be removed and/or priority could be lowered instead.
If work on this task is blocked by another task, then that other task should be added via Edit Related Tasks... → Edit Subtasks.
If this task is stalled on an upstream project, then the Upstream tag should be added.
If this task requires info from the task reporter, then there should be instructions which info is needed.
If this task needs retesting, then the TestMe tag should be added.
If this task is out of scope and nobody should ever work on this, or nobody else managed to reproduce the situation described here, then it should have the "Declined" status.
If the task is valid but should not appear on some team's workboard, then the team project tag should be removed while the task has another active project tag.)
Where it was discussed, what will be shown instead of the ip-address? It would be nice if it was some kind of hash that allows, by the similarity of pseudo-nicknames (we must somehow understand that a person writes from the same address) to establish that this is either one subnet or close subnets.