Hello Abigail, Tuesday, May 17, 2005, 3:53:28 PM, you wrote: Why? I don't propose letting to log in only for THAT only user. Any user will be able to log in - or even to post anonymously - it just won't be so implicit. I think, usual "remember my password across session" option is already working through cookies. So if cookies are set properly, I will be already logged on. And if I'm not logged on, cookies are wrong - so I think your proposition has little sense... -- Best regards, monk mailto:monk@zoomcon.com

On 19/05/05, Eric <ek79501(a)yahoo.com> wrote:

On 5/19/05, Eric <ek79501(a)yahoo.com> wrote: Perhaps it is not incompetance on the part of everyone else, but your failure to effectively communicate your goal? The simplest answer... Anyway, it sounds like you want a secure hash, so why not use something like MD5 or SHA or something?

Eric wrote: This means that the IP address can still be reconstructed from the "unique number". What you are suggesting is called "security by obscurity". Unfortunately, you are forgetting that the source code is open, and so any formula - no matter how complex - can be seen by everybody. I'm not sure if the GPL allows you to keep your formula secret. But even if it does, you only need an untrustworthy admin, or an accidental technical problem that reveals the relevant source code, and the IP addresses can be reconstructed until you find out that the formula has leaked. Additionally, you are forgetting that dial-up users sometimes get an IP allocated that a different user had in the past. If they can see they get the same ID allocated for their edits as a previous user, it will be obvious that they had the same IP. Sorry to bust your bubble. Timwi

Brent 'Dax' Royal-Gordon <brentdax <at> gmail.com> writes: Your idea looks good. I tried doing the MD5 thing. It does generate a nonsense number that is almost impossible to crack, but WIKI didnt allow me to ban that certain user. Hmm. Maybe the output string was too large etc or something and the program was'nt designed to ban that long 'string' IP. The aim is to prevent anyone from seeing the real IP. There can be simple digit tranformations (put digit 7 in place 1, etc - kind of criss crossing) and mathematical operations on the IP's to contort them beyond recognition. Repeat a couple of times to really mix it up, for example: --- 123.456.789.xxx 68x.12x.543.x97 add, 10,25,30 and 43 to each of the respective segments Jumble up again add something again --- And now you have a nonsense IP that's almost impossible to crack. Regarding what a user said about "what if the formula is accessed by an unfaithful admin": If anyone's able to get that formula, they are able to get into my database anyway so there's no use of thinking "what if a hacker admin got in". If they got in, they've gotten everything anyway. So we can get a certain number that is a 1-to-1 and I've seen in once instance that it allows us to ban single IP's as before. Do we admins really need real IP addresses for the vandal, unless we want to report any vandalism act. And oh, in our special:reverseip page, we could actually write the reverse formula that gives us the real IP if we need it. The only big problem is banning IP blocks. I dont know if that will work. I have to try and see.

Ivan Krstic <krstic <at> fas.harvard.edu> writes: You're probably right about the possibility of cracking the makeshift jumbling i suggested earlier, and the fixed salt MD5 seems a better option of assigning a unique number to each IP. Your two ideas are good for anonymity, however, easily dealing with Vandalism is an equally important aim I cant afford to compromise with. If the IP's are hidden, people would not be able to click on that unique number and see all the edits by that certain number/IP. If the IP's are encrypted uniquely with different salt each time, that too will disable people from checking the vandalist acts made by the same IP. So one thing is clear: We need a unique number for each IP. The chance of someone having the same IP as another person is very small so that doesnt matter. The asymetric cypher you and others suggested seems the best choice. Interestingly the anonymous edit tracking works if the output 'code' (IP) starts with a number. If it starts with a letter (like f7564ghfdd), it doesnt work. That problem is solved by adding a constant number to each anonymous code (like 5f7564...). Anonymity means that ideally, not even Admins should see the real IP so the real IP should not be stored in the database even if MyPhPadmin is the only way to access it. Dealing with vandalism is the remaining issue: The site will be controversial so there will be lots of vandals. Removing anoynous editing is an option but I want to see how it goes before I'm forced to remove anoymous editing. I dont believe Wiki is equipped to deal with vandals easily. Looking at the case of a vandal who does 50 edits in a single day and how WIKI itself advises to deal with it: - Click on all the rollback links So we'd have to click 50 times on all the rollback links. Think about dealing with this daily. Since same IP's can be used by others, WIKI should add a certain unique random number that makes that IP and that machine unique. Something that could come from creating a cookie in that machine. So you'd have 111.111.111.111.PC_ABR34 PC_ABR34 identifies that certain PC so if another person is using another PC with the same IP, they'll get a different number. The aim is to differentiate 2 people using the same IP and thus differentiate the vandal from the good guy. With that in place, there should be a way to reject all the changes of a single IP/PC with a few sysop clicks. Also, there should be protection from bots which copy paste the same text in the mass vandalism they do. Detection should be there to catch the same text being posted in different pages from the same IP and block or atleast postpone suspicious edits until someone approves it. Flood limits should be set between edits so we can reduce the number of spam vandal edits. Automatic Alert pages should be present for anonymous edits, particularly high volume edits from the same IP. So I think that WIKI is not well equipped to deal with anonymous vandalism. It works for most of the information WIKI has which is nuetral, but this is a big problem for controversial topics where vandals are bound to be more. Removing anonymous editing has the disadvantage you know of already. There definitely has to be a way of dealing with anonymous vandalism more efficiently and quickly. I'm glad the uniquq salt/code works, so I do have a way to ban a single IP but dealing the vandalism is the next big problem. Eric

Brent 'Dax' Royal-Gordon <brentdax <at> gmail.com> writes: Brent, Thanks for putting it nicely! MD5 hash is good for showing a consistent unique number but its now allowing me to ban. It says "user doesnt exist" when I try to ban that hash. I would greatly appreciate if you allow me to contact you and seek your help in this as you are going to do the same thing I need too: Show an anonymous IP, only admin sees the real IP and ban the blocks if people are being consistent vandals, etc. thanks a lot Eric

On 5/22/05, Eric &lt;ek79501(a)yahoo.com&gt; wrote:

Hello John, Tuesday, May 17, 2005, 4:08:49 PM, you wrote: I want to stress again - I by no way meant to disallow anonymous posting AT ALL; just to make it more explicit. may be. Is there any note about custom css files? how to make them and so on. -- Best regards, monk mailto:monk@zoomcon.com

On 5/17/05, John Fader &lt;jfader(a)gmail.com&gt; wrote: ...which are documented, btw, at http://meta.wikimedia.org/wiki/User_styles (Thinks to self: hmm, it should be easy enough to write a [[greasemonkey]] script which detects when you're not logged in and zaps the edit page link.) -- John Fader