Allow excluding hubs with hidden share from hub counts

[maksis]

The client could allow excluding hubs with no share from the hub counts shown in sharing hub. This would lessen the need to run multiple clients, and those hubs supposedly aren't relevant in sharing hubs. The client could still display the total hub count in hubs with no share. Also the option to disconnect non-reg hubs could be changed to hide the share in non-reg hubs instead.

[Sopor (sopor)]

"disconnect non-reg hubs " should stay. Users will never understand how this will works when Airdc don't have any help text to show for the options.

[Night (night.)]

Excluding hubs with hidden share from hubcounts could help in my case, I have a lot of chat only hubs.

[Janne (barajag)]

this is bad that users can be in a public hub and we cant see that..

[Janne (barajag)]

Excluding hubs with hidden share from hubcounts could help in my case, I have a lot of chat only hubs.
But if you use that you can use public hubs and i think thats a big problem..

[maksis (maksis)]

I'm not sure that what do you mean. I'd say that this change mostly helps users who are currently running separate chat clients to overcome total hub count limits. You've never been able to know whether the user is in a public hub or not because there's no way to determine that from the tag.

If you want to know if your users are staying in public hubs, I recommend setting up remote monitoring, monitoring all their network traffic and performing random home searches where you go through everything they have. Even then they might be able to log in to public hubs without you knowing from it. Not to mention cases where people are chatting/sharing files by using other applications... or in real life (in public).

[maksis (maksis)]

I also heard this tip from a dangerous user, which can used to fool hub owners without even running a second client:

If you join to a public hub, you are most likely to register yourself. Usually the command is +regme <password> or similar (use the help command to get the correct command or use the right-click menu if available). After that you can join the hub with your registered account and all hub owners would happily consider that hub as a private hub.

[maksis (maksis)]

Meanwhile: another user is running a hub in his local network and joins that hub without having a registered account. Hub owners consider that hub as a public hub and the user becomes a serious security threat and must thus be banned forever.

Here's a good explanation of various tag fields (hub counts included) that is useful especially for hub owners: http://www.dslreports.com/faq/6529

[Janne (barajag)]

what i mean is that im in a reg hub but if i use that Excluding hubs with hidden share from hubcounts. if i add a public hubs in favorites and connect i dont see the public hub. and the script for public hub dont work so the user can be in my reghub and in 1 public at the same time.

[maksis (maksis)]

Have you tried the registration tip I mentioned in comment #6? It should work with any client and your script doesn't see anything. Or have you tried using a second client that your script can't see either? These tips should probably be posted on the forum so that people would be better aware of them. I'd also be curious to know more about the security threats caused by users chatting in public.

Something that reminds me of this: http://bits.blogs.nytimes.com/2007/08/02/the-weird-psychology-of-security/

[Janne (barajag)]

how many users do you think use that? i have 2 clients now for test but many hubs you dont need to reg to enter so this is a problem. just try public hus from the client and you can enter many whitout to reg.all owners i have talkt to about this change dont like it at all.

[zfr (locoz2)]

Being a good listener, me :)

To make a constructive opinion here, whyu dont you just add a line to the TAG, instead of removing?
Add a line, so 4 instead of 3, with the new one for 0 share.

[zfr (locoz2)]

All though, the tag for Public (i.e unregged hubs) should allways rule over the 0 Share ("chat-client").

[maksis (maksis)]

The optimal way to report the hubs would probably be to just split them to "share visible" / "share hidden" because the current classification seems to be way too difficult for users and hub owners to understand correctly (even you are referring to "public hubs" in the tag). Compatibility-wise it's hard to make such changes at this point though.

ps. try joining to hiphopclub.no-ip.org:666 that can be found from a public hublist and see what's being added to your tag

[atlant1s (giddygiddy)]

While I agree, it'd be better to reflect the true hubcount _including_ 0-share/chat-only profiles in the tag, I still don't get why this feature was considered to be a good idea..

Only to get rid of a second, chat-only client, because it's more convenient?

I always thought the few users who needed this (devs, maybe ops) were using 0-share clients for a reason, for example, their own security. To freely chat and roam in many hubs without any strings attached?

With this feature introduced, anyone can safely interpret a 0-share 3.2 client will most likely have a share hidden as well! Something you couldn't as easily before.

Also, convenience goes both ways, even if the true hubcount is shown: ops might simply ban users/clients with too many connected hubs. Regardless if they share only in e.g. two hubs.

Before, users who used two clients to be in regged AND public hubs were mostly aware it wasn't allowed in reg hubs and suffered the consequences when discovered. They ignored any or all of the rules of the reg hubs.

This feature would take those consequences away. But those consequences are there for a reason.

[maksis (maksis)]

The fact that many hub owners really seem to consider people discussing in public as security threats is really worrying to me, especially since no one wants to explain the reasons behind such thinking. The client shouldn't be developed based on ambiguous claims.

[edup (edup)]

I've been following this discussion and there is miscommunication/misunderstanding both ways.

The question to answer: "the security threats caused by users chatting in public."
More specifically: in relation to this change.

Hub owners can still detect public (as in unregistered) hubs. If one registers to a public hub, hub owners still won't be able to detect it. A no share profile would be similar to this case, although not quite the same. Users on private hubs are more likely to visit a chat only hub with no share than a public hub with sharing.

* https://en.wikipedia.org/wiki/Information_leakage
If you are in a public (chat) hub, the tag is publicly visible. It shows on how many registered hubs you are and the hubs you administer. This is an ideal starting point for law enforcement. It gives an idea of what kind of user you are. Probably enough as probable cause to start monitoring. Even if it's not detrimental to the user, it helps in pointing to some wanted locations.
From private hubs it can't be detected anymore. Using a separate client isn't as high a risk, but still the same.
=> Can be worked around by faking the tag to ALL no-share hubs (registered and unregistered and op). Behavior stays the same.

* https://en.wikipedia.org/wiki/Honeypot_(computing)
On a no-share hub you don't share, even not partial sharing. I think this is correct in the commit? https://github.com/airdcpp/airgit/commit/7771a7ae914efc9b078a1e3bdf2ddf439e0ab577
On the other hand, can you stop users from downloading from (public) no-share hubs?
How far can your download behavior be monitored on the public hub?
Users have already been caught downloading using a honey-pot. If they raid your home, they can find a Favorites.xml with all the passwords in plain text. This is a security issue for private hubs too, not just that user.
=> no searches and no downloads from no share hubs are a must to be the same as 2 clients

* Public chat hubs
On IRC they use bouncers, not only to stay connected all the time, but also to conceal the real ip address (if the network does't do that for you). One has to set up a proxy to get the same effect? Public chat hubs with your IP visible are a security issue.
=> It doesn't change the matter at hand. It's just easier to be as no-share on a hub, without hub count consequences, given the previous issues are handled and there isn't any other information leakage.
=> Anything you do outside the client, hub-owners can't check either and can be equally harmful.

[maksis (maksis)]

Yeah, there are some points that need to be addressed and the feature won't be released in its current state.