Should-Be-Asked Questions intended to help clarify issues related to smartphones and similar personal electronic devices running approved ARDF apps are presented below.
Won’t smartphones allow competitors to place phone calls, use maps with GPS, etc. to gain an unfair advantage?
Smartphone hardware does indeed provide support for cellular network access, maps, and other features that, if permitted, would radically change the nature of ARDF. But the hardware features are only accessible through software programs that provide the user access to those functions. An app that does not provide access to the cellular network, or maps, or any other prohibited functionality will prevent the user from accessing those features for as long as the app is running. Apps approved for use in ARDF would not provide access to prohibited functionality.
Won’t a competitor simply be able to close an app and make phone calls, etc.?
Yes, an app can prevent access to prohibited functions only so long as that app is running in the foreground, and maintains control over what the user can access. But approved apps would be required to record events such as the app’s closure, phone calls being answered, and any circumvention of the app such as placing it in the background. The easiest way to record such events is to create log files that reside on the smart device. Those same logs would be required to be submitted immediately after completing a course, by all competitors carrying a smart device in a competition. Failure to provide a continuous log file, or any circumvention of the app indicated in a submitted log, will result in the disqualification of the competitor.
So a competitor carrying a smart device must be required to run the same approved ARDF app during the entire time on the course, from start to finish. Failing to do so will result in disqualification.
In an emergency, a competitor could elect to close the approved app in order to place a phone call for help for him/herself or another competitor. That is an important benefit of allowing cellular-enabled devices to be used on the course. And in the event that a smartphone is used in an emergency situation, the Jury could rule to allow such use in that instance. Such emergency use should be quite rare.
Won’t analyzing all those log files require a lot of effort on the part of organizers?
Before smart devices and approved apps are permitted for use in major ARDF competitions, an automated system for log file submission and analysis should be implemented. Approved apps could automatically and wirelessly upload log files to a server (or local PC) for analysis. The server could automatically analyze all submitted log files, and notify organizers of any suspicious events contained in them. Organizers and/or the jury would only get involved if suspicious log data is found; This should be a rare event.
What about jailbroken phones, hacking, and counterfeit apps running on competitors’ devices?
The devices would not need to be approved for ARDF use, only the apps that run on them. So jailbroken phones, and side-loaded apps, are not an issue. If an approved app is run on a jailbroken phone, or has been sideloaded onto a device, it is still an approved app, and will only provide permitted functions, and will record logs containing evidence of any app circumvention.
Since it is the apps that are approved for use, measures must be put in place to authenticate the apps running on competitors’ devices. Again, the log files could be used for this purpose. Approved apps could be required to support a registration procedure at time of installation, that embeds into the app a unique public key. A unique identifying tag encrypted by the public key (a signature) would automatically be included within the log file submitted by each app-carrying competitor. If the tag in a log file decrypted by the associated private key were found not to match the tag associated with the registered app, that would indicate that an inauthentic app was used and that competitor would be disqualified.
Hacking the authentication system should be made difficult, but extreme measures need not be employed. As long as it is much harder to hack the authentication system than to sew a hidden pocket into a uniform for stashing a disallowed mapping GPS device (for instance), a cheater will choose the easier path.
That all sounds like a lot of work, isn’t it too great a burden to place on organizers and the Working Group?
Yes, the burden of implementing authentication measures, log file submission and analysis tools, and all other components of the overall support system for approved apps, should lie squarely upon those who would utilize the system: the app-carrying competitors and the app writers.
The only burdens imposed upon event organizers and regional authorities should be the creation of rules, approval of systems implemented for authenticating apps, and the adjudication of issues that might come up. That degree of support should prove small relative to the potential benefits.
Who wants to use smart devices and approved apps anyway? What would they add to the sport?
Were a blanket ban on all communication devices not in place, we would almost certainly see smart devices in use at ARDF events today. But without rules governing their use, it is not worth the effort to develop apps and a system to support them, because there is no assurance that the developed apps will ever be allowed to be used in competition.
Modern smartphones and similar devices can provide a vast array of functions relevant to ARDF. From a simple compass app providing magnetic headings, to a graphical user interface providing access to all receiver functions, satellite positioning information (if permitted), background track recording, real-time position reporting, and control point arrival registration. Almost anything imaginable within the rules can be done, including enforcing the rules themselves, with approved apps and a system to support them.
With the rise in popularity of smartphones, approved apps should lower the cost barrier for entry into the sport. Since many participants will already own the most expensive hardware component (the phone itself) little more than a receiver front-end and a suitable antenna will be required to fully participate in the sport.
Cell phone communications access, provided by the smartphones carried by competitors, can add to the sport’s safety.
Welcoming ARDF-app programmers worldwide will help bring in new sport supporters and participants.
In short, there is a lot to be gained from the use of smart devices and approved apps. But it all starts with the rules.
Who would approve ARDF apps?
App approval could be done in any number of ways. But one approach that would help focus the responsibilities on the app users and developers, would be the authorization of App Approval Authorities (for lack of a better name) who would take on the responsibility of developing a complete system.
Applicants from the community of ARDF app users and developers might be allowed to apply to a Regional ARDF Working Group for recognition as an ARDF App Approval Authority. A group so designated would have the responsibility to develop a complete app authentication system for approved ARDF apps: a system that applies to app development, validation, dissemination, and use in competition. The only real “authority” of such an Authority, would be that of defining exactly how the app approval process works under their system. The only reasons for such groups to be officially recognized by the WG, is to avoid chaos, and to afford those Authorities some standing when they request reasonable accommodation at ARDF competitions for testing their systems, etc.
An App Approval Authority would be responsible for all of the work and investment involved in designing and implementing a system to approve and authenticate ARDF apps. It would also be responsible for providing documentation to the Regional ARDF Working Group demonstrating that a proposed system works correctly, reliably, securely, and does not impose excessive demands on organizers.
What would be the approval process for a candidate ARDF app?
App approval would necessarily be a component of an authentication system. It should be the responsibility of an App Approval Authority to define an app approval process that passes muster with a Regional ARDF Working Group.
Exactly what form an app approval process takes remains to be seen, but some of the elements of the approval process might include:
- App authors being required to certify that their apps provide users access only to functions and features allowed under the latest release of official ARDF rules.
- Apps being required to successfully complete a validation process proving that they support log file creation, encryption and submission requirements. (Apps might be required to incorporate the binary of a custom authentication library, providing them with the ability to successfully register and submit logs.)
- Apps would probably need to be officially submitted to an Authority for approval well ahead of their use at sanctioned events, to allow time for validation and any required rework.
- Apps might be required to be open source, so that no hidden functionality could be concealed in them, and a wide community could examine them in detail.
- Apps’ binaries might be compiled and submitted to app stores by an App Approval Authority, rather than by the app authors, in order to ensure the integrity of the submitted binaries.
How do the rules need to change in order to allow approved smart-device apps for ARDF?
Using the Region 1 rules (version 2017) as a baseline, the following changes to Part B Appendix 1, Section T4 should suffice:
T4.2 All personal electronic devices (including satellite positioning devices, and radio receivers or other devices with integrated navigation or communication functionality) are disallowed unless their capabilities are inherently limited to provide no navigation assistance or communications functionality except for the following:
o Short range device-to-device digital communications providing connectivity between permitted devices carried by the same competitor (e.g., Bluetooth, WiFi, or NFC data link between a receiver and a display screen.)
o Long-range digital communications providing connectivity specifically authorized by event organizers (e.g. real-time competitor position reporting over a cellular network.)
o Display of digital official competition maps provided by the event organizers, that can be used in lieu of a paper map.
o Compass direction.
o Non-graphical position information (e.g., latitude and longitude text data stored to a track file) that is unavailable to the competitor during the competition.
Any device capable of providing navigation or communication functions beyond those listed above is subject to T4.3.
T4.3 Personal electronic devices, receivers, and other devices that would otherwise be banned under the rules shall be permitted to be carried by competitors and team officials during the competition if both of the following conditions are met:
o Any device capabilities banned under the rules are not used, and are effectively disabled or unavailable at all times and in all situations where those capabilities are disallowed.
o Evidence of compliance (e.g., continuous log files) to establish that banned capabilities were not utilized must be provided in accordance with an App Authentication Procedure administered by an App Approval Authority designated by the Organizing Society, or as directed by the Organizing Society.
Note 1: the wording above is intended to maintain the ban on smart devices until App Authentication Procedures and App Approval Authorities come into existence, or an Organizing Society decides to establish their own procedures. The terms App Authentication Procedures and App Approval Authorities will also need to be defined in Part A section 1.
Note 2: the wording above is intended to allow an Organizing Society that wants to implement its own app authentication procedures for a particular event to do so. Not all competitions necessarily need to have the most stringent level of rules enforcement. An Organizing Society might choose to simply spot check logs randomly, or only if an infraction is reported or suspected.
Note 3: T4.2 above lists those functions that are allowed, rather than attempting to describe every conceivable function that might be disallowed. This approach should result in a shorter and simpler list, and forces us to consider what should be permitted on a case-by-case basis.
Note 4: Some additions to the list of permitted functions in T4.2 will probably be required in order to permit commercial “non-mapping” satellite positioning receivers as currently permitted under IARU Region 1 rules, if their use is to be permitted under Region 2 rules.