What if DCC send/receive would work only if both sides had each other in the address book set by default to ON?
And for the several dozen clients that don't support address books? Just prevent mIRC from dcc send/receive'ing with these clients? And how should mIRC know if you are listed on the other users address list?
What if the firewall support would only work if the firewall was on the same IP range (depending on class A B C) or on the same domain if the name was resolvable? After all, the feature is called "firewall" it is only meant to get you trough your local firewall, and not for exploiting other connections.
Well, there are SEVERAL companies that sell access to firewalls. These firewalls are NOT owned by your ISP and therefore may have not a single similarity to your IP address. Why should people who use these services be penalized? Also, I have access to several machines not run off my ISPs lines. I have access to install a socks4/5 server on these machines. Why shouldn't I be allowed to use my own server?
What if mIRC used some serial number as ident? After all you are not doing anything wrong thus you don't get banned right?
And no, serial numbers do not affect your privacy any more than any other information in nickname/ident/fullname. Perhaps this feature could be turned on by 005 numeric, at the network's request (REQUESTMIRCIDENT=YES).
If mIRC implemented such a feature, I know I (and probably everyone else) would disable identd support in mIRC and just download an identd.exe and set it to use whatever you want. It's a bad idea and one that can't even be implemented correctly. For example, how do you propose this serial number be generated? And how can it not give out more info? Thats a ridiculous statement. Nick/ident/fullname you can change, this serial number you can not. I can set my nick to "Bill", my realname to "Bill", and my ident to "bill" well my name isn't bill, so no information is given. But if a serial number is given some unwanted info is distributed. For example, one of the most effective serials is generated from the hardware installed on the system. If someone can determine how mIRC generates this hash they now know all the hardware installed in my system. Such a thing could lead to people being able to exploit your system (hardware is not immune to exploits, the Pentium 3 for example had a feature that could allow someone to track websites you viewed, etc). So how is knowing every piece of hardware on my system and possibly knowing ways to compromise my system in no way compromise security? How can you possibly compare knowing such information to seeing my nick as the fake name "bill"? Then assuming you do come up with some hash that provides no information and is unique, your 005 idea isn't possible at all. The 005 numeric is sent AFTER the ident response is already received. So how can mIRC send the serial rather than the regular ident only when it receives this token if it only receives this token after it has already sent the regular ident?
What if mIRC would allow you to set a password to protect your scripts from being modified, perhaps using MD5 values for the scripts? The same feature would also mean you cannot load
MD5 is a hash, NOT encryption. If something is hashed with MD5, well you can't reverse it. It is 1 way, thats how hashes work. As for using a two way algorithm, well if mIRC can decrypt it, that means anyone can, as long as they know how mIRC decrypts and encrypts. And based on the fact that people have discovered the method mIRC uses to generate serial numbers, I'm quite sure someone could break this protection in a matter of minutes. And if you meant it can't be viewed in the editor because the user didn't enter a passowrd, what is to stop someone from opening it in notepad or some other text editor that would completely ignore this password because it knows nothing about it?
