<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body style="overflow-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;"><div>Hi Dirk et al,</div><div><br></div>Are we saying then that v2.0 has registration set as standard? I really feel that this should be the case. As someone who was there when Dirk implemented it during 9/11 (How many updates did you release that day Dirk?) and has been using it ever since on 2 cluster nodes, it is really no problem once you are on top of it.<div><br></div><div>A couple of small things I would like to see improved around registration though. If a user asks for registration, it would be nice to be able to set/reg and get a response if the user is already registered. That would save having to do stat/user to check every time. Quite a lot of HRD users in particular think that if they reload their software, then they have to ask for registration again for some reason.</div><div><br></div><div>Again with HRD, there is a check box in the cluster options to increment the SSID if a user loses connection and then cannot log back in because the cluster thinks they are still there. Whilst I understand the reason for this option, it breaks the registration as each SSID is deemed as a separate user for registration. I wonder if registration could cover all SSID’s or even if this is a good idea?</div><div><br></div><div>As for stat/user, it would be nice to see if a user is *not* registered or does not have a password set. Currently, nothing is shown for either if they are not implemented. I really am. A ’show me either way’ type of guy (put it down to age).</div><div><br></div><div>The issue is of course, how to ‘persuade’ v1.0 nodes to upgrade to v2.0 as some sysops just seem to set up a node because they can and then don’t seem to bother with it as long as it runs.</div><div><br></div><div>Just a few thoughts</div><div><br></div><div>73 Ian<br><div><br><blockquote type="cite"><div>On 2 Nov 2022, at 22:06, Dirk Koopman via Dxspider-support <dxspider-support@tobit.co.uk> wrote:</div><br class="Apple-interchange-newline"><div>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<div>
<div class="moz-cite-prefix">Most of this is achievable and/or a
reasonable idea.<br>
<br>
However, there are some things that I won't do, for a variety of
reasons:<br>
<br>
<ul>
<li>I WILL NOT distribute login information around the network.
However one does it, it has a number of security risks
associated with it. It's simply not going to happen. PS Even
if it were, it certainly wouldn't be MD5 hashes.</li>
<li>What I can do (and will implement) is a new PC41 type 6
message which will be structured like all the others
PC41^6^user call^registration node call^user IP address[:IP
address...]^H99. This will be sent on registration and on the
next (configurable) 3 logins. Additional IP addresses will
also cause PC41s to be sent. Thereafter they will be sent when
a 'forward/opernam' command requests it using RCMD, or by the
periodic, automatic process that (currently) happens for every
user that has the node as the homenode - and now will happen
if they are registered as well. This will change to every
(configurable) 3 months (as opposed to the current 12 months).
If any user has not logged onto node within the last
(configurable) 12 months, then registration is cancelled.
Nodes will also prune out known registered users if they have
not seen a PC41 for a similar period. Anyone not seen in the
last 36 months will be removed completely (in theory this
happens already - but I am wondering whether it is actually
working).</li>
<li>The fact that a user has been registered on another node
will be noted in the user file, BUT it will *STILL* mean that
a user will need to register on this node. In other words: a
registration on another node, that has been notified by PC41,
is there to provide some confidence that data purporting to
come from a known user on a known node and known IP address is
probably OK. It also improves analysis and detection, after
the fact, if something bad happens. <br>
</li>
<li>There has to be some "grit" in the system, so that bots will
find it difficult to automate registration. I am open to
suggestions, but forcing the sysop to confirm a registration
they have been automatically been sent (either as SP or email)
to them after a new registration request from a user, and the
sysop then doing a manual 'set/register' for that user will
certainly slow the bots down :-) But I am also happy to
consider other, bot unfriendly, suggestions. <br>
</li>
<li>Suggestions for dealing with existing (long time) users will
be gratefully received. <br>
</li>
<li>There will be NO AUTOMATED method of one sysop
de-registering a user on the rest of the (new) cluster.
Period. The whole business of deciding who is doing what to
whom and then deciding if and at what level any sanction
happens, is just a can of worms. There are some obvious things
that happen that we could agree on, but how one goes about
coordinating actions by independent sysops is difficult to
impossible make happen.<br>
</li>
<li>I'm not certain how one deals with the changeover to v2.0,
given that the majority of spots and anns will still come from
v1.0 - and this is important - committed DXers really don't
care; just so long as they see the spots. Maybe add a single
letter marker to user displayed version of the comment (S for
suspicious or D for dubious?).<br>
</li>
<li>One thing that I have noticed is that several spots/anns
lately have the same comment sent by different calls. The
"duplicates" could be intelligently deduplicated just by
comment...<br>
</li>
</ul>
<br>
My 2 cents worth...<br>
<br>
73 Dirk G1TLH<br>
<br>
On 16/09/2022 08:40, Joaquin via Dxspider-support wrote:<br>
</div>
<blockquote type="cite" cite="mid:b1de8681-5269-f99a-120b-650b502aeeb0@cronux.net">Hi all,
<br>
<br>
We have all seen the offensive spots that have been being sent to
the Net. Others know that in WW contests, malicious spots are sent
in order to cause the disqualification of an operator or team in
that contest. We also know that if an authentication policy is not
applied in our nodes, this will continue to happen and the sysops
will always follow behind trying to block the alleged offenders,
but not only are we late because the spot has already spread, in
addition, the spotter is usually an unassigned callsign or worse
still, from an operator that is not the one that actually sent
that garbage. The bad thing is that we block those operators
without knowing if they are the cause.
<br>
We also know that many of the nodes are not updated, so new
features and bug fixes are not applied to them. This makes it
impossible for the current network to evolve to a more secure and
reliable one.
<br>
<br>
How can progress be made without the collaboration of the sysops
community? An answer to this question may be this draft:
<br>
<br>
Let's say the current Network is v1.0 and the new one will be
called v2.0.
<br>
<br>
The Network v1.0 remains as it is today.
<br>
The new Network v2.0 would be an evolution of v1.0 in such a way
that a series of functions would be incorporated:
<br>
1. Every connection (user-node, node-node) would be with
login/password authentication to be able to use the sending of
information.
<br>
2. The information of all users and nodes will always be at least
username, password, email if they are registered/validated.
<br>
3. Passwords will be stored encrypted (eg in MD5).
<br>
4. In order for a user registered/validated by a sysop on your
node to access any other v2.0 Network, this information will be
sent to all v2.0 nodes.
<br>
5. In the case of DXSpider, the current logging mechanism should
allow sending an email to the sysop.
<br>
6. A new command should be included that allows the sysop to send
a message (email) indicating that a certain user who is registered
in the v2.0 Network has broken the rules and that he proposes that
he be blocked/eliminated from the nodes.
<br>
<br>
For both networks to cohexist initially:
<br>
v2.0 <-> v2.0. Network v2.0 nodes with other v2.0 nodes will
send and receive the same information as they do now.
<br>
v2.0 <-> v1.0. In the case of Network v1.0 nodes that
connect to v2.0 nodes, the former will continue to function as
before, but v2.0 nodes will only maintain the link up, receiving
the spots, ann, .. ., but since v2.0 spots will not be sent, ann,
...
<br>
v1.0 <-> v1.0. The interconnection between nodes of the
Network v1.0 was safe as before.
<br>
<br>
The idea is that the v1.0 nodes converge on the v2.0 Network
without being isolated, progressively disappearing when they
realize that they do not receive all the spots and their software
is not updated.
<br>
<br>
From a developer point of view, I think it would be possible to
use newer PCxx and CCxx with less impact if current software can
be adapted. And with some modifications for the current v1.0. But
it is still a job that takes time and effort.
<br>
<br>
For this to work, the involvement of cluster developers and sysops
is necessary, especially those that have more users and therefore
can exert indirect pressure to promote change.
<br>
<br>
What do you think of this proposal?
<br>
Possible improvements?
<br>
Infeasibility?
<br>
Alternatives?
<br>
<br>
Regards.
<br>
<br>
Kin EA3CV
<br>
<br>
sysop EA3CV-2, EA4URE-2,3,5
<br>
<br>
<br>
_______________________________________________
<br>
Dxspider-support mailing list
<br>
<a class="moz-txt-link-abbreviated" href="mailto:Dxspider-support@tobit.co.uk">Dxspider-support@tobit.co.uk</a>
<br>
<a class="moz-txt-link-freetext" href="https://mailman.tobit.co.uk/mailman/listinfo/dxspider-support">https://mailman.tobit.co.uk/mailman/listinfo/dxspider-support</a>
<br>
</blockquote>
<br>
</div>
_______________________________________________<br>Dxspider-support mailing list<br>Dxspider-support@tobit.co.uk<br>https://mailman.tobit.co.uk/mailman/listinfo/dxspider-support<br></div></blockquote></div><br></div></body></html>