Requesting hub filtering of client traffic
Posted: 15 Aug 2012, 18:01
The recent user commands and CDM issue; hubs forward a B-type CMD message. In a hub that doesn't know about UCMD, it rightly forwards the messages. In a hub that does know about UCMD, but doesn't filter, are more troublesome. But it doesn't actually boil down to a hub problem, since, again, the clients might just have something new going on. (And I can admit that it may have been a premature assumption in saying that there's a massive security hole, especially for the hubs).
I thought about the potential commands that are of this nature and I could only really think of UCMD, but this is a general problem; clients send stuff that the hub forwards to others, potentially using memory or CPU on the receiver. Also, while there is a (tehnical) way for the client to decide "hm, that's a B-type CMD, I should just ignore that since that came from a user", the client _should not_ all according to the rule about where the information is parsed; the type shall only be used for message parsing.
If we apply a different solution though; we ask the hub to filter stuff we want or don't want. Think of this; you say to the hub "I am not interested in B-type CMD", so the hub doesn't forward it to you. The hub will possibly eat some memory, but might actually be able to save on bandwidth since some (all?) clients might not want a particular type of message. Say, you would "naturally" not send searches or CTMs to a client that doesn't share anything. There's multiple ways we could implement this and I haven't thought it through yet.
In fact, not only could we restrict things to types, we could restrict things to commands or even parameters. ("I don't care about the PM flag" or "I don't want MSGs", but not using AW2 in INF.)
I haven't thought this through much, but I thought a discussion would be in order.
I thought about the potential commands that are of this nature and I could only really think of UCMD, but this is a general problem; clients send stuff that the hub forwards to others, potentially using memory or CPU on the receiver. Also, while there is a (tehnical) way for the client to decide "hm, that's a B-type CMD, I should just ignore that since that came from a user", the client _should not_ all according to the rule about where the information is parsed; the type shall only be used for message parsing.
If we apply a different solution though; we ask the hub to filter stuff we want or don't want. Think of this; you say to the hub "I am not interested in B-type CMD", so the hub doesn't forward it to you. The hub will possibly eat some memory, but might actually be able to save on bandwidth since some (all?) clients might not want a particular type of message. Say, you would "naturally" not send searches or CTMs to a client that doesn't share anything. There's multiple ways we could implement this and I haven't thought it through yet.
In fact, not only could we restrict things to types, we could restrict things to commands or even parameters. ("I don't care about the PM flag" or "I don't want MSGs", but not using AW2 in INF.)
I haven't thought this through much, but I thought a discussion would be in order.