Reporting Clients

Archived discussion about features (predating the use of Bugzilla as a bug and feature tracker)

Moderator: Moderators

Locked
Henrik
Posts: 21
Joined: 2003-01-03 20:07

Reporting Clients

Post by Henrik » 2003-04-20 12:57

Today fakeshare is a growing problem.

More and more users choose to cheat the community on share. With an attitude that is far away from the thought that made dc what it is today, share share share. This problem is very time consuming for ops (to go thru every share) to discover these. I know ops are trying there best to keep scum like fake sharers away from hubs. But it would be a nice feature to have clients report if the amount that is shown after you download some ones file list is not the same as is reported in $myinfo string. This little function should just send a msg to the hub like “$wrongshare username� and then just have a bot in the hub who picks out these small infos that are sent to the hub and broadcast it to the ops or something like it.

I would love a feature like this.

//Extasy

Moch
Posts: 71
Joined: 2003-03-21 22:29

Post by Moch » 2003-04-20 13:04

A feature like this wouldn't help.

If I was to fake share and this feature was implemented, I would quickly create my own share file list that reported the correct amount of data shared. *shrug* That isn't to hard to do.

Also, I don't think it would be a good idea to implement this on the clients end. You could have a bot that did this for you.

~Moch

Henrik
Posts: 21
Joined: 2003-01-03 20:07

Why not have it in end client?

Post by Henrik » 2003-04-20 13:22

I think it would be the wises choice to have it in the client, A boot that would go around connecting to each user would take another computer from the hub owner and this feature would be easy to implement due to that the function already is present. This could help a lot keeping dc clean. There will always be those who get by this with different methods. But it will remove some and I think most!

Sedulus
Forum Moderator
Posts: 687
Joined: 2003-01-04 09:32
Contact:

Post by Sedulus » 2003-04-20 14:04

another computer from the hubowner?
ts.. yeah.. so? there are plenty OPs that have a spare computer

tried ragnarök? see the Other Tools forum
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)

Moch
Posts: 71
Joined: 2003-03-21 22:29

Post by Moch » 2003-04-20 17:09

Also, you wouldn't need an extra computer.. there wouldn't be a problem running the bot from the same computer. As stated in a diffrent thread.. hubs can look after themselves. Clients shouldn't be relied on to inforce such rules.. Why? Because, clients are easily modified to cheat, especially with the feature you propose. A client can not be trusted. The only software that can be trusted as a hub owner is under your own control, IE: The hub. (and that is only if you understand the source and any modifications made to that software).

~Moch

volkris
Posts: 121
Joined: 2003-02-02 18:07
Contact:

Post by volkris » 2003-04-20 17:33

Moch wrote:A client can not be trusted. The only software that can be trusted as a hub owner is under your own control, IE: The hub. (and that is only if you understand the source and any modifications made to that software).
Actually......

A client cannot be trusted to turn itself in, but it can be trusted to turn others in. The worry becomes not one of people not being reported, but one of people being reported falsely. Even this isn't that big of a problem, though, because people who report falsely can be quickly kicked.

Well then there's an extra problem that cheaters might seek to stop tattling by tricking others into reporting them then showing up properly when the ops check, making a false report seem to have occurred.

But anyway, don't dismiss this idea out of hand. I actually think it has some merit. Allowing clients to report to ops when an inconsistency is found in the system is not a bad thing.

Moch
Posts: 71
Joined: 2003-03-21 22:29

Post by Moch » 2003-04-20 17:52

No, Clients cant be trusted. You are asumming that people would naturally want to report others. Trusting a client is like trusting another human being to be honest.

There is more to faking then not having any files, but faking the share size just by submitting a bad share size. This feature wouldn't even address the people that "fake" by sharing files without read permissions, or people that are pushing out bad data (random data, or poetry, or nulls, or whatever) when a file is being downloaded from them.

It seems like a feature that just adds bloat. It won't solve the problem, so why even add it. Even if the majority of the clients supported this 'feature' it would just cause the people that are doing the faking to use more sophisticated methods like I just mention. If I had the choice.. I rather a file not be found than have to download files just to find out that it is garbage. In my opinion (and yes, I acknowledge it could be wrong) if this was a wide spread feature it would encourage the growth of bad data on the DC network. That isn't something to encourage. Ask yourself, what is the lesser of the two evils?

I am glad there is some attempt to stop fakers, but to implement something that won't stop them in the slgihtest is just dumb. Until hashes are supported I don't think what is proposed here would work very well. Perhaps more along the lines when hashing is implemented than this feature applied to when someone is actually downloading a file and continuly gets bad hashes from the data being downloaded (or no file found) from a user then it could be reported to the hub. That seems to be a more reliable way of spotting more fakers. Again this is all asumming that we can trust clients to report the right people.. which, I don't feel we could.

;) So I didn't imeaditly discredit it, but I really don't think the mentioned application would help at all.

~Moch

cologic
Programmer
Posts: 337
Joined: 2003-01-06 13:32
Contact:

Post by cologic » 2003-04-20 17:59

No, Clients cant be trusted. You are asumming that people would naturally want to report others. Trusting a client is like trusting another human being to be honest.
Huh? Yeah, clients can't be trusted to act kindly towards other clients competing for slots; if provided a way to say "look, evil client here. Kick him!" many will attempt to take advantage of it.

volkris
Posts: 121
Joined: 2003-02-02 18:07
Contact:

Post by volkris » 2003-04-20 23:31

Moch wrote:No, Clients cant be trusted. You are asumming that people would naturally want to report others. Trusting a client is like trusting another human being to be honest.
But they would naturally want to report others.
Here you have a situation where someone is basically ripping someone else off, and you're proposing that the victim wouldn't want to report the perp. Basically, this situation is one where it costs the reporter nothing but does him some potential good. Therefore he will naturally want to report the other.
There is more to faking then not having any files, but faking the share size just by submitting a bad share size. This feature wouldn't even address the people that "fake"[...]
Right. The feature doesn't go very far, but it would do what it seeks to do: report people who jump the system specifically by submitting bad share sizes.

But you know what? There's more to this feature than just what was stated. It can be used to do a variety of things that simply protect the integrity of the system. By abstracting it to the point where it can watch for general inconsistencies it can watch not only for people who report one thing and show different, but watch for duplicate IP addresses, and a ton of other things I can't even think of right now. Not all of these things will be intentional abuse, either.

Moch
Posts: 71
Joined: 2003-03-21 22:29

Post by Moch » 2003-04-21 13:01

volkris wrote: But you know what? There's more to this feature than just what was stated. It can be used to do a variety of things that simply protect the integrity of the system. By abstracting it to the point where it can watch for general inconsistencies it can watch not only for people who report one thing and show different, but watch for duplicate IP addresses, and a ton of other things I can't even think of right now. Not all of these things will be intentional abuse, either.
We get back to the point that the Hub should take care of itself. It already has the best ability to detect bots and multiple IP connects. The only thing the hub doesn't know about is the actual data being transmitted P2P between users. So, that means the hub knows everything else, and the hub should protect itself when it comes to everything else. I still think this reporting feature would A. cause major trafic on the hub, thus limiting the amount of users a hub can have online even further. B. Abused. My Biggest concerned is that people will falsly make their clients report people. Actually on top of that.. what if there is some kind of network split, and users in the US can't communicate with users in Norway? Then all the US people will be reporting norway users because they can never connect to them and vice versa. The hub would be flooded with inaccurate information.

*L* Thanks for the discussion!
~Moch

volkris
Posts: 121
Joined: 2003-02-02 18:07
Contact:

Post by volkris » 2003-04-21 16:33

Moch wrote: We get back to the point that the Hub should take care of itself. It already has the best ability to detect bots and multiple IP connects. The only thing the hub doesn't know about is the actual data being transmitted P2P between users. So, that means the hub knows everything else, and the hub should protect itself when it comes to everything else. I still think this reporting feature would A. cause major trafic on the hub, thus limiting the amount of users a hub can have online even further.
Actually the hubs currently don't have the ability to look for these things and implementation of such ability would cost enormously in bandwidth. The users are stumbling across this information anyway, though, and this suggestion would simply make use of information already being discovered.

It is the hub's responsibility to protect itself, but that doesn't mean it can never be helped. Furthermore, it's the hub server's responsibility to protect itself, but the hub group has the same responsibility.

Moch
Posts: 71
Joined: 2003-03-21 22:29

Post by Moch » 2003-04-21 20:42

volkris wrote:
Actually the hubs currently don't have the ability to look for these things and implementation of such ability would cost enormously in bandwidth. The users are stumbling across this information anyway, though, and this suggestion would simply make use of information already being discovered.
The "other things" which you mentioned earlier:
volkris wrote:By abstracting it to the point where it can watch for general inconsistencies it can watch not only for people who report one thing and show different, but watch for duplicate IP addresses, and a ton of other things I can't even think of right now.
So.. the one other thing you mentioned was watching for duplicate IP's this is really easy to check. Perhaps you mean there isn't a simple function or variable to get this with scripts, but it is really easy to check for because the IP associated to each user has to be associated already in the hub software. This wouldn't take up any extra bandwidth... and the "ton of other things" you can't think of right now, cant really be used as example, till.. they are thought of ;) I don't see there being any more bandwidth usage if the hub checks for things on its own that doesn't have to deal with transfers of files amoung the clients. Why? Because the hub already gets all the data and relays all the searches and gets the $MyINFo of everyone.. etc etc.. So all it would have to do is keep its own stats and determine if anyone is abusing the system dealing with search abuse, login abuse, pm abuse, chat abuse.. (things of that nature). I wouldn't worry about it taking extra bandwidth, it won't. It would take a little more cpu time and memory. However, if the hub software is of quality programming than it would not be as taxing as one would think.

So. Hubs are very capable of taking care of themselves, if they are programmed to look at the data ALREADY available to them. The issues that a hub can't really protect against automatically is fake shares, corrupted file transfers, verification of slots open, and bogus Acitve search results. The way the protocol definition is, those things would have to have some kinda of external check (bots or client reporting).

Just to make it sound like everything needs to be abstracted to client reported THAT would cause alot of extra bandwidth (clients reporting to the hub for everything it 'suspects' is wrong). I think a well made bot could keep log files for the hub owner to look at and would be more reliable and accurate and expandable than every client having some general rules on what to report on.

~Moch

volkris
Posts: 121
Joined: 2003-02-02 18:07
Contact:

Post by volkris » 2003-04-21 22:21

Moch wrote:This wouldn't take up any extra bandwidth... and the "ton of other things" you can't think of right now, cant really be used as example, till.. they are thought of ;)
Ahh, but there you're wrong.
The clients could easily be smart enough to alert ops when they notice inconsistencies that they weren't specifically told to look for. Computers do such things all the time. Just because a human hasn't forseen a certain way in which the consistency of the network can be harmed doesn't mean a computer can't catch it.
I don't see there being any more bandwidth usage if the hub checks for things on its own that doesn't have to deal with transfers of files amoung the clients.
The hub is (hopefully) not going to be downloading everyones' file lists, downloading files, and interacting with the system in the way of a normal client. That a client can potentially find blips in the system through its normal activity is how it would save a ton of resources.
So. Hubs are very capable of taking care of themselves, if they are programmed to look at the data ALREADY available to them.
But hubs rarely have ANY data available to them that actually realistically suggest potential faults in the system.
The issues that a hub can't really protect against automatically is fake shares, corrupted file transfers, verification of slots open, and bogus Acitve search results.
And these are examples of things that a client could report about.

Locked