DHT banned in hubs

[Skasowitz 0]

I browsed back through older posts and this question has come up before, but generally seems to be resolved another way.

1.3.5 has been added to the banned client list on a local hub, I believe because of DHT being on by default. Hub admins are requesting all Windows users to use 1.3.4, but doing so brings up the automated version check and shuts down the client. I have been unable to find anything in the settings to disable the check, and was wondering if this is a way around this. I am hoping that the hub will change its stance on the new version, but is there anything I can do as a temporary workaround to continue using version 1.3.4?

Thank you

[Crise 26]

I browsed back through older posts and this question has come up before, but generally seems to be resolved another way.

1.3.5 has been added to the banned client list on a local hub, I believe because of DHT being on by default. Hub admins are requesting all Windows users to use 1.3.4, but doing so brings up the automated version check and shuts down the client. I have been unable to find anything in the settings to disable the check, and was wondering if this is a way around this. I am hoping that the hub will change its stance on the new version, but is there anything I can do as a temporary workaround to continue using version 1.3.4?

Thank you

Tell your hub owner to do his homework, DHT can still be disabled... and the instructions are linked to in more than one place here. Also hub owners have the possibility to filter clients strictly base on whether DHT is enabled or not (through SUP/Supports) rather than version number.

That is all I have to say on this subject .

[Lee 84]

Point your hub owner to this topic, and tell him to reply with his stance if need be. DHT can be detected when a user enters their hub and they can block the user from entering with a clear message as to why. For example:

"You have been disconnected because we have detected the DHT global network is running. We do not allow this in our private hub for user's security. Please disable this by going to Settings > Advanced > "Publish shared files on DHT" and reconnect."

If your hub owner continues to block all future versions of ApexDC++, users are open to a lack of compatibility and future development opportunities.

[Guest Toast]

Too the user that started this pointless thread is it worth blocking new clients and having security vulnerabilities over one lousy feature aint it better to set up a simple checking system to see if DHT is enabled instead

Think about that before you comeback and reply to me

[Lee 84]

Too the user that started this pointless thread is it worth blocking new clients and having security vulnerabilities over one lousy feature aint it better to set up a simple checking system to see if DHT is enabled instead

Think about that before you comeback and reply to me

The guy has no authority to block or unblock new clients. His hub operator should come and continue this discussion so everyone is happy

This topic is not pointless, because we are trying to suggest setting up a system to check DHT .

[Beowulf 0]

The guy has no authority to block or unblock new clients. His hub operator should come and continue this discussion so everyone is happy

This topic is not pointless, because we are trying to suggest setting up a system to check DHT .

Speaking quickly as an owner. I am amused because I used much the same language in my message that skasowitz referred to but I doubt he's one of mine.

Apex has been our preferred client of choice, espoused by our operators and made reference to in our MOTD for at least two plus years now and it was with a fair amount of annoyance that I placed the block across the board on 1.3.5. The addition of DHT being enabled by default causes issues -- DHT is innately threatening for our users' circumstances due to bandwidth restrictions (namely any connections that are outside of our intranet). Our userbase is typically a constant 1k, peaking at 1400 and we serve probably at least 8-10k people over the typical course of our functional year. Summer is our downtime. Apex saturation on the hub is probably 50% of currently connected clients at any time.

And because not everyone is technically able (regme eludes 40+% of these people) I can't expect them all to be able to understand what DHT is or how to turn it off. And yes, I am well aware of how easy it is. I still attempt to provide the service to these users however. And in this case it meant playing down to the most common denominator here, where they either won't bother or won't understand what we're attempting to tell them to do when it comes to disabling the option.

If 1.3.4 was a stable hold I was more than comfortable having 1.3.5 blocked across the board and skip the problem entirely. It was a quick fix to block the version while I'm away for a time before I could setup handling the support route.

More than likely with 1.3.4 being shoved off, it'll mean that the technically-able people will use 1.3.5 (~40-50 users) and turn off DHT on their own/with direction but we'll most likely have the others (the typical 800+) swap to DC .770 instead.

[YouKnowWho 0]

I think this is a big boo-boo on Apex' side. New features are always welcome, but it's not up to you to decide to enable DHT and thus compromise all private hubs. Apex is used by many as an out-of-the-box solution, and those kinds of users are intimidated by the host of features that can be changed. So they follow some basic guide they find on the internet and stay well away from the rest, not being aware what DHT is doing.

You're not doing yourselves any favors here with your elitist attitude of pushing new behavior, the only thing that will happen is what happened to that version of utorrent a few years back that had DHT enabled by default: It got banned on ALL private trackers.

So I urge you to reconsider and push out an emergency update which either disables DHT by default or gives the user a CLEAR WARNING on what the client is about to do before they decide to update.

Thanks.

[Mek 13]

I don't know if it relates but before I upgraded today, DHT was off (with UseDHT tag in DcPlusPlus.xml set to 0). However, after upgrading, DHT was back on so I had to turn it off again. Why was the xml file setting ignored?...

[Lee 84]

When uTorrent came with DHT enabled, private trackers banned it yes. Pretty soon after they made sure that all torrents on private trackers had DHT disabled with a method in place to determine this.

We aren't being "elitist". We are sending this information to the hub. A clear message of how to disable this feature is all that is needed. If your users decide not to follow these simple instructions, maybe they feel the hub they are connecting to isn't worth the effort?

I think we need more input from you hub owners in our development, rather than once a version is pushed. Maybe we can work something out with that.

Mek: It was reset after upgrading to 1.3.5.

[Beowulf 0]

We are sending this information to the hub. A clear message of how to disable this feature is all that is needed.

You're sending the information to the hub, and now the hub gets to decide how we're going to handle it, just like everything else. And in the end this change meant (for on my end) having to add on another something to have to handle or explain to people, many of them fresh or new to the whole concept of DC every year.

DHT is simply not a viable option in any way for us.

/Even if it is simple, these are users which can get discouraged or confused very easily./

And Lee:

If your users decide not to follow these simple instructions, maybe they feel the hub they are connecting to isn't worth the effort?

This has nothing to do with the 'Holy Grail' awaiting them at the end of their journey, else I wouldn't find emails about it each week with people having problems connecting and attempting to walk them through the process or what could be wrong.

No. On my end, it means that the client isn't worth the effort. It means I'll run it because it's useful to me but the client is not useful to others in the same way when all they care about is getting that file in a way that is relatively safe and secure. The client is something that I enjoy having so we have a standardized process when it comes to walking people through things or that I know that there is this feature available and can point to it.

Users should opt in to putting themselves on this DHT or at the very least be very clearly informed what is going on with this one, as I had three people separately send me messages asking why people in Romania were touching their files and none of us had any idea why until I looked through the changelog myself and balked.

I...

I guess I'm just at a loss for words where this feature became an assumed 'this should be enabled by default' when it seems to be an option that should be a conscious decision to want to run with DHT.

It simply means we'll swap out clients en masse when it comes to an out of the box solution and Apex won't be it anymore.

[Mek 13]

Beowulf, this DHT setting isn't the only one to discourage new users. There are plenty of settings which, when misconfigured, make things not working. People then ask on main chat and you have to walk them through the settings to correct everything. This is the reason we on our campus network are suggesting a preconfigured version of Apex (with everything preset, including the language and theme). The user just has to set up his nick, add files to share and connect to the only preconfigured favorite hub. It's easy and I would recommend doing it this way as well. ;)

[Beowulf 0]

Beowulf, this DHT setting isn't the only one to discourage new users. There are plenty of settings which, when misconfigured, make things not working. People then ask on main chat and you have to walk them through the settings to correct everything. This is the reason we on our campus network are suggesting a preconfigured version of Apex (with everything preset, including the language and theme). The user just has to set up his nick, add files to share and connect to the only preconfigured favorite hub. It's easy and I would recommend doing it this way as well.

Hah, agreed, but most users don't touch the other settings anyway. One of my Ops is messing with the setup now to possibly do that. I'm still meh on it because I don't enjoy the concept of anyone hosting one of those on our available hardware where anyone can get it and see the address if the link proliferates. The IP range bans we function on are fun enough, but still, I don't like to broadcast and I know how that stuff travels.

The first rule of private hub is you don't talk about private hub, naturally.

The second rule of private hub is MAKING SURE THE FIRST ONE ACTUALLY IS FOLLOWED.

The 1.3.5 overwrite (of the .xml settings) also bothers me because if there's another update where DHT is enabled again (or rather, each update enables it again, so on and so forth) it means there'll be a lag between our release and the dev release each time, which is even more time sunk.

[YouKnowWho 0]

<br />When uTorrent came with DHT enabled, private trackers banned it yes. Pretty soon after they made sure that all torrents on private trackers had DHT disabled with a method in place to determine this.<br />

You forgot to mention that afterwards utorrent had DHT always disabled by default as well. I agree that DHT needs to be able to be blocked at hub level as well, preferable directly in the hub soft together with the "private hub" option. Knowing some of the hubsoft programmers I don't get my hopes up yet.

This is a two-way street. DHT is good, when people know what they're doing. Since more often than not they don't, we need to work together on this, please.

[Big Muscle 1]

It's absolutely stupid to block DHT via hub. Why should this happen? Any real reasons? DHT is just another hub where user is connected to, should hubs block another hubs too?

One opinion is that it can break user privacy. But question is "How?". When user doesn't want it, he can disable it. But when user wants it and leaves it enabled, it's only his right. Hub has absolutely no rights to decide what user enables unless it is some thing which can influence other users in hub or hub itself (e.g. fake features, too much segments per file etc.) But how DHT influences hub or other users? In no way. It's just ******** of admins/hubowners which prefer virused, trojaned or just exploitable clients in their hubs before having DHT enabled.

[ArnoldLayne 0]

Hi. My first post here, I'm sorry it has to be a negative one because in general I'm very grateful for all your efforts to keep ApexDC++ in shape.

DHT is a security issue for private hubs, period. We can take for granted that many users just accepted the forced update and then went on to share files they thought still were confidential. DHT enabled by default is IMO quite similar to Microsoft's intentions to do the thinking that users should be doing. No offence, my critics is meant to be constructive, but it has to be said that respect for privacy is plain and simple "savoir être" in Internet.

Cheers,

AL

[Big Muscle 1]

DHT is a security issue for private hubs, period.

How is the security broken?

[ArnoldLayne 0]

How is the security broken?

I already gave an example of that. Just imagine some files are shared that contains information that can be used to identify hub participants. A private hub is by definition a place where stuff is shared among a limited group of people. And DHT by definition makes the private material non-private.

[Lee 84]

Renamed topic title appropriately.

I already gave an example of that. Just imagine some files are shared that contains information that can be used to identify hub participants. A private hub is by definition a place where stuff is shared among a limited group of people. And DHT by definition makes the private material non-private.

Agreed. So make sure you detect that DHT is enabled and disconnect those users.

You are banning everybody on 1.3.5 because they *could* be running DHT. No need to ban specific versions, detect and ban the use of the feature.

Beowulf: There is no need to stop using ApexDC++. The two solutions you have are to either supply a message to the user on entry, or configure your own client that will be constantly out of sync with development. DHT setting will not be reset again in terms of users upgrading from previous versions. Once a user has disabled DHT, it will never again be enabled without the user's permission.

How about moving the option of enabling and disabling DHT into the Sharing settings page? This seems more appropriate than buried in advanced. Big Muscle, what do you think? I'd prefer being able to right click on the DHT status bar like in utorrent and enabling/disabling on the fly though. You managed to take a look at that?

[ArnoldLayne 0]

...

Agreed. So make sure you detect that DHT is enabled and disconnect those users.

You are banning everybody on 1.3.5 because they *could* be running DHT. No need to ban specific versions, detect and ban the use of the feature.

...

Oh, I'm not at all opposed to resolve it at hub configuration level. It would IMO be necessary to consider it anyway, whether DHT was activated by default or not in ApexD++. So maybe after all the fuzz created has been good in the sense that it's bringing hub admins' attention to DHT. Still, they're learning it the hard way and suffering a potential privacy threat meanwhile.

[Big Muscle 1]

I already gave an example of that. Just imagine some files are shared that contains information that can be used to identify hub participants. A private hub is by definition a place where stuff is shared among a limited group of people. And DHT by definition makes the private material non-private.

But it's the user who breaks privacy and not DHT. It's user who shares such private material and same problem can appear when he is connected to another hub. It's not limited to DHT only.

Lee: DHT is just experimental option, so it is in Advanced settings. When it is maximally optimized and all bugs are fixed than it will be moved to some other page - sharing or upload page. I was also thinking about putting it into Favorite hubs (as non-deletable item) where user could connect/disconnect or select auto-connect (by (un)checking the checkbox).

[Lee 84]

But it's the user who breaks privacy and not DHT. It's user who shares such private material and same problem can appear when he is connected to another hub. It's not limited to DHT only.

Lee: DHT is just experimental option, so it is in Advanced settings. When it is maximally optimized and all bugs are fixed than it will be moved to some other page - sharing or upload page. I was also thinking about putting it into Favorite hubs (as non-deletable item) where user could connect/disconnect or select auto-connect (by (un)checking the checkbox).

How do you mean, so that it could be disabled on a per hub basis?

Agreed about experimental, but because it's such an important feature it still should be moved from Advanced and easily accessible.

[Crise 26]

How do you mean, so that it could be disabled on a per hub basis?

Nope he means to have it as an entry in the favorite list.

[Beowulf 0]

If the DHT setting isn't going to be touched from here forward after being disabled once from 1.3.5 onward, then we'll simply package a version of Apex that runs with it disabled by default and use that instead of linking to the official distro.

The only reason this is an 'issue' is that I'm attempting to protect people from themselves when we're using the client.

[Crise 26]

The only reason this is an 'issue' is that I'm attempting to protect people from themselves when we're using the client.

This may come off as blunt, but do you intend to protect them from actually learning something new as well, if they can't disable an option in settings I truly feel sorry for them.

Also about distributing pre-configured versions, if you do it by shipping it with XML files you better be careful about doing it right... if you actually intend to recompile then that won't be a problem.

[mappy 1]

We run a large campus LAN hub, and having DHT enabled by default will cause the general users to use their limited bandwidth.

We'll probably employ something similar to this script to block DHT-connected users in the hubsoft.