I don't really agree with this assessment. The biggest problem, as you have correctly identified, is that players' information is not well recorded, very infrequently updated, and not properly accessible. A more advanced system which automated more of these tasks would be a huge boon to the airsoft community. I am envisioning a smartphone app and website. First how it works for UKARA:
- UKARA creates a database which is capable of creating and storing (in a GDPR-compliant fashion, obviously) profiles for retailers, sites and players.
- UKARA creates a web portal, with online forms, through which retailers, sites and players can fill out their information, upload supporting documentation, and view their own profile (and others', but only once the other has consented to the release only of the required information for each individual request).
- UKARA dedicates staff to manage the database and review information supplied by retailers, sites and players on initial application, and a periodic basis thereafter.
Then how it works for sites:
- The site registers with UKARA via an online form, and uploads its contact details and insurance information. This is manually inspected by UKARA staff. A site profile is created by said staff, and the details of the insurance and its expiry date logged against the site's entry in the UKARA backend. When the expiry date nears the site owner is independently notified by UKARA that its continued eligibility is contingent on supply of updated insurance documents. The site is responsible for updating UKARA as to any change in its circumstances, e.g. if it closes or opens a new location, which would be manually reviewed by UKARA staff. Each location has a unique entry in the UKARA backend.
- The site installs an app on a "site" smartphone, tablet etc., and logs in to the site's profile within the app. This app uses NFC, or scans a QR code, or similar to communicate with a player's smartphone. This doesn't need to have live internet connectivity - the app can just upload data to the UKARA database the next time it is connected to the internet. The only time it would need immediate access to the database would be to check a player's eligibility for an in-person purchase of a RIF on-site.
- This could also be of use to the site in other ways, e.g. establishing whether a player has already signed and completed the site's own insurance waivers etc. by logging that as an entry on the players' profile which is only viewable as a yes/no answer and only requestable by that site's app.
- It also removes from the site the current burden of manually entering (and updating, etc.) players' details on UKARA's system.
Then how it works for the player:
- The player registers a profile with UKARA. The usual details - profile picture, name, address, age etc. - are supplied via an online application. The player uploads their proofs of age, address etc., all of which are manually reviewed by UKARA staff. A player profile is created by said staff, and the player's details logged against this entry. The player is responsible for updating their profile as to any change in circumstances, e.g. a change in address, which will be manually reviewed by UKARA staff and require the same proofs as the original application.
- The player installs an app on their smartphone, and logs in to their profile within the app.
- When the player attends a game, the app displays their profile picture to the site staff to confirm the player is using their own profile, and uses NFC, or presents a QR code, or similar, so that the site can scan their profile using the site smartphone. This doesn't need much work to be GDPR compliant - the site app only needs to log the player's attendance, not access their personal details. The app then logs the player's attendance at a game on their profile in the UKARA backend.
- The UKARA backend then adds the player's game to a rolling list of games played, and when a deadline of a year since the last game played approaches, the player is independently notified by UKARA that their continued eligibility is contingent on playing a game soon.
- This has a significant benefit for players, who can now play at any registered site and have that logged as a game played on their profile. No more having to attend one site three times every twelve months, because your continued participation is logged every time you play at any site.
How it works for buying and selling:
- Once a player has a profile, the UKARA backend can supply information on the player's eligibility. A retailer can register a profile on the UKARA backend using the usual online form, supplying the appropriate contact details and insurance information.
- When a buyer wants to purchase a gun, the app can supply a yes/no answer as to their eligibility to purchase a RIF (or an IF, for that matter; they only need their profile to confirm they're over 18 for that and it can of course automatically update to eligible after a suitable number of games within a suitable period) to the seller.
- When a request is made by a seller - whether that's a retailer or another player - to confirm the buyer's eligibility, the buyer is asked whether they consent to the distribution of their details to the seller. For an in-person purchase the app might display the player's name, profile picture and eligibility status so the seller can confirm the buyer's identify and eligibility. For a delivery purchase the app might display the player's name, address and eligibility status, so the seller can confirm the buyer's eligibility, and that they're delivering to an address which matches the buyer's profile.
- If a sale is made, the seller could log a unique ID (e.g. one assigned to the request they used to confirm the buyer's details) against the details of the sale (in their POS software, or in a record book or something) so they could confirm in the future that they checked the buyer's eligibility before they sold to the buyer, which is the literal form of a s.38 defence.
- This includes importation. Border Force can request a player's information (name, address, eligibility status) when they detain an imported gun, to confirm those details match a registered player's profile. This would vastly speed up situations where a player's status is unclear and Border Force detains the gun until they're sure everything is in order.
I mean... Isn't the whole point of an API to access data? At this point you're more picking holes in the technological implementation than the fundamental idea, which seems to me to be perfectly sound.
Remember that I was responding to your suggestion of a scanner to swipe players membership cards.
The scanners are still a technical solution, but you have detailed a process and system.
The full process you have now given doesn’t necessarily have to rely on technology of scanners etc, but is based on the information that needs to be shared / verified at each stage.
For the API element, the point of an API is not only to enable accessing data but also to deny accessing data - ensure the right level of data access is provided to the right people
Using NFC/RFID cards needs those cards to be produced and printed for each player. Cards are cheap enough, especially in bulk but printing is expensive.
They would need an in house card printer or having them printed in batches.
With QR code’s (or barcodes, membership numbers etc) you could get away with printing on classic membership cards and laminating which allows for one off printing in house. (Though the easier the option that’s selected, the easier it is for a rogue player to create a copy with a different face)
Smartphone users could have an in app card which enables NFC/RFiD on suitable phones, or display a QR etc. But a players app needs development in both Apple and Android, has to pass approval for hosting on the App Store, and keep working when OS updates take place which means ongoing development. So you need an in-house app developer or keep the services of a commercial developer.
If you accept the potential of player fraud (swapping photo) you can have a generated email copy of the card for players to print or keep on their phone.
For the fraud part - is there a genuine problem that a player wanting to stay in date would make a fake card for a different player to swipe in as them, and at a site where nobody would be able to recognise either of them? I doubt it so the highest level of genuine card security wouldn’t be needed.
The passage of information remains the key topic, and in your process in comparison to the existing UKARA process there is just the addition of logging all games rather than just ensuring the logging of your initial qualifying 3, plus continuity qualifiers each year.
The UKARA are apparently not concerned about the players problem of private sale / self checking service or that form batches are captured in a timely manner.
An integrated solution needs development of the database, server software, site & shop software / apps and player software / apps, abs the server needs to be active for transactional or batch data transfer updates. All with either security controls to avoid a breach to wrong parts of the database and/or separate sub sets of data with the relevant fields only for each type of transaction
This will cost the money and time to develop and resources to maintain.
They don’t seem to be coping with a basic system already (or they are coping as well as suits them but not players)
