Last modified: 2014-09-24 00:04:10 UTC
Please allow true anonymous IP editing. Spilting this discussion from the mailing list so that the people may submit the patches.
Clarified bug summary.
Created attachment 6167 [details] mediawiki-1.15.0rc1-anonymize-v2.patch
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.
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.
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...
