IP listed in active transfers
Moderator: Moderators
IP listed in active transfers
Hi Guys,
I'm querying the addition of the IP column in the latest releases of DC++.
I'm running a LAN hub which the IP's of my users are DNS'd to physical locations, and this is considered an invasion of privacy. As I dont' have any control over the changing of such DNS schema, then this column i'd like to see removed, and not even an option to turn it on...
Although i'd like to hear why this option would REALLY be useful for the greater DC++ community.
-Asc3nti0n
.au
I'm querying the addition of the IP column in the latest releases of DC++.
I'm running a LAN hub which the IP's of my users are DNS'd to physical locations, and this is considered an invasion of privacy. As I dont' have any control over the changing of such DNS schema, then this column i'd like to see removed, and not even an option to turn it on...
Although i'd like to hear why this option would REALLY be useful for the greater DC++ community.
-Asc3nti0n
.au
coz MacsRBest
-
- Posts: 506
- Joined: 2003-01-03 07:33
Well? There is nothing you can do about it. Every time they interact as active clients they will send its own IP. Every time they communicate client<-->client ipinformation the physical location will be known. The information is there wheater you deside to show it in a client or not. So there is nothing todo here unless you want to tunnel all connections through an anonymous host.
Your users are asking for security/privacy by not showing something which you can find out anyway.
If you are a citizen of EU. You might try to convince your ISP that this is illegal.
i.e-your-specific-problem-is-your-isp-and-not-dc++-showing-IPs-ly'ers.
Your users are asking for security/privacy by not showing something which you can find out anyway.
If you are a citizen of EU. You might try to convince your ISP that this is illegal.
i.e-your-specific-problem-is-your-isp-and-not-dc++-showing-IPs-ly'ers.
Everyone is supposed to download from the hubs, - I don´t know why, but I never do anymore.
you missed it...
We're on a LAN ... 100Mbit CISCO all the way...
we aren't running through a ISP... i am aware that the backend & protocol REQUIRES the use of the IP, i'm debating the listing of it on the front panes of the client.
good for debug builds, but really for the general n00b who's on a power trip, looking up IP's and building up information on the general DC public... I'd rather keep that the domain of the admin. those of us that had some moral sense of these things.
we aren't running through a ISP... i am aware that the backend & protocol REQUIRES the use of the IP, i'm debating the listing of it on the front panes of the client.
good for debug builds, but really for the general n00b who's on a power trip, looking up IP's and building up information on the general DC public... I'd rather keep that the domain of the admin. those of us that had some moral sense of these things.
coz MacsRBest
-
- Posts: 506
- Joined: 2003-01-03 07:33
-
- DC++ Contributor
- Posts: 3212
- Joined: 2003-01-07 21:46
- Location: .pa.us
Yeah. i know it's false, but it controls n00bs. Having the IP in open air is a little different than viewing your zonealarm logs, people who know something about computers look through logs, having it right in front of them is a little different.
I was just interested in the addition of the column, generally just as a new feature to pointed out by the local DC population.
I was just interested in the addition of the column, generally just as a new feature to pointed out by the local DC population.
coz MacsRBest
-
- Posts: 506
- Joined: 2003-01-03 07:33
The fact is there was no real reason to put that feature in the program. You say that it was put in the program because it´s so easy to see the ip address anyway. Well I say why put it in there if it is so easy to see everyones ip address? In reality it isn´t so easy to match an ip address fram netstat or the firewall logs to a nick in DC, at least not if you don´t know exactly what you are doing.
Having the IP column in the transfer windows is bad enough but putting it in the search window too is way over the line. Now anyone using active mode can get the ip from everyone on the hub just with one click!!!
The only thing this will do to DC++ is make it less popular among operators and admins. In fact we have banned it as we have banned all clients that can show ip. And if we ban it then other hubs will too. We are making our own mod with this feature removed but I really hope that you will remove it in future versions so that we don´t have to. I will put up a link as soon as it is ready.
Having the IP column in the transfer windows is bad enough but putting it in the search window too is way over the line. Now anyone using active mode can get the ip from everyone on the hub just with one click!!!
The only thing this will do to DC++ is make it less popular among operators and admins. In fact we have banned it as we have banned all clients that can show ip. And if we ban it then other hubs will too. We are making our own mod with this feature removed but I really hope that you will remove it in future versions so that we don´t have to. I will put up a link as soon as it is ready.
It's sad, but probably true. Many people will gladly follow any idiots lead, since they are afraid of actually taking the time to learn about something themselves.Framed wrote:In fact we have banned it as we have banned all clients that can show ip. And if we ban it then other hubs will too.
However, let's pray that there are more intelligent people out there, and that reason will win over. False security is a very dangerous thing, especially now that the copyright organisations are starting to move into the EU, where the biggest part of the DC community is.
-
- Posts: 1
- Joined: 2004-04-02 07:08
This just makes it easier for them cheaters
Hey there, running a (@ the moment) 1.708 user hub and I must say that my very clever users have found a great use for this new "feature." They simply take that-lame-user-that's-always-DL'ing-from-me-but-has-a-pathetic-share-himself's IP from the transfer windows, maximize their firewall and add a rule to block outgoing to that IP.
Sorry to say... many of my users aren't so happy with this new "feature," I wonder why?
Thank's anyways.
Sorry to say... many of my users aren't so happy with this new "feature," I wonder why?
Thank's anyways.
Why are you so dead set on keeping this feature in there? If you were so worried about giving dc++ users a sense of false security why didn´t you add it alot earlier? Why now? You still haven´t given me/us a good reason for having that feature in there. Really, all I´m reading out of your answers is; just because or because we could. You can mock me all you want that still does not give us a good reason.
Lets put it this way: Arne refuses to put a bandwith limiter in dc++ on the grounds that it can be misused yet its relatively easy to limit the bandwith with external programs like netlimiter. So according to your reasoning dc++ should have a bandwith limiter because its easy to do externally.
It´s the same thing with the ip showing. People can very easily misuse this by blocking ip addresses in their firewall. Yes I know that they could get those ip addresses from netstat or their firewall logs and then block them but thats just like saying its ok to have a bandwith limiter in there.
Lets put it this way: Arne refuses to put a bandwith limiter in dc++ on the grounds that it can be misused yet its relatively easy to limit the bandwith with external programs like netlimiter. So according to your reasoning dc++ should have a bandwith limiter because its easy to do externally.
It´s the same thing with the ip showing. People can very easily misuse this by blocking ip addresses in their firewall. Yes I know that they could get those ip addresses from netstat or their firewall logs and then block them but thats just like saying its ok to have a bandwith limiter in there.
Yes you have a point, but the only one who can answer that question is really arnetheduck, it's hard for anyone else to tell you what his motivation is for adding certain features and not adding others.
Then again, if users want to block other users from downloading from then, then they'll most likely find a way anyway. Yes the IP makes it a bit easier, but if they are so dead-set against sharing, i doubt they would have been stopped anyway. And if you know this is going on, why don't you ban them instead? After all, it's easier to detect a complete blocking than a bandwidth limit..
Oh don't forget, for many programmers, "because i can" is more than enough motivation to add a feature..
Then again, if users want to block other users from downloading from then, then they'll most likely find a way anyway. Yes the IP makes it a bit easier, but if they are so dead-set against sharing, i doubt they would have been stopped anyway. And if you know this is going on, why don't you ban them instead? After all, it's easier to detect a complete blocking than a bandwidth limit..
Oh don't forget, for many programmers, "because i can" is more than enough motivation to add a feature..
It wasn't introduced earlier simply because no one had bothered writing it earlier. I took that initiative, and thus now it's in DC++. That's really a pretty stupid objection.
My strongest motivation for writing this patch was precisely because I knew the reaction it would generate, that people jealously held tight this utterly false sense of anonymity in how they used DC, and I wished to forcibly remove them from this tragic state.
"Op clients" have long displayed this sort of information, but since many ops seem to operate with this peculiar cognitive disconnect that when clients they use display such information it's acceptable or even encouraged, but when the mere proletariat has wide access to such clients, it's cause for outrage. (To the point where such clients have gotten non-ops kicked for their use. That to me is incredible hypocrisy.)
This patch partially fixed that, or at least triggered discussion of the issue.
My strongest motivation for writing this patch was precisely because I knew the reaction it would generate, that people jealously held tight this utterly false sense of anonymity in how they used DC, and I wished to forcibly remove them from this tragic state.
"Op clients" have long displayed this sort of information, but since many ops seem to operate with this peculiar cognitive disconnect that when clients they use display such information it's acceptable or even encouraged, but when the mere proletariat has wide access to such clients, it's cause for outrage. (To the point where such clients have gotten non-ops kicked for their use. That to me is incredible hypocrisy.)
This patch partially fixed that, or at least triggered discussion of the issue.
When DC++ first came out, it became banned on many hubs due to certain features (i believe multi-hub capability was the main one). Today, it is used by about 95% of the DC community. There will always be hubowners who resist progress for reasons they hardly understand themselves, but given time, progress is inevitable.. Just wait.MrZ wrote:The 0.401 is baned in the hubs im wisiting,,,
I think that the dc comunity is built up by hub owners, users and OP's and none of those in those hubs are happy to know about this feature.
-
- DC++ Contributor
- Posts: 3212
- Joined: 2003-01-07 21:46
- Location: .pa.us
That's okay, DC++ isn't meant to be a client for everyone - for you cannot keep everyone happy. If a new client comes along, and manages to win a majority of users and takes over DC++'s dominance of the client market, that would be great.MrZ wrote:Sorry to say you have not convinced them that/what this is good to their use.
(No, there's no sarcasm in this post.)
DC (the protocol in general, no matter what client one's using) promiscuously spreads one's IP. Users should be aware of this, and basking in ignorance whilst the copyright enforcement agencies hunt for future lawsuit victims is shortsighted and counterproductive.
Claiming something like "okay, we know" doesn't really answer this; if people had truly internalized it, they would be unoffended by this feature.
It has practical value for me, but that's less interesting than its value in educating people as to how easily one can acquire an IP on DC (again, irrespective of client). That, to me, is how it's good for users.
Claiming something like "okay, we know" doesn't really answer this; if people had truly internalized it, they would be unoffended by this feature.
It has practical value for me, but that's less interesting than its value in educating people as to how easily one can acquire an IP on DC (again, irrespective of client). That, to me, is how it's good for users.
Could the middle way not be the solution?
By enabling the hub to disable the debated feature, I feel everyone would "win".
I am a user on the hub Framed is OP, and it anoyes me graitly that they ban DC++. Mostly because they encourage users to use oDC witch does not have 1st development, 2nd TTH, witch I think will be the best thing DC++ has done to date.
By enabling the hub to disable the debated feature, I feel everyone would "win".
I am a user on the hub Framed is OP, and it anoyes me graitly that they ban DC++. Mostly because they encourage users to use oDC witch does not have 1st development, 2nd TTH, witch I think will be the best thing DC++ has done to date.
The feature is here to stay. Anyone without the knowledge on how to obtain the IP address if it weren’t in DC++, probably can’t use IP addresses in any harmful way anyhow.
If the hub you are visiting still bans DC++ for that reason, it sounds to me like its time to find another hub, with more enlightened OPs.
If the hub you are visiting still bans DC++ for that reason, it sounds to me like its time to find another hub, with more enlightened OPs.
"probably can’t", nice...Shroom wrote:The feature is here to stay. Anyone without the knowledge on how to obtain the IP address if it weren’t in DC++, probably can’t use IP addresses in any harmful way anyhow.
If the hub you are visiting still bans DC++ for that reason, it sounds to me like its time to find another hub, with more enlightened OPs.
The hub has just about 3000ppl.
The second largest hub has less then 300ppl.
The fact is, they are not wrong I cant hold up a debate that this is a good feature. I lose every time.
But why are you so determent to keep this in?
How is it not the best solution for everyone (you including) to have this as an option controlled by the hub?
What arguments are there to remove the IP column?cue wrote:The fact is, they are not wrong I cant hold up a debate that this is a good feature. I lose every time.
But why are you so determent to keep this in?
Why are you so determed to keep this away from DC++?
If you don't like the feature; simply remove it and tell people to download your hacked DC++.
The hubs are currently developed completely independent of DC++, by different people. So if you’re really serious about this feature you’ll have to convince them to include this feature in forthcoming releases. Thereafter you/someone could mod DC++ to use this “middle way�.cue wrote:Could the middle way not be the solution?
By enabling the hub to disable the debated feature, I feel everyone would "win".
But, as said in previous posts, this could lead to a feeling of false security since everyone still would be able to see your IP with a simple dos command, or the use of programs like NetLimiter.
With the risk of just adding more wood to this fire..........
I wanted to start by saying that I like cologic's argument that this is a fine way to educate the masses (No, I'm actually not sarcastic or ironic, I think it's a nice attitude).
Besides that I got a little bit curious about:
Regards
I wanted to start by saying that I like cologic's argument that this is a fine way to educate the masses (No, I'm actually not sarcastic or ironic, I think it's a nice attitude).
Besides that I got a little bit curious about:
Could you elaborate on that a bit cologic?, I'm just the curious kind over herecologic wrote:It has practical value for me.
Regards
"Nothing really happens fast. Everything happens at such a rate that by the time it happens, it all seems normal."
The reason i´m so determent to limit or remove this feature is stated above, please read all previus posts to understand what we are talking about.ullner wrote:What arguments are there to remove the IP column?cue wrote:The fact is, they are not wrong I cant hold up a debate that this is a good feature. I lose every time.
But why are you so determent to keep this in?
Why are you so determed to keep this away from DC++?
If you don't like the feature; simply remove it and tell people to download your hacked DC++.
I have no idea how to use netsat to link a connected IP to a specific user downloding from me to block him. If its at all possable, it would take much know how and manual ground work.
But you are right "Shroom" there is no way for me to get the hub developers to include this. DC++ developers would have to ask them and I can see that is not about to happen.
You have NO reasoning for this feature you just want it in there. I consider education to be a rather bad one. most of the ppl connected to DC++ network have no idea that you can trace an IP to a specific person. For that, they have no idea what an IP is.
So seeing it listed next to the names means nothing to them. Its just a number
But if you are serious about this you would post a warning every time the program starts.
I hope that that client of yours is ready soon because this is obviously a severe case. I assume you mean from "above" that you should be the one having control. If you are "scared" that someone else could be in "control", why not educate yourself? (No, this is not meant to be rude or disrespectful)cue wrote:The reason i´m so determent to limit or remove this feature is stated above, please read all previus posts to understand what we are talking about.
"BobBuilder" obviously have some "clever" users (as opposed to your nOOb users I presume) that found a way.cue wrote:I have no idea how to use netsat to link a connected IP to a specific user downloding from me to block him. If its at all possable, it would take much know how and manual ground work.
I don't see the education argument as a bad one. Actually it is the reason I like open-source software. To be able to educate myself and add/remove what I like/don't like. But sure, I am also a bit curious about cologic saying "It has practial value for me" and hopefully he will answer my question about that. If not, there's not much I can do about that.cue wrote:You have NO reasoning for this feature you just want it in there. I consider education to be a rather bad one. most of the ppl connected to DC++ network have no idea that you can trace an IP to a specific person. For that, they have no idea what an IP is.
Who's voice are you?. If this is the case with "your" users, what is the actual problem? (No, I didn't mean to be rude this time either)cue wrote:So seeing it listed next to the names means nothing to them. Its just a number
I see no other way for you to solve this problem but to mod the existing client/build your own (and obviously that was in the pipeline if I read your earlier posts correctly).
Other than that I agree with some of the former speakers/writers about the fact that hiding the IP is a bad way of providing false security to people.
Regards
"Nothing really happens fast. Everything happens at such a rate that by the time it happens, it all seems normal."
I am a user NOT an OP or hub owner, like I sad before.
I think there is not much more to say, both of us have logic behind us, I argue that education is a bad reason and this feature can have no use at all.
However I am also arguing with the OPs here, I dont know about any other hub that enforces this ban for this reasoning.
And now it seams I lost that argument, they simply sad "allowing other clients then the ones we "patch" is to much trouble"
My GUESS is that they found 5ppl or so that did this and now 3000+ users have to suffer for it.
I think there is not much more to say, both of us have logic behind us, I argue that education is a bad reason and this feature can have no use at all.
However I am also arguing with the OPs here, I dont know about any other hub that enforces this ban for this reasoning.
And now it seams I lost that argument, they simply sad "allowing other clients then the ones we "patch" is to much trouble"
My GUESS is that they found 5ppl or so that did this and now 3000+ users have to suffer for it.
My mistake, won't be repeatedcue wrote:I am a user NOT an OP or hub owner, like I sad before.
Well,cue wrote:I think there is not much more to say, both of us have logic behind us, I argue that education is a bad reason and this feature can have no use at all.
I do actually believe in the education value, but of course, you are free to believe what you want about that. However, I'm pretty sure about that there is a specific reason for having it in there. But I'll let someone else elaborate on that since I'm neither responsible nor capable of explaining the actual use of it.
Sure, I can understand your frustration about this but I'm sorry to say that I don't have any easy solution to this other than the before stated.cue wrote:However I am also arguing with the OPs here, I dont know about any other hub that enforces this ban for this reasoning.
Yes, I do understand that you are "caught between two tigers"cue wrote:And now it seams I lost that argument, they simply sad "allowing other clients then the ones we "patch" is to much trouble"
Too bad, but I must stress that this is sometimes the price one must pay for innovation (your own definition goes here), Especially in a such divergent environment as the DC community.cue wrote:My GUESS is that they found 5ppl or so that did this and now 3000+ users have to suffer for it.
Regards
"Nothing really happens fast. Everything happens at such a rate that by the time it happens, it all seems normal."
Guitarm wrote:I am also a bit curious about cologic saying "It has practial value for me" and hopefully he will answer my question about that.
Indeed.Guitarm wrote:I'm pretty sure about that there is a specific reason for having it in there. But I'll let someone else elaborate on that
I can get quite different transfer speeds from different 10Mbps ISPs. BBB, in particular, fluctuates somewhat commonly for me, so I've learned their most common (approximately 213.[110-114]) IPs so that I can discriminate against them when choosing a source. This happens with some regularity.
Further, nickfaking's trivial in DC, because it's not authenticated or from a trusted source. I've used displayed IPs to notice that the same person with two nicks was downloading from me. (Caveat: this is difficult to safely automate, for it can legitimately occur.)
Those are two practical uses for displayed IPs.
Edit: automated -> automate
yes.. let's do that. and then add an option in Advanced to disable hub-requested-show-IP-disabling ;))cue wrote:How is it not the best solution for everyone (you including) to have this as an option controlled by the hub?
cue: it's not in the clients interest to listen to the hub when the hub has no way to check if the client actually is listening or not.
http://dc.selwerd.nl/hublist.xml.bz2
http://www.b.ali.btinternet.co.uk/DCPlusPlus/index.html (TheParanoidOne's DC++ Guide)
http://www.dslreports.com/faq/dc (BSOD2600's Direct Connect FAQ)
http://www.b.ali.btinternet.co.uk/DCPlusPlus/index.html (TheParanoidOne's DC++ Guide)
http://www.dslreports.com/faq/dc (BSOD2600's Direct Connect FAQ)
You could add an option in Advanced to enable "virtual" share as well, it would be just like real share, only it would not be real, just fakeSedulus wrote:yes.. let's do that. and then add an option in Advanced to disable hub-requested-show-IP-disabling )cue wrote:How is it not the best solution for everyone (you including) to have this as an option controlled by the hub?
cue: it's not in the clients interest to listen to the hub when the hub has no way to check if the client actually is listening or not.
But you can make the client listen.
There must be a way, its possible now to prohibit the client from downloading from a hub without registering. So the client must have some comunication with the hub..?
yes.. but this can be detected.. even slot-locking clients must open a slot once in a while, either verifiable by statistics (sensitive to false positives) or by a karma (ratings) system (non-existant.. yet _possible_ to implement)cue wrote:You could add an option in Advanced to enable "virtual" share as well, it would be just like real share, only it would not be real, just fake ;)
communication yes.. but it can't be proven to be correct. the "feature" does not modify any data, it's existence/behaviour is purely local.cue wrote:But you can make the client listen.
There must be a way, its possible now to prohibit the client from downloading from a hub without registering. So the client must have some comunication with the hub..?
continuing your line of thought: if I'm talking to you over the phone, try convincing me that you have a 22" monitor on your desktop. over the communications channel that we have, you can't.
or a lamer example, which is a bit closer to the subject at hand: prove that you have green on black text in your client. you can send any color identifier to the hub. it can't possibly know you're not lying.
http://dc.selwerd.nl/hublist.xml.bz2
http://www.b.ali.btinternet.co.uk/DCPlusPlus/index.html (TheParanoidOne's DC++ Guide)
http://www.dslreports.com/faq/dc (BSOD2600's Direct Connect FAQ)
http://www.b.ali.btinternet.co.uk/DCPlusPlus/index.html (TheParanoidOne's DC++ Guide)
http://www.dslreports.com/faq/dc (BSOD2600's Direct Connect FAQ)
-
- DC++ Contributor
- Posts: 3212
- Joined: 2003-01-07 21:46
- Location: .pa.us
If this is a big enough issue that we need to talk to hubsoft authors, why is it not a big enough issue that one of them has already contacted us?cue wrote:But you are right "Shroom" there is no way for me to get the hub developers to include this. DC++ developers would have to ask them and I can see that is not about to happen.
I do believe you're generalizing your point of view and assume far more supporters than you have.
You mean like the "YOUR COMPUTER IS BROADCASTING AN IP ADDRESS, CLICK HERE FOR SECURITY INFORMATION" banner ad that was pretty popular in the past?cue wrote:You have NO reasoning for this feature you just want it in there. But if you are serious about this you would post a warning every time the program starts.
Just because you don't agree with the reason doesn't mean the reason isn't valid, or that there's no reason. Detecting nickfaking users if a very good one, as is locating users who might have fast connections.
-
- DC++ Contributor
- Posts: 3212
- Joined: 2003-01-07 21:46
- Location: .pa.us
It can't check nickfaking in Client to Client communications. Even if it checks it in one, that's not foolproof - for instance, if I were to write it, I'd not nickfake to OPs, or to users on the same subnet as OPs or the hub. Or perhaps on connections within a certain time within joining the hub.MrZ wrote:There is scripts that check nickfaking users automaticly and imo even better the humans
In short: it's a legitimate use, since no script can do what a person can.
If you tell me that you have a 22" monitor, I will believe you because I have no reason to do otherwise.Sedulus wrote:if I'm talking to you over the phone, try convincing me that you have a 22" monitor on your desktop. over the communications channel that we have, you can't.
or a lamer example, which is a bit closer to the subject at hand: prove that you have green on black text in your client. you can send any color identifier to the hub. it can't possibly know you're not lying.
But the DC++ client sends back the information, its not the user that gathers the information and tells the hub.
You are talking about PPL that would hack the DC++ client and fake that information, right...?
That is a different problem all together.
But as an idea, cant every DC++ program file carry a hash like signature that the hub could access and verify?
-
- DC++ Contributor
- Posts: 3212
- Joined: 2003-01-07 21:46
- Location: .pa.us
Wasn't this idea floated earlier in the conversation?cue wrote:But as an idea, cant every DC++ program file carry a hash like signature that the hub could access and verify?
If you did that, how do you know that DC++ is generating the hash itself, and not simply feeding a pre-calculated hash back at you? Who's to say that some faking client won't require a clean DC++ EXE to checksum?
These games are retarded.
This is a completely different discussion, and has already been discussed at length here.cue wrote:(But one question comes to mind, how does Punk Buster make sure IT'S files are not being cracked)?
So this is the conclusion of that debate?Sedulus wrote:AluminX:cheats can easily update this fast if the program is open source.http://www.shacknews.com/ja.zz?comments=17882 wrote:The whole point is that it updates itself automatically, and up to several timers per day. That's why it can work effectively. Cheats really can't update that fast, unless players trust their cheat to update itself also.
As I understand it, even if you have the source and know the way the ani-cheat works. Its still a big hassle to crack/hack/cheat the game/client.
But as I see it, there is debate if fake clients should be eliminated..?
If that's the case, I will "surender".
Perhaps. Depends on the programmer. But the point is that there are no developers involved in DC++ that would have the time to constantly change the way this verification works, as soon as it's cracked. There is also the tiny matter of making all hubsofts upgrade to support this feature. But if you can pull it off and make it happen, i'm all for it.cue wrote:As I understand it, even if you have the source and know the way the ani-cheat works. Its still a big hassle to crack/hack/cheat the game/client.
"Todi" argued that this discussion was getting out of its subject. So lets sum-up.
1. "Asc3nti0n" started the debate asking that a new feature with DC++ 4 would be removed. The IP colum.
2. Others argue that the IP colum should be there as a education, to pick the fastest IP as source, to guard against nick-faking of sort and because it's so easy to see the IP anyway.
3. Could hubs not have the power to disable the new IP colum feature, as a solution for both?
4. No because of (see no 2). And It's imposable to implement because the hub can't verify that you are not using a fake client.
5.Cant a Punk Buster clone verify that you dont have a fake?
6. No because.... To be edited
I think its still within its original intention of disabling the IP colum, if DC++ can be verified as not fake, it can be trusted to send back the correct information.
1. "Asc3nti0n" started the debate asking that a new feature with DC++ 4 would be removed. The IP colum.
2. Others argue that the IP colum should be there as a education, to pick the fastest IP as source, to guard against nick-faking of sort and because it's so easy to see the IP anyway.
3. Could hubs not have the power to disable the new IP colum feature, as a solution for both?
4. No because of (see no 2). And It's imposable to implement because the hub can't verify that you are not using a fake client.
5.Cant a Punk Buster clone verify that you dont have a fake?
6. No because.... To be edited
I think its still within its original intention of disabling the IP colum, if DC++ can be verified as not fake, it can be trusted to send back the correct information.
Good, you are welcome to provide a patch.cue wrote:I think its still within its original intention of disabling the IP colum, if DC++ can be verified as not fake, it can be trusted to send back the correct information.
"Nothing really happens fast. Everything happens at such a rate that by the time it happens, it all seems normal."
Correct me if I'm wrong but DC++ is opensource so that people can modify it?
Now you're trying to say we should add a feature to stop people modding clients?
am I the only one to think this is crazy?
Not to mention the amount of work you're asking to be put in to 'hide' a users ip when its not exactly hard to get them anyway.
What are they gonna do with your ip anyway, worst i see happening is being added to a firewall to block you downloading.
Now you're trying to say we should add a feature to stop people modding clients?
am I the only one to think this is crazy?
Not to mention the amount of work you're asking to be put in to 'hide' a users ip when its not exactly hard to get them anyway.
What are they gonna do with your ip anyway, worst i see happening is being added to a firewall to block you downloading.