The GAEN Application & Server are just about ready for lab trials / pilots. This article tries to capture the set of additional requirements that we need to articulate and address before we are ready for production at scale.
This is a working draft, for review with other folks in test & the GAEN team. Many of the considerations probably also apply to GPS - once this article is fleshed out, we hope to copy and perform teh same exercise for GPS.
Requirement Area | Current view of requirements | Priority |
|---|---|---|
OS versions | iOS 13.5 upwards. Android version TBC. Are there any isues with specific vendor customizations of Android? | |
Devices | Assumed to be any device that supports the necessary BLE standards. How do we help users determine whether they meet the criteria? | |
Accessibility | WCAG 2.1: compliant to level A, and any shortcomings vs. AA standard acknowledged in a published Accessibility statement. | |
App Security | Huge topic.. | |
Server Security | See above. | |
Privacy | Big topic - will discus with ALS | |
Red Team | Red Team testing / Abusability Testing. | |
Battery Consumption | 24 hours of operation should not use typically use more than 10% of battery, and should not use more than 25% in the most demanding circumstances. | |
CPU. Memory etc. utilization | Should be below some reasonable limit to ensure it does not intefere with other applications (TBC what) | |
Resilience | Mobile App should be resilient to adverse condoitions on the mobile device - running out of storage, running out of memory etc. | |
Bandwidth | Mobile data used by the app should be minimal. < 1MB per day. | |
No requirement on any particular data network | The app should be fully operational even if it never has WiFi connectivity, but only Mobile data. | |
Exposure Detection Accuracy | In real world conditions, we want to identify when devices are with 6 feet of each other for > 15 mins. We consider it a False Positive if we flag an EN when this condition is not met, and a False Negative if we flag an EN when this condition is met. Our False Negative rate explicitly *excludes” cases where Exposure Detection is not expected by design: a device is powered down, has BLE disabled, does not have the App installed etc. etc. | |
Non-interference (this device) | Other uses of BLE on the device (e.g. headphones), or other RF functions (Wi-Fi, cell network) should not interfere with operation of the function. | |
Non-interference (other devices) | The function should continue to perform correctly in the context of 100s of nearby devices, all with BLE and other RF functionality (WiFi, Cell etc.) enabled. | |
Shortcomings acknowledged | We should publish clear information about the known shortcomings of the technology (e.g. may detect through walls, distance detection may be distorted in buses, it can’t tell who is wearnign face masks etc.) so that users can factor this into the use of the app, and organizations can consider supportive interventions (e.g. BLE-blockign wall coverings). | |
Server Availability / Reliability | The GAEN server should be available 99.9% of the time (40 mins downtime / month), excluding planned maintenance. Planned maintenance can occur between the hours of 12pm and 6am, and may last for up to 6 hours, subject to prior approval by Health Departments. | |
Server Scalability | Defined load. Overload. Throughput & Latency. | |
Client/Server Network Resilience | Where data network to server is poor quality, client/server comms may be delayed, but should not lead to any more severe problems. | |
Device Interoperability | The BLE exposure detection protocol should be fully interoperable between all supported devices, including Android and iOS. False Positive and False Negative rates above targets may be accesptable between individual pairs of devices as long as the overall FP & FN rates are expected to be within target, given the expected distribution of devices. | |
Interoperability between PathCheck Health Departments | ??? I believe there are no requirements here - they’d need to download a separate app for each HD? | |
Interoperability with non-PathCheck GAEN implementations | ??? I believe there are no requirements here - they’d need to download a separate app for each implementation? | |
Usability | Clarity - is it clear what it is telling me? Non-intrusive - doesn’t bother me when it shouldn’t. Community (e.g. how many others using it, we are all in this together etc. - see Irish app). | |
Polish | The app should feel polished - consistent look & feel across the app, smooth glitch-free transitions etc. | |
Maintainability | ||
Diagnosability | ||
Testability | Observation | |
App Store processes | Ability to push out a new release, and roll back a release if needed. | |
CI / CD Pipeline | ||
Analytics | ||
M&E | ||
End-user support desk | ||
Defect reporting | Clear channels for reporting of defects, especially privacy and security defects. | |
Documentation | ||
Server Patch / Upgrade |
References / useful resources
Google’s Testing Considerations for GAEN Apps: https://developers.google.com/android/exposure-notifications/testing-quality-considerations
“Quality Map” for GPS App / Server Safe Paths Quality Map (this was a resource developed for GPS, but many of the stakeholders & their needs are similar)
German GAEN App Threat Model: https://github.com/corona-warn-app/cwa-documentation/blob/master/overview-security.md
German App justification for Transmission Risk model: https://github.com/corona-warn-app/cwa-documentation/blob/master/transmission_risk.pdf
German App on Chaos Computer Club’s Privacy Requirements: https://github.com/corona-warn-app/cwa-documentation/blob/master/pruefsteine.md