[Dxspider-support] FTx autogenerated spots
Dirk Koopman
djk at tobit.co.uk
Tue Mar 18 13:24:11 GMT 2025
There will be a version of this in the next release.
Dirk
On 18/03/2025 12:51, IZ2LSC via Dxspider-support wrote:
> I Ciemon,
> it was just a different approach, not yet implemented because I'm sure
> Dirk could do something better.
> I'm just doing some experiments on a lab node.
>
> 73s
>
> Andrea
> -->
>
>
> On Tue, Mar 18, 2025 at 11:48 AM Ciemon Dunville via Dxspider-support
> <dxspider-support at tobit.co.uk> wrote:
>
> Andrea,
>
> I'm curious as to whether or not your rate limiting applies to
> your (you only) 'OTA cluster? Or are you not forwarding spots into
> those systems?
>
> Having just had a look, I can't see any mention of you rate
> limiting spots on your cluster, it would be useful to understand
> your thinking/levels etc
>
> 73, Ciemon
>
> ---
> Ciemon Dunville - GØTRT <https://www.qrz.com/db/G0TRT>
> Warminster, Wiltshire. UK
> Sysop @G0TRT-9
>
>
>
>
> On Tue, 18 Mar 2025 at 08:46, IZ2LSC via Dxspider-support
> <dxspider-support at tobit.co.uk> wrote:
>
> Because I don't tolerate serial spotters (human or robot, SSB
> or DATA or CW), my approach is different and radical.
> If a spotter exceeds a threshold of spots/m it is blacklisted
> for a certain time.
>
> 73s
>
> Andrea, iz2lsc
>
> -->
>
>
> On Tue, Mar 18, 2025 at 3:28 AM Christopher Schlegel via
> Dxspider-support <dxspider-support at tobit.co.uk> wrote:
>
> Agreed on the update point...
>
> And I see your point on the likeness of the auto
> generation, but I'm going to play devil's advocate here.
> In the last week the K index has been horrible for
> barefoot and a wire operators leading to an increase in
> digital mode activity. I am one of these operators. Now, I
> don't care for auto generated spots and have it disabled
> as I feel that I can filter the spots better than just
> automagically letting it happen (my opinion). I am capable
> and educated (through effort) enough to do that. I
> understand the argument for general users and their
> capabilities, ignorance is not an excuse at some point.
> Perhaps an education campaign by sysops could help the
> situation, but that's a losing battle as well. Proven by
> Kin's efforts. Gives me the idea to put a link to the wiki
> in the MOTD.
>
> Most software that I have been exposed to will
> automatically spot (if set) when a contact has been
> logged. No different than an overzealous spotter at say a
> few spots a minute. The gotcha here is that the
> information is valid (as much as any manually entered
> spot) and authentic to the contact. Even during contests,
> if all QSOs were automatically spotted of even the best CW
> 2BSIQ operators you're looking at maybe 9 spots per minute
> by various call signs. 500 QSOs/hr / 60min = 8.33
> spots/min (exaggerated for headroom)
>
> I think there is merit in the idea of rate limiting, at
> least in mitigating the effect of flooding. Websites and
> other software (thinking PSKReporter, rate limiting login
> attempts, etc.) do this all the time. The deduping
> algorithms employed in the cluster (haven't forgotten the
> bypass) do to some extent but not in the manner needed.
>
> Authenticity of spots is a separate issue to me. As you
> mentioned previously, the cluster is far too disparate and
> open to truly fix that issue while being inclusive to
> older technologies and formats. Again, we mirror the
> greater Internet at this point and trying to get everyone
> on board is like pulling teeth. Do we use the greater
> share that Spider nodes have to force a movement? Is it
> worth an essentially civil war at this point alienating
> older nodes? I don't think this is in the spirit of
> Amateur Radio nor is keeping everything a secret by way of
> going closed source. I applaud Dirk's efforts here
> in adhering to the spirit. If someone used my radio gear
> to broadcast a commercial transmission, would I not have
> the responsibility to prevent that and suffer the
> consequences that follow?
>
> Sysops need to wake up and pay attention. These attacks
> are coming from somewhere, there has to be a way to find
> the holes and do what we can to patch them. My personal
> opinion is that I provide a service and compromising that
> to solve a problem is the easy way out. I would
> respectfully request that these changes remain optional so
> that I can provide the service to users the way I believe
> it should be. Some other sysops have already filtered out
> FTx spots on their nodes and advertise them that way. I do
> not filter announcements so any user that would prefer
> that, is able to see them and make that choice for themselves.
>
> It has been danced around on this list and I'm just going
> to go and outright say it...sysops that are absent or
> apathetic perhaps need to be disconnected as a warning or
> make their nodes inaccessible to the public. A culling of
> sorts to prune the dead weight and reduce the vulnerable
> attack surface. This I feel is the real vulnerability of
> the system that gets exploited. Checking in once in a
> while or paying attention to communication from a group
> that a sysop directly affects is the first and foremost
> thing we can do to cooperate on keeping things healthy. I
> for one will keep paying attention in hopes of finding
> that slip that lets us figure out the hole and I will
> continue to work with other sysops here in that effort.
>
> As always, I am not a developer, but I will respect the
> decisions of the group and the developer who has so
> graciously spent his time providing the software needed to
> provide this service to the hobby.
>
> 73, Chris WI3W
>
> Sorry for the rant like prose, but a call to arms is needed...
>
>
> On Mon, Mar 17, 2025, 18:58 Dirk Koopman <djk at tobit.co.uk>
> wrote:
>
> Which is the place that I am coming from. Maybe, in
> this case, on somewhat specious grounds but is
> precisely in the light of the recent uptick in
> attacks on the network that caused me to do this.
>
> Please bear in mind that the network was recently used
> to promote and facilitate someone’s commercial
> activity by sending genuine (looking) spots by
> irregular means. But ignoring the whys and wherefores
> of the circumstances: consider the nature of the
> generation. The majority of those spots were
> automatically generated by design. Just like these
> spots AND they too were then modified by some people
> to get around the filters - just like the spots
> causing the recent flooding.
>
> They were designed to affirm rather than inform the
> user. The system generated them rather than the user.
> As sysops and I struggled to contain the flood, and
> the resulting vendetta that ensued, caused even more
> problems and has led me to conclude that any automated
> spots are to be discouraged or removed.
>
> Some years ago I had a similar spat with an author
> about automated FTx spots. Which went nowhere. The
> volume may not be the same but these spots annoy many,
> many users when they appear in large runs as they did
> (for a time) this afternoon. Hence this little
> experiment.
>
> Users are not literate enough to (force their user
> programs to) create filters for themselves*. Either I
> have to provide a mechanism or sysops have to each
> create a local command / filter to do it for them.
>
> Anyway I shall be merging the test branch tomorrow
> (with this feature switched off) and I’ll do something
> about a user version as well (maybe disable/ftx) with
> a sysops function to allow or disable Ftx spots for
> users as well. Maybe that will mean that the nodes
> running very old software offering this as a selling
> point might upgrade. Sigh.
>
> 73 Dirk G1TLH
>
> * In the last couple of days I have had a request from
> a user to fix his filters for Hamclock.
>
> > On 17 Mar 2025, at 19:19, Christopher Schlegel
> <sutehk.cs at gmail.com> wrote:
> >
> > Flooding, providing false info, or other abuses to
> the cluster is our domain as it directly relates to
> the above sysop responsibilities.
>
> _______________________________________________
> Dxspider-support mailing list
> Dxspider-support at tobit.co.uk
> https://mailman.tobit.co.uk/mailman/listinfo/dxspider-support
>
> _______________________________________________
> Dxspider-support mailing list
> Dxspider-support at tobit.co.uk
> https://mailman.tobit.co.uk/mailman/listinfo/dxspider-support
>
> _______________________________________________
> Dxspider-support mailing list
> Dxspider-support at tobit.co.uk
> https://mailman.tobit.co.uk/mailman/listinfo/dxspider-support
>
>
> _______________________________________________
> Dxspider-support mailing list
> Dxspider-support at tobit.co.uk
> https://mailman.tobit.co.uk/mailman/listinfo/dxspider-support
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.tobit.co.uk/pipermail/dxspider-support/attachments/20250318/fabf7227/attachment-0001.htm>
More information about the Dxspider-support
mailing list