[Dxspider-support] List of nodes that should be unlocked

Wed Feb 22 12:32:54 GMT 2023

Hello Dirk,
First of all, thank you for all your work, surely all of us know how 
many things muste be done and how many hours have you spent on these 
matters. I believe that the only way we have to really thank you is 
implementing all the new features you have given to us.

Thanks of course to Kin too for his work. We both have also spent a lot 
of time discussing about the dx-cluster network and all its present and 
past problems.

Managing a so old and decentralized system as this, implies that there 
are a lot of things to do in order to make it better.

So, we have -generally speaking- this scenery for our "enterprise" (I'm 
sure you will understand me):

1.- Our "product" is spots.

2.- Our "clients" are nowadays:
- Dxers
- Contesters
- Award followers (SOTA, POTA, GMA, etc.)
- "Normal" ham radio ops. ;-)

3.- Our data sources are:
- "Human spots". They cover all bands & modes
- Automatic spots: They also cover all bands, but not "phone" modes 
(SSB,FM,AM,...)

4.- Our business:
Give to our "clients" the best possible data (this means not only 
quantity but quality as well)

5.- Our "personnel":
- Cluster Software developers
- Sysops
- 3rd part soft developers

6.- Our main problems are currently (I'm am not judging, just 
enumerating them):

- The source of all our *legitime* data is radio transmissions. They can 
be faked and no human or rbn spotter will be able to filter them.

- The soft developers are few. They work for free (or almost) and their 
time is limited. They work tied to an outdated transmission system, and 
also old protocols.

- Forgive me for this, but having a lot of nodes of any system and/or a 
lot of users in our nodes it is not at all a measure of neither success 
nor quality of the "product".

- Today, some of the software being used is not maintained any more 
(several reasons), but some nodes keep them running. New measures cannot 
be implemented on them.

- The sysops, also working for free, by hundreds, not always keep their 
(our) software updated, and  sometimes show themselves reluctant to 
implement changes that could imply extra work.

- Among our "clients" there are a few who introduce bar information in 
the data flow. It's very easy to do it, as long as anybody can log on 
almost any node and pretend to be another user. I think we all know can 
avoid the net security measures (Just in case, I will not put it here). 
We have raise the level to reject the most "easy" ones, but it is a fact 
that on any large contest / DXped they are always present.

There are several issues more, but I think these ones are enough to 
begin with.

Once all we have all the big photo, it seems clear that there is not a 
fast and simple solution, and that we have to front the problem dividing 
it in small slices. It must also be clear that all the elements 
("personnel") involved in our "enterprise" should work together if we 
want to "sell" a product good enough.

I -myself- shall start taking some small steps:

- I will use only the best software, (in relation to security, I'am not 
measuring other parameters).

- I will not connect to other nodes which have not implemented the same 
security level, that is:

- Only registered users and *with passwords* will be able to put data in 
my node. Given our system, anybody can always pretend to be a registered 
user -and send spots- if a password is not necessary to do so.

- The nodes connected to mine shall be connected only to other nodes 
with the same security measures.

- I will (well, I am already doing it) connect to other nodes registered 
with password, that is:

SET/SPIDER M4TENODE
SET/REGISTER M4TEN0DE
SET/PASSWORD M4TEN0DE 8-12!cHArpASS

- If I reach a certain number of users, I will send (derivate) the rest 
to other nodes. If we have now, say 500 nodes on the, it doesn't seem 
very logic having some of them with 10K users and others with 10.

- I will limit my connections to other nodes to a maximum of 2 (3?) 
nodes by continent. No more is needed and this way I will try to avoid 
duplicate data traffic and fake users coming in.

I encourage to other sysops to join this few and simple rules in order 
to create a quality network. I don't want to take part -as another 
loudspeaker more- for the people disturbing ham radio activities. It 
would be very easy to detect any node not following the rules and lock 
it if these few rules are followed.

Then, our "clients" will choose which net they prefer. During a 
Dxpedition or a contest, do you want to spend your time running from a 
fake spot to another? Well, their choice.

I believe that with some work, we can find a no very complicated system 
of broadcast the users/passwords around the nodes. This way, we will 
reduce the work of the nodes with larger amounts of clients. I'll send 
Dirk some ways to analyze whether they are doables or not.

About data protection acts/laws, we are already saving personal data 
(name, loc, email,...) if we use some kind of hash storing / 
transmission, I don't think it should change the data types being shared 
/ stored

I left for sure a lot of aspects of the problem, but I think this post 
is long enough and its aim is only make all the people involve think 
about it and collaborate on the search of solutions.

73 de Mikel EA2CW (as always, please forgive me for my english)

El 22/02/2023 a las 12:06, Dirk Koopman via Dxspider-support escribió:
> I have been looking at the code and doing some thinking. And I am 
> afraid that we may have started to go down the wrong path by using 
> set/lockout. As currently implemented when a new node appears on the 
> cluster, a number things happen:
>
> 1. A new user record is created.
> 2. That record is marked as a basic node
> 3. It is locked out.
>
> The reason it is locked out is prevent any node connecting to any 
> other node without asking the sysop of that other node first. What it 
> isn't - is a good method to distinguish a 'good' node from 'bad' 
> (whatever is decided that means - this week).
>
> There are a few other things that happen to this user record as 
> various other PC messages appear from that node:
>
> A PC41 will update any other information for that node (qth, name, qra 
> etc).
> A PC92/3 record of any sort will set that node as a Spider node (at 
> the moment I don't differentiate between CC-Cluster and DXSpider 
> nodes, they speak (roughly) the same PC92/3 and PC61 protocol.  It 
> does not unlock it.
>
> If a sysop grants another node's request to connect, they will then 
> issue a set/spider (or node, arccluster etc), this will 
> _*automatically*_ unlock that node.
>
> By doing all these set/unlocks globally, we are unconditionally 
> allowing access by those unlocked nodes to your node without your 
> _*explicit*_ consent.  Which probably _*isn't*_ what is wanted.
>
> But it gets worse: I cannot see a method of distinguishing whether an 
> incoming spot (from afar, or a non-DXSpider node) is forged or not. I 
> remain unconvinced that registration, by itself, whether flagged by 
> some field (for instance, in a PC92 K) helps anything much. 
> Registration - to get closer to a guarantee that the user/ip address 
> combo in the PC61/93 is truly genuine - will likely require something 
> more than simply a password. An "ideal" solution might be available 
> through SSL client certificates but that is a whole lump of 
> infrastructure that would be even more difficult to administer (and 
> get logging programs to use) than passwords.
>
> I observe that last weekend there were just 20 odd spots that could be 
> regarded as 'rude'. I suspect that there were many more spots sent 
> that were wrong in some way, 'busted' or even downright forged (for 
> whatever reason). I wonder whether now would be a good time to put 
> this all to sleep for a while, to draw breath - so that when we do 
> something extra it will make a tangible difference.  As it stands at 
> the moment, given that there are a large set of non-DXSpider sources 
> of spots, we seem to be rushing headlong into cutting our noses off to 
> spite our faces.
>
> Kin is doing an excellent job in motivating nodes running the master 
> branch of the code to upgrade to mojo (and keep it up to date in the 
> future). I am very grateful that he has taken the time (and quite a 
> lot of trouble) to do this. You could all help by encouraging your 
> DXSpider neighbour nodes to so as well. I am also available to help 
> you to upgrade, via ssh, if it is all too difficult or something goes 
> wrong. Just email me privately.
>
> This is my current work plan:
>
> 1. Add the missing load/bad... commands to allow the creation of a a 
> global (as well as local) baddx, badword, badnode lists.
> 2. Establish a formal way of submitting a 'bad...' entry to the 
> central repository in such a way that it does not become a burden for 
> that repository's owner to keep it all up to date.
> 3. Establish a way for all sysops to see the lists of all of these 
> global entries.
>
> Question: given the work plan being done and tested, is now not the 
> time to check to see that what has been done is enough? The new 
> badword and badip system seem to have taken a very large chunk out of 
> the overtly abusive behaviour such that I believe we are now (and 
> especially after the work plan is done) well beyond the point of 
> diminishing returns.
>
> Another question: I would like some suggestions as to how to 
> (preferably automatically) check that a new user, requesting 
> registration, is who they say are and, should a method involve the use 
> of email addresses and/or database lookups (such as qrz.com), how that 
> can be done without having to register nodes as 'data controllers' 
> under GDPR et al.
>
> Dirk G1TLH
>
>
>
> _______________________________________________
> Dxspider-support mailing list
> Dxspider-support at tobit.co.uk
> https://mailman.tobit.co.uk/mailman/listinfo/dxspider-support

-- 
ea2cw at gautxori.com
Bilbao, Bizkaia. IN83MG
http://radio.gautxori.com
http://qrz.com/db/ea2cw
https://t.me/EA2CW