APRS Mobile 1.0 Released for iPhone/iPad

[Gregory A. Carter]

Hi All,

With the release of iOS8 I have released a new APRS app into the Apple App
Store for both iPhone and iPad. I have received a large number of requests
over the years for an APRS app that connects to APRS-IS directly and I am
excited to announce that APRS Mobile does just that and is available in the
app store today.

Features:

- Beacon your position while app is in background
- Real time position mapping of other Amateur Radio stations around the
world with PHG circle plots, track lines and "Dead Reckoning"
- Supports SmartBeaconing
- Callsign SSID support
- Ability to change APRS icon
- Imperial, metric and nautical units supported
- High and low battery drain modes for background GPS/positioning
- Background beacon using minimal data
- Focus on APRS tactical data, no messaging
- View weather (WX) station data (graphs coming soon)
- Beacon prediction
- Packet statistics (packets sent, average time between packets, etc)
- Maximize map viewable area by briefly touching the map to hide/reveal
navigation
- iOS8 Support

Planned Features:

- RESTful mode with option to use several different APRS API's including
our 2015 release Mac App API
- Enhanced multiple station tracking
- WX scrolling graphs
- Animated movements of stations
- Object Creation
- Tactical callsign mapping
- Telemetry
- Your requested feature here....

There is no future plan to add messaging into this app, the focus is on the
tactical value of station reports, however we'll be releasing an APRS
messaging app in the next few months that focuses directly on messaging.
Keeping functionality separate makes releases far easier to address issues
and add additional functionality.

APRS Mobile may be viewed at :
https://itunes.apple.com/us/app/aprs-mobile/id915387067?ls=1&mt=8

I welcome feedback as in the next few weeks I'll be releasing a few
additional versions that take more advantage of some of the exciting new
functionality that iOS8 provides. I will also be slowly replacing all the
antiquated icons, creating a new public github repository for everyone to
freely contribute and share vector APRS icons and add any suggested
features.

In 2015 Q1 I'll be releasing OpenAPRS for Mac which will be an APRS-IS
application with GPS/serial support, uses the same mapping engine as APRS
Mobile and will offer restful support for APRS Mobile which will allow
folks to run the mac app as the backend for a restful service for the iOS
app.

Greg

[Tom Hayward]

What methods does it support for authentication? You say it connects
directly to APRS-IS, so I suspect it supports passcode authentication.
What about SSL, like APRSdroid?
http://aprsdroid.org/ssl/

I expect authentication to the REST API to be some other system,
although using a LotW certificate would be most convenient [for me]
since it's already in use elsewhere in APRS-IS infrastructure.

I'm interested in hearing more about the REST API.

Tom KD7LXL

Post by Gregory A. Carter
Hi All,
With the release of iOS8 I have released a new APRS app into the Apple App
Store for both iPhone and iPad. I have received a large number of requests
over the years for an APRS app that connects to APRS-IS directly and I am
excited to announce that APRS Mobile does just that and is available in the
app store today.
- Beacon your position while app is in background
- Real time position mapping of other Amateur Radio stations around the
world with PHG circle plots, track lines and "Dead Reckoning"
- Supports SmartBeaconing
- Callsign SSID support
- Ability to change APRS icon
- Imperial, metric and nautical units supported
- High and low battery drain modes for background GPS/positioning
- Background beacon using minimal data
- Focus on APRS tactical data, no messaging
- View weather (WX) station data (graphs coming soon)
- Beacon prediction
- Packet statistics (packets sent, average time between packets, etc)
- Maximize map viewable area by briefly touching the map to hide/reveal
navigation
- iOS8 Support
- RESTful mode with option to use several different APRS API's including our
2015 release Mac App API
- Enhanced multiple station tracking
- WX scrolling graphs
- Animated movements of stations
- Object Creation
- Tactical callsign mapping
- Telemetry
- Your requested feature here....
There is no future plan to add messaging into this app, the focus is on the
tactical value of station reports, however we'll be releasing an APRS
messaging app in the next few months that focuses directly on messaging.
Keeping functionality separate makes releases far easier to address issues
and add additional functionality.
APRS Mobile may be viewed at
:https://itunes.apple.com/us/app/aprs-mobile/id915387067?ls=1&mt=8
I welcome feedback as in the next few weeks I'll be releasing a few
additional versions that take more advantage of some of the exciting new
functionality that iOS8 provides. I will also be slowly replacing all the
antiquated icons, creating a new public github repository for everyone to
freely contribute and share vector APRS icons and add any suggested
features.
In 2015 Q1 I'll be releasing OpenAPRS for Mac which will be an APRS-IS
application with GPS/serial support, uses the same mapping engine as APRS
Mobile and will offer restful support for APRS Mobile which will allow folks
to run the mac app as the backend for a restful service for the iOS app.
Greg
--
NV6G
OpenAPRS.Net
OpenAPRS iPhone Edition
Find RC sites and weather in your area on iPhone/iPad with WhereBRC
_______________________________________________
aprssig mailing list
http://www.tapr.org/mailman/listinfo/aprssig

[Steve Dimse]

Post by Tom Hayward
What methods does it support for authentication? You say it connects
directly to APRS-IS, so I suspect it supports passcode authentication.
What about SSL, like APRSdroid?

This is exactly like putting a $500 lock on the front door of a house that has a back door that will not even close. You might feel better for having done something, but if you feel better you are deluding yourself - the contents of the house are not a single bit more secure.

Unless there is a new APRS IS protocol you are doing nothing but wasting time.

Steve K4HG

[Tom Hayward]

Post by Steve Dimse

Post by Tom Hayward
What methods does it support for authentication? You say it connects
directly to APRS-IS, so I suspect it supports passcode authentication.
What about SSL, like APRSdroid?

This is exactly like putting a $500 lock on the front door of a house that has a back door that will not even close. You might feel better for having done something, but if you feel better you are deluding yourself - the contents of the house are not a single bit more secure.
Unless there is a new APRS IS protocol you are doing nothing but wasting time.

Once the back door is boarded up, that $500 lock will work quite well.

I apologize. I forgot this is ham radio, where we stopped innovating in 1993.

Tom KD7LXL

[Steve Dimse]

Post by Tom Hayward
Once the back door is boarded up, that $500 lock will work quite well.

Wouldn't it make sense to board up the back door before spending the money? If no one wants to hammer in the nails the lock is wasted, and that is the current situation.

Post by Tom Hayward
I apologize. I forgot this is ham radio, where we stopped innovating in 1993.

It isn't an issue of innovation, it is an issue of effort vs. return. The APRS IS has been wide open for almost as long as it has existed without causing problems. If there is no perceived problem there is no return, so no effort is justifiable to most people who look at this as a practical system.

The only way to secure the APRS IS is to start over with a secure infrastructure which is separate from the existing one. Until there is a perceived need, until the users are unhappy with the current system, a new system will not attract many of the users - especially if it invalidates favorite software or requires additional effort.

My point is not rehash this, only to take exception to your challenge of a new client based on this issue. A sure way to squash innovation is to expect a new client to address a problem the vast majority of existing clients do not, and which the vast majority of users do not care about!

Steve K4HG

[Gregory A. Carter]

Hi Tom,

At the moment we use plaintext passcode. Apple requires apps using any
encryption to go through the export certificate process with the US so it
makes adding any sort of noticable SSL difficult and borderline not worth
doing. App makers often don't press the check mark for encrypted apps when
submitting to apple even when they actually do use SSL and get away with it
but having an active place to set an SSL cert would trigger red flags and
force an export cert.

Greg

Post by Tom Hayward
What methods does it support for authentication? You say it connects
directly to APRS-IS, so I suspect it supports passcode authentication.
What about SSL, like APRSdroid?
http://aprsdroid.org/ssl/
I expect authentication to the REST API to be some other system,
although using a LotW certificate would be most convenient [for me]
since it's already in use elsewhere in APRS-IS infrastructure.
I'm interested in hearing more about the REST API.
Tom KD7LXL

Post by Gregory A. Carter
Hi All,
With the release of iOS8 I have released a new APRS app into the Apple

App

Post by Gregory A. Carter
Store for both iPhone and iPad. I have received a large number of

requests

Post by Gregory A. Carter
over the years for an APRS app that connects to APRS-IS directly and I am
excited to announce that APRS Mobile does just that and is available in

the

Post by Gregory A. Carter
app store today.
- Beacon your position while app is in background
- Real time position mapping of other Amateur Radio stations around the
world with PHG circle plots, track lines and "Dead Reckoning"
- Supports SmartBeaconing
- Callsign SSID support
- Ability to change APRS icon
- Imperial, metric and nautical units supported
- High and low battery drain modes for background GPS/positioning
- Background beacon using minimal data
- Focus on APRS tactical data, no messaging
- View weather (WX) station data (graphs coming soon)
- Beacon prediction
- Packet statistics (packets sent, average time between packets, etc)
- Maximize map viewable area by briefly touching the map to hide/reveal
navigation
- iOS8 Support
- RESTful mode with option to use several different APRS API's including

our

Post by Gregory A. Carter
2015 release Mac App API
- Enhanced multiple station tracking
- WX scrolling graphs
- Animated movements of stations
- Object Creation
- Tactical callsign mapping
- Telemetry
- Your requested feature here....
There is no future plan to add messaging into this app, the focus is on

the

Post by Gregory A. Carter
tactical value of station reports, however we'll be releasing an APRS
messaging app in the next few months that focuses directly on messaging.
Keeping functionality separate makes releases far easier to address

issues

Post by Gregory A. Carter
and add additional functionality.
APRS Mobile may be viewed at
:https://itunes.apple.com/us/app/aprs-mobile/id915387067?ls=1&mt=8
I welcome feedback as in the next few weeks I'll be releasing a few
additional versions that take more advantage of some of the exciting new
functionality that iOS8 provides. I will also be slowly replacing all the
antiquated icons, creating a new public github repository for everyone to
freely contribute and share vector APRS icons and add any suggested
features.
In 2015 Q1 I'll be releasing OpenAPRS for Mac which will be an APRS-IS
application with GPS/serial support, uses the same mapping engine as APRS
Mobile and will offer restful support for APRS Mobile which will allow

folks

Post by Gregory A. Carter
to run the mac app as the backend for a restful service for the iOS app.
Greg
--
NV6G
OpenAPRS.Net
OpenAPRS iPhone Edition
Find RC sites and weather in your area on iPhone/iPad with WhereBRC
_______________________________________________
aprssig mailing list
http://www.tapr.org/mailman/listinfo/aprssig

_______________________________________________
aprssig mailing list
http://www.tapr.org/mailman/listinfo/aprssig

[Heikki Hannikainen]

Post by Gregory A. Carter
At the moment we use plaintext passcode.

To be a bit more specific, APRS Mobile 1.0 calculates the passcode for the
callsign entered by the user.

1) User enters his callsign in the configuration view
2) Correct passcode automatically appears in the passcode field of the
configuration view

- Hessu

[Lynn W. Deffenbaugh (Mr)]

Ug. And this conforms how to the requirement on

*It is the responsibility of each software author to provide the
proper passcode to their individual users on a request basis.* This is
to aid in keeping APRS-IS restricted to amateur radio use only.

IMHO, it should default to -1 until some contact is made to honor the
responsibility of the software author to get a proper passcode for their
callsign.

Lynn (D) - KJ4ERJ - Author of ARPSISCE for Windows Mobile and Win32

Post by Gregory A. Carter
At the moment we use plaintext passcode.

To be a bit more specific, APRS Mobile 1.0 calculates the passcode for
the callsign entered by the user.
1) User enters his callsign in the configuration view
2) Correct passcode automatically appears in the passcode field of the
configuration view
- Hessu
_______________________________________________
aprssig mailing list
http://www.tapr.org/mailman/listinfo/aprssig

[Gregory A. Carter]

I will not go into detail of how but if a non-licensed ham is discovered
and reported I can prevent them from posting.

That being said, the next release will not show the passcode in plaintext
to prevent users from using the app to generate and get passcodes to use
them outside of the app.

I will however, point out a couple of things:

1) It is unlikely a non-amateur radio operator will search for an APRS app.
2) It is unlikely they will bother to spend $4.99 on it just to screw with
the network.
3) In the years OpenAPRS has been out as an APRS app on iOS I've not had
issues. The combination of likelyhood + the ability I have to deadman
switch posting makes abuse a statistically insignificant issue.

Hopefully that addresses any concern of the security of the network. I will
also point out you can search for APRS passcode and the first 2 or 3 hits
are web generators. There are far more appropriate gripes over passcode
security of APRS-IS greater than an auto-generated passcode on a paid app
that can be switched off remotely.

Greg

On Mon, Sep 22, 2014 at 7:30 AM, Lynn W. Deffenbaugh (Mr) <

Post by Lynn W. Deffenbaugh (Mr)
Ug. And this conforms how to the requirement on
*It is the responsibility of each software author to provide the proper
passcode to their individual users on a request basis.* This is to aid in
keeping APRS-IS restricted to amateur radio use only.
IMHO, it should default to -1 until some contact is made to honor the
responsibility of the software author to get a proper passcode for their
callsign.
Lynn (D) - KJ4ERJ - Author of ARPSISCE for Windows Mobile and Win32
At the moment we use plaintext passcode.
To be a bit more specific, APRS Mobile 1.0 calculates the passcode for the
callsign entered by the user.
1) User enters his callsign in the configuration view
2) Correct passcode automatically appears in the passcode field of the
configuration view
- Hessu
_______________________________________________
aprssig mailing list
http://www.tapr.org/mailman/listinfo/aprssig
_______________________________________________
aprssig mailing list
http://www.tapr.org/mailman/listinfo/aprssig

[Steve Dimse]

It is the responsibility of each software author to provide the proper passcode to their individual users on a request basis. This is to aid in keeping APRS-IS restricted to amateur radio use only.

IMHO, it should default to -1 until some contact is made to honor the responsibility of the software author to get a proper passcode for their callsign.

Again, this is busy work. There is NO security provided by the passcode, at this point it is nothing but an annoyance. If you would feel even the slightest bit better if it defaults to -1 you are delusional.

Steve K4HG

[Javier Henderson]

On Sep 22, 2014, at 9:30 AM, Lynn W. Deffenbaugh (Mr) <

Post by Lynn W. Deffenbaugh (Mr)
Ug. And this conforms how to the requirement on

Post by Lynn W. Deffenbaugh (Mr)
It is the responsibility of each software author to provide the proper

passcode to their individual users on a request basis. This is to aid in
keeping APRS-IS restricted to amateur radio use only.

Post by Lynn W. Deffenbaugh (Mr)
IMHO, it should default to -1 until some contact is made to honor the

responsibility of the software author to get a proper passcode for their
callsign.
Again, this is busy work. There is NO security provided by the passcode,
at this point it is nothing but an annoyance. If you would feel even the
slightest bit better if it defaults to -1 you are delusional.

If the passcode is so useless, maybe we should revise the use of
certificates, as it has been proposed here before more than once.

73,
-jav k4jh

[Steve Dimse]

If the passcode is so useless, maybe we should revise the use of certificates, as it has been proposed here before more than once.

Again, the issue isn't the front end where people sign on, it is the back end where the data travels. It doesn't matter how secure the authentication is when the transport is wide open.

Any system you design for authentication must transmit that authentication information via the APRS IS. Since the passcode is all that is needed to fully authenticate with the APRS IS anyone can put anything on the APRS IS. So if you want security, you must replace the APRS IS.

Is it possible to have a new, secure APRS IS? Yes, but would it reach critical mass? If you move, you lose some connectivity with hams connected through the old system. This would not be an insurmountable hurdle with early adopters blazing the way, except for the fact that the vast majority of users do not see a problem with the current system. So moving has no benefit and a significant loss. Combined with the problem of upgrading software and setting up a new back end transport network it just isn't worth the effort to people that look upon APRS as a functional system rather than a theoretical playpen.

Steve K4HG

[Javier Henderson]

Post by Javier Henderson

Post by Javier Henderson
If the passcode is so useless, maybe we should revise the use of

certificates, as it has been proposed here before more than once.
Again, the issue isn't the front end where people sign on, it is the back
end where the data travels. It doesn't matter how secure the authentication
is when the transport is wide open.
Any system you design for authentication must transmit that authentication
information via the APRS IS. Since the passcode is all that is needed to
fully authenticate with the APRS IS anyone can put anything on the APRS IS.
So if you want security, you must replace the APRS IS.
Is it possible to have a new, secure APRS IS? Yes, but would it reach
critical mass? If you move, you lose some connectivity with hams connected
through the old system. This would not be an insurmountable hurdle with
early adopters blazing the way, except for the fact that the vast majority
of users do not see a problem with the current system. So moving has no
benefit and a significant loss. Combined with the problem of upgrading
software and setting up a new back end transport network it just isn't
worth the effort to people that look upon APRS as a functional system
rather than a theoretical playpen.

You are making a lot of assumptions, rather than rehash everything please
refer to past posts on this, it's all been explained how the proposal
involving SSL certificates includes workarounds for those using ancient or
modern software that doesn't have native support, as well as the benefits
of using strong authentication, such as new services for example.

Aren't we suppose to innovate, advance the state of the art, and so on?

73,
-jav k4jh

[Steve Dimse]

You are making a lot of assumptions, rather than rehash everything please refer to past posts on this, it's all been explained how the proposal involving SSL certificates includes workarounds for those using ancient or modern software that doesn't have native support, as well as the benefits of using strong authentication, such as new services for example.

As I say, it is possible to build a new network to parallel the APRS IS, but unless there is a reason that compels all users to participate most won't, and all you get is a fractured APRS. "new services" is a nice phrase, but what services do you have in mind that would make users want to use it? And who is going to build this?

Aren't we suppose to innovate, advance the state of the art, and so on?

Yes. But making something more complex and fracturing something that works well, is not what I call innovation. If you have an idea in mind, then you need to do what the last generation of APRS innovators did. Build it. If it is good users will come. TAPR has a saying "He who builds, rules". That has worked in the APRS world too. So if you want to innovate, stop talking and just do it!

Steve K4HG

[Javier Henderson]

Post by Steve Dimse
As I say, it is possible to build a new network to parallel the APRS IS, but unless there is a reason that compels all users to participate most won't, and all you get is a fractured APRS. "new services" is a nice phrase, but what services do you have in mind that would make users want to use it? And who is going to build this?

And as I said, there’s nothing about a parallel network, I don’t know why you keep bringing that up and talk about “fracturing APRS-IS"

Post by Steve Dimse
Yes. But making something more complex and fracturing something that works well, is not what I call innovation. If you have an idea in mind, then you need to do what the last generation of APRS innovators did. Build it. If it is good users will come. TAPR has a saying "He who builds, rules". That has worked in the APRS world too. So if you want to innovate, stop talking and just do it!

There is already code in place, aprsc supports it and some of us are using it on tier 2 servers and hubs. The well known APRSdroid app supports SSL as well, and KD7LXL wrote a wiki page once on using stunnel to allow just about every APRS-IS client to use certs.

So we’re not just talking about it, but every time we bring it up you try to shut it down.

73,
-jav k4jh

[Steve Dimse]

Post by Javier Henderson
There is already code in place, aprsc supports it and some of us are using it on tier 2 servers and hubs. The well known APRSdroid app supports SSL as well, and KD7LXL wrote a wiki page once on using stunnel to allow just about every APRS-IS client to use certs.
So we’re not just talking about it, but every time we bring it up you try to shut it down.

I'm not truing to "shut it down", I'm trying to make it clear that this is a lock on the front door of a house without a back door. Yes, you can use certs instead of a passcode, but I can put a packet on the APRS IS that looks exactly like a packet you have sent through your cert mechanism. So this accomplishes nothing.

If you disagree, exactly how is this system more secure?

Steve K4HG

[Javier Henderson]

We already discussed all of this. Please refer to past posts on the
subject, and the relevant presentation by OH7LZB at the DCC in Seattle '13.

73,
-jav k4jh

[Steve Dimse]

We already discussed all of this. Please refer to past posts on the subject, and the relevant presentation by OH7LZB at the DCC in Seattle '13.

As I said, all the discussions I've seen amount to a lock on the front door of a house without a back door. If you cannot describe some concrete additional security this provides then I can only assume my assessment is correct.

As to the DCC, there is no such abstract or paper mentioned on the DCC 2013 page:

http://tapr.org/pub_dcc32.html

Do you have a link for the "relevant presentation"?

Steve K4HG

[Javier Henderson]

Post by Javier Henderson

Post by Javier Henderson
We already discussed all of this. Please refer to past posts on the

subject, and the relevant presentation by OH7LZB at the DCC in Seattle '13.
As I said, all the discussions I've seen amount to a lock on the front
door of a house without a back door. If you cannot describe some concrete
additional security this provides then I can only assume my assessment is
correct.

Sure, whatever.

Post by Javier Henderson
http://tapr.org/pub_dcc32.html
Do you have a link for the "relevant presentation"?

Sure:

-jav k4jh

[Steve Dimse]

Post by Steve Dimse
Do you have a link for the "relevant presentation"?
Sure: http://youtu.be/wQxtvvhf4K8

This is a talk about the authentication side only. It does not address the backend (APRS IS) which is wide open.

So yes, this is a way to authenticate hams. Is it innovative? Of course not. As the talk itself says hams have been using LotW authentication since 2003. The use of SSL authentication goes back much further. But it is ONLY authentication. The computer you are connected to can verify you are a ham, but the rest of the network cannot!

Imagine your bank has the most sophisticated two-factor authentication available. Every time you log on you have to enter a number from a key fob as well as your password. The bank then texts your phone with a random number you have to enter to complete the log in (really, three factor). That is a very secure authentication mechanism. However, if your bank lets anyone call by phone, give just your name and transfer money out of your account, that great authentication is totally wasted. Your money will disappear in no time. If you want something to be secure, it must be secure on all sides, not just from a pretty front facade.

Here is the important thing I'm trying to get across. AUTHENTICATION JUST DOESN'T MATTER IN THE CURRENT APRS IS. You can have the most foolproof authentication possible, but any way you choose to express that on the APRS IS can be spoofed. So fancy authentication is nothing but a useless toy. If you want to play with it fine, but do not be saying that this in any way makes APRS IS more secure. IT DOES NOT!

The only way to fix this is to start over with a parallel APRS IS. And (to localize to the US which has the largest base of APRS users) if the FCC suddenly reversed 15 years of tolerance and said that IGating via the current APRS IS is illegal, then there would be a strong incentive for the development to take place, and for the user base to switch over. But as things stand no there is simply no incentive driving the creation and use of a separate APRS IS. Until there is back end security this is nothing but a meaningless toy.

Steve K4HG

[Javier Henderson]

Steve,

OK.

-jav k4jh

[Georg Lukas]

Post by Steve Dimse
As I say, it is possible to build a new network to parallel the APRS
IS, but unless there is a reason that compels all users to participate
most won't, and all you get is a fractured APRS. "new services" is a
nice phrase, but what services do you have in mind that would make
users want to use it? And who is going to build this?

SSL certificates can be used to login into HamNet, and they could be
used for any kind of online services for radio amateurs (think echolink,
think aprs.fi).

Post by Steve Dimse
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.

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

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.

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.

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.

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.


Georg

[Steve Dimse]

Post by Georg Lukas

Post by Steve Dimse
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.

Post by Georg Lukas
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!

Post by Georg Lukas
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!

Post by Georg Lukas
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.

Post by Georg Lukas
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.

Post by Georg Lukas
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.

Post by Georg Lukas
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

[Javier Henderson]

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

Every time a discussion starts on this group, you disparage it, like you're
doing it now.

Besides comments here, it was discussed on the aprs2net list to some
extent, there were some conversations at the DCC last year, etc.

73,
-jav k4jh

[Georg Lukas]

Post by Steve Dimse
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.

Post by Steve Dimse

Post by Georg Lukas
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.

Post by Steve Dimse
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?

Post by Steve Dimse
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.

Post by Steve Dimse
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.

Post by Steve Dimse
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.

Post by Steve Dimse
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.

Post by Steve Dimse
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).

Post by Steve Dimse
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

[John Gorkos]

Ding ding ding ding! We have a winner! THIS is how we should be doing
authentication on new clients. ARRL LotW certs. The ARRL does the hard
work, we just trust them to get it right. Infinitely better than the
'passcode' system, and not exceptionally difficult to do, especially if
you bake it in to new code. Extensible, as additional cert authorities
come online (RGSB? The Germans?) we just add their certs as trusted to
the server.

I'm with you Javier.

John Gorkos

On Sep 22, 2014, at 9:30 AM, Lynn W. Deffenbaugh (Mr)

Post by Lynn W. Deffenbaugh (Mr)
Ug. And this conforms how to the requirement on

It is the responsibility of each software author to provide the

proper passcode to their individual users on a request basis. This
is to aid in keeping APRS-IS restricted to amateur radio use only.

Post by Lynn W. Deffenbaugh (Mr)
IMHO, it should default to -1 until some contact is made to honor

the responsibility of the software author to get a proper passcode
for their callsign.
Again, this is busy work. There is NO security provided by the
passcode, at this point it is nothing but an annoyance. If you would
feel even the slightest bit better if it defaults to -1 you are
delusional.
If the passcode is so useless, maybe we should revise the use of
certificates, as it has been proposed here before more than once.
73,
-jav k4jh
_______________________________________________
aprssig mailing list
http://www.tapr.org/mailman/listinfo/aprssig

[Jeff Dugas (Mobile)]

Indeed, it is time to bring APRS out of the 90's. There will be those that resist change. But change is inevitable.

[Robert Kirk]

_______________________________________________
aprssig mailing list
aprssig-***@public.gmane.org
http://www.tapr.org/mailman/listinfo/aprssig