Requirements input for GAEN Application

OS versions

iOS 13.5 upwards. Android version TBC. Are there any isues with specific vendor customizations of Android?

Need a clear plan for assessing compatibility with new releases: Android 11 & iOS 14, and later when they arrive.

Devices

Assumed to be any device that supports the necessary BLE standards. How do we help users determine whether they meet the criteria?

Languages

Local languages in all target deployment areas.

Customization

HD control of strngs for e.g. next steps; HD control of risk scoring algorithms.

Branding

Change logos, colours, fonts etc.

Accessibility

WCAG 2.1: compliant to level A, and any shortcomings vs. AA standard acknowledged in a published Accessibility statement.
Also: Compliance with s508 - see: https://jimthatcher.com/sidebyside.htm

App Security

Huge topic..

• Published Threat Model, and documentation of mitigation steps taken against all identified threats

• Static code scans. Immuniweb, or commercial grade? And address what level of problems identified?

• Dynamic security testing?

• Composition analysis, & vulnerability scans.

• Defined set of security tests / scans run over each new release

• Doubtless lots more here - consult with Adam Leon Smith.

• Reporting procedures in place for external security researchers who have identified sceurity or privacy issues with the app.

Server Security

See above (App Security). SImilar list of considerations apply.

Privacy

Big topic - will discus with ALS

Privacy of individual users; of others in the community.

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.

This constraint applies for all supported devices, on the assumption that they have a battery performing at rated capacity. Aged batteries with reduced capacity may see higher levels of power consumption.

Google recommend analysis with https://developer.android.com/topic/performance/power/setup-battery-historian

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 conditions on the mobile device - running out of storage, running out of memory etc.

Any failures should be graceful and clearly flagged to the user.

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.

Likewise, even if it never has Mobile data connectivity but only WiFi (e.g. no SIM).

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.

Suggested targets:
- At least 75% of such encounters should be identified (< 25% False Negatives)
- At least 20% of ENs reported should match the above conditions (< 80% False Positives) (if this seems high, note that by casting a 60ft radius, our GPS solution generates an estimated 99% False Positives: 20 times more than this).

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.

These targets need careful review by Epidemiology Modellers / M&E experts…
(also watch out for public opinion. This research: https://www.microsoft.com/en-us/research/project/descriptive-ethics-for-covid19-apps/ suggests that the public will not download such an app if they know that it has levels of FNs & FPs this high, and they need to be much lower if the app is to be adopted).

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 (Max. 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. We need to define some targets here based on expected deployment scale.

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?
Usability - Can I do what I want to do?

Non-intrusive - doesn’t bother me when it shouldn’t.
More information - Is it clear where to find it?
Trust - The app should engender trust

Other values

The App should foster a sense of Community (e.g. how many others using it, we are all in this together etc. - see Irish app)?

Transparency: who built this? What organizations are involved?

Other values…? This paper advocates for “values in design” and mentions: Autonomy, Equity, Solidarity, Efficiency, Enconomic Well-being, Companionship, Patriotism
https://muse.jhu.edu/book/75831/pdf

Ethics

Clear plan for ensuring that the App is used Ethically by the Health Departments that we deploy it with, including checks against non-ethical use.
See e.g. Ethical Compliance Assessment for COVID Safe Paths

Polish

The app should feel polished - consistent look & feel across the app, smooth glitch-free transitions etc.

Maintainability

Code should have a low level of technical debt, and high levels of automated regression test coverage, so that bugs can be fixed, and desired enhancements implemented, without dispropritionate costs.

Diagnosability

Bugs and other problems with teh app should be quick to diagnose, with

Testability

The product should provide high levels of observability & control to testers.

There should be a clear system for distribution of builds to testers, with clear identifiers for each build, that are visible & consistent across filenames (e.g. APK or IPS files), other distribution systems (Google Beta or TF), and within the product “About” screen.

App Store processes

Ability to push out a new release, and roll back a release if needed.

Active response to negative reviews, to mitigate their impact.

CI / CD Pipeline

A CI/CD pipeline exists which allows incremental validation of each commit made.

Analytics

Analytics framework in place so that we can monitor the app for stability and other problems (e.g. crashlytics).

For Privacy reasons, we expect this to be limited in what data it collects (and in particular it will not collect any PII), and also to be opt-in only.

M&E

Strategy available, suitable for sharing with HDs, to help them to assess
1. the overall effectiveness of the GAEN solution
2, the impact of specific changes that they make to the app, or their surrounding processes.

End-user support desk

There will be a support contact in the app.

!! But who should this be plumbed through to? PathCheck? Or the HD?

L3 support plan

There will be an agreed plan for how we will deliver bug fixes to the field, including:
- A clear branching strategy for release maintenance
- A clear plan for who will be responsible for bug fixes, how we will ensure that appropriate expertise is available, and how we will manage the risk of impact on further ongoing product development.

Defect reporting

Clear channels for reporting of defects, especially privacy and security defects.

Documentation

Documentation of the application should be up-to-date, and included in the open source repo, so that it can be referenced by project contributors, and provide correct & useful information.

(we should probably also define what should be in scope fo documentaton, and what other purposes it has).

Server Patch / Upgrade

We will have well-defined and tested procedures for patch & upgrade of server systems involved in the solution.

Implementatio Collateral

All the assets needed by the Implementation team to successfully pitch the soluton, answer concerns of prospective HDs, and successfully manage rollout of the solution.