[aprssig] APRS Mobile 1.0 Released for iPhone/iPad

[Georg Lukas]

* Steve Dimse <steve at dimse.com> [2014-09-23 13:43]:
> 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.

You mean, as compared to requesting a passcode and entering it into the
application? I would say the work required is comparable, but the
benefits are bigger.

> > 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.

I am with you here, but this issue has been discussed dozens of times
and people insisted on doing it this way, irregardless of any evidence.

> The way this latest OpenAPRS client does it, generating it
> automatically, is the correct way to do this.

So I have the permission to remove the passcode requirement in APRSdroid
as well?  However, APRSdroid can be downloaded for free from the
homepage, and there is no magical kill-switch I can engage if somebody
is abusing the network with it. For sure I am allowed to point anybody
complaining to the above statement in the aprssig archive?

> Or use one of the web generators. As I say, any software author that
> implements this is wasting his own and his users time!

I am well aware of this fact, but you and me are fighting against the
consensus here.

> Callsigns of these "CB stations"? If they are on T2 they are on findU
> and I've not seen or heard of a problem.

From a short search, FRA376 is one that was active in the last days.
FRA012 and FRA199 have been spotted some months ago.
A long blacklist was posted on aprs2net, but it seems to have been
collected over a long interval and contain many stations that are not
active currently.

> Again, this makes no sense when the backbone os not secure.

As I wrote, these are two separate problems, and we need to tackle both
eventually. But using one as an argument to not do anything about the
other will keep the status quo forever, or until somebody starts to
abuse APRS-IS in a big way, and then it will be too late.

> Not without greatly inconveniencing users, and degrading the utility

It will not degrade the utility or inconvenience users if we start
supporting it in our software now, and make it easy to use.

> 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.

What about a benefit to the whole amateur radio community: use one
single mechanism to authenticate to all Internet services for amateurs.

The benefit for the APRS community was already discussed on this list as
well: http://www.tapr.org/pipermail/aprssig/2013-March/041513.html

Currently, this is an _alternative_ login mechanism. Let's keep it this
way until SSL authentication has become the norm (and feel free to
influence other amateur radio online services into that direction).

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

I am speculating here, but the reason might be that the APRS community
has time and again shown that it is not interested in any discussion of
new ideas, as any change would break compatibility to the existing
conglomerate of things.


Georg
-- 
APRSdroid - Open Source APRS Client for Android | http://aprsdroid.org/m
https://play.google.com/store/apps/details?id=org.aprsdroid.app | @APRSdroid
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 811 bytes
Desc: Digital signature
URL: <http://lists.tapr.org/pipermail/aprssig_lists.tapr.org/attachments/20140923/137cbd38/attachment.asc>