[aprssig] APRS Mobile 1.0 Released for iPhone/iPad

[Steve Dimse]

On Sep 23, 2014, at 5:45 AM, Georg Lukas <georg at op-co.de> wrote:

> 
>> Yes. But making something more complex and fracturing something that
>> works well, is not what I call innovation.
> 
> The additional complexity is low, SSL/TLS has been around for decades
> and there is a plethora of libraries available.

To add additional load on the users to obtain and install certificates, which as you say have been around for a long time, is NOT innovation. And again, this adds nothing to the user.
> 
> Also, I can not agree that APRS-IS is "working well". The manual
> approval of passcodes by the program author, as required by the APRS-IS
> specification, is a tedious (and totally useless, because insecure)
> procedure which does not scale well.

Absolutely. To require this is ridiculous. The way this latest OpenAPRS client does it, generating it automatically, is the correct way to do this. This is what started this thread in the first place. On top of everything else this automatic generation was the way it was intended to be done and the way it was implemented for years!

> Users complain because they can not
> immediately use their application; it is a significant workload that
> takes away time from doing useful things, and any evildoer can just
> google up "passcode generator" or install one of the Linux applications
> that bundle a generator tool.
> 
Or use one of the web generators. As I say, any software author that implements this is wasting his own and his users time!

> The aprs2net ML is currently discussing issues with a large number of CB
> stations that crept up on the T2 network, so the problem is real.

Callsigns of these "CB stations"? If they are on T2 they are on findU and I've not seen or heard of a problem.
>  
> The issuing of certificates can be scaled much better, alone by the fact
> that you can use one certificate for multiple different amateur radio
> Internet services. It has been built and tested, and more applications
> and services need to jump up on the wagon.

Again, this makes no sense when the backbone os not secure.
> 
> Once SSL authentication is introduced as an access mechanism and
> implemented, at least for end users, it is possible to limit passcode
> based authentication step by step, and to turn it off eventually.
> 
Not without greatly inconveniencing users, and degrading the utility of the APRS IS. If you provide some benefit to the APRS community perhaps this can be justified, but I haven't heard of any.

> It is a separate issue how to handle the core network, and there are
> ideas there that do not require a separate next-generation APRS-IS
> network.

If there are such ideas they are not being shared with the APRS community. Is there a reason for such secrecy?

Steve K4HG