ukhsa-collaboration / covid-19-app-ios-beta Goto Github PK

Describe the bug
Uses a centralised data approach.

To Reproduce
Use the app

Expected behaviour
Privacy
Smartphone (please complete the following information):
Affects iOS and android.

Additional context
May affect chances of international travel.
https://uk.reuters.com/article/uk-health-coronavirus-europe-tech/european-coalition-takes-shape-on-coronavirus-contact-tracing-idUKKBN22J1LL

NB. This thought is a bit outside the box, it may have flaws, but was hoping to float the idea.

Apple Watch. I'm not sure exactly what percentage of iPhone users have one but I believe it could be as high as 20% Source.
How about implementing a basic Apple Watch app with complications showing a green or a red symbol almost like a traffic light to confirm contact tracing is working for the user.
This could be done with a WatchConnectivity handshake to confirm the app is still ok every time the complication updates (usually every ~15 minutes). This will mean that:

• The regular WCSession calls from watch will wake the iPhone app potentially helping the background bluetooth issues discussed in #2 !
• The user will be more engaged to keep an eye on the app.
• The user will have a visual guide that the app is working correctly.

I appreciate 20% is by no means everyone, but it could be an important number of people to make the difference on the number of devices out and about that are awake. Implementing the app would also be fairly trivial and could be simply added on as an extra for those who want it and have an Apple Watch.

As a further extension, Apple Watch devices to have access to the CoreBluetooth framework so there is a possible future to explore in using them to do some waking.

Smartphone:

• iPhone running iOS 8 & later
• Ideally Apple Watch Series 3 or greater for WatchOS 6 & CoreBluetooth, but any model will do

Describe the bug
No way to identify the commit for each release and know what fixes are included please tag releases in some way so production behaviour can be verified against the code.

Expected behaviour
Tags such as release_1.0 and release_1.0.2 should be added at the correct places.

Android devices may only support BLE receive, not broadcast. The current BLE data exchange protocol in the COVID-19 app will result in a "receive only Android device" recording the broadcast payload, but the other device will not detect or record the contact.

Steps to reproduce the behaviour

1. Install app on Samsung J6 (supports BLE scan, connect but not broadcast)
2. Install app on iPhone (supports both)
3. Run app
4. J6 should detect iPhone, but not the other way around

Expected behaviour
Both phones should detect each other to generate similar records on both phones, otherwise if the iPhone user becomes ill, the J6 user will not be notified. This is also necessary if there are any plans to switch to a decentralised model in the future.

Mitigations

1. Add write-only characteristic to enable receive only devices to submit broadcast payload via data channel (preferred option that also enable decentralisation in the future).
2. Infer symmetric contact records in central server. If the iPhone user becomes unwell and shares his/her contact records (not showing contacts with the J6), and the J6 user has already shared his/her records (showing contacts with the iPhone), the server can infer that the J6 should have been in contact with the iPhone (from the J6 records), and therefore notify the J6 user. This is a risky option, as the J6 user would not be notified if he/she has never submitted their records, i.e. they were never ill and therefore not notified.

Describe the bug
When the app is installed, but not in the foreground, the iOS device cannot connect to certain bluetooth devices at all and cannot connect to others without turning the bluetooth stack off and on again
To Reproduce
Steps to reproduce the behaviour:

1. Install NHS CoVID app
2. Make first run
3. leave bluetooth enabled
4. device will not connect to RENPHO Smart scales at all
5. device will not connect to fitbit devices without turning bluetooth off and on again
6. only permanent fix is to uninstall NHS app, at which point all functionality returns to normal.

Expected behaviour
NHS CoVid App should not affect the devices ability to connect to other bluetooth devices.

Smartphone (please complete the following information):

• Device: iPhone Xr
• OS: iOS
• Version 13.4.1
• Modem Firmware: 2.05.13

Additional context
Inability to connect to pre existing devices will cause user frustration and lead to uninstallation from device, hampering ongoing tracking efforts.

Describe the bug
I've been trying to see how the app works around the issue where an iOS app central cannot discover an iOS app peripheral on another device if they are both in the background (and/or the device is locked).

I did a lot of initial testing of this with an Apple sample project yesterday and could not find a way to make it work and am able to reproduce this problem with the COVID-19 app as well.

A few notes, I've had to make a few small mods to get the app running on my device to the point where it's actively scanning and broadcasting:

• Disabled remoteNotificationManager.configure() in the app delegate to bypass Firebase
• Faked registration by creating my own Registration, using the device advertising identifier as the UUID and a fake secret/SecKey.
• Commented out the peripheral state restoration code in the broadcaster so my two test devices always appear as new devices to each other.

To Reproduce

1. Install app on two iOS devices. In my test I'm using an iPad and an iPhone.
2. Install the app on the iPhone, launch the app and make sure its working. Kill the app, turn on Airplane mode.
3. Install the app on the iPad, launch the app, make sure its working (I'm running this one attached to the debugger so I can watch the log output). Background the app (verify using logs) and lock the device.
4. Move out of range of the iPad with the iPhone, wake the iPhone up, disable Airplane mode, launch the app, close the app, lock the device.
5. Move in to range of the iPad and observe no log output - the didDiscover delegate method is not being called on the iPad.
6. Wake the iPad screen by pressing the home button - the didDiscover delegate is called and it springs to life.

Expected behaviour
This was the behaviour I expected based on my previous testing however I was lead to believe that a way had been found around this limitation.

My understanding of the problem is thus:

• iOS apps acting as a peripheral do not broadcast their service UUID in the advertising packet while they are broadcasting in the background. The service UUID is stored in an "overflow area" to quote the Apple docs.
• iOS apps acting as a central can only find other iOS peripherals by scanning for a specific service UUID if when they are running in the background - because the other device is not broadcasting it's service UUID, it doesn't find it.
• If either app is in the foreground, the connection is made - either the central is in the foreground and is able to find the peripheral without relying on the service UUID being advertised or the peripheral is in the foreground and is broadcasting it's service UUID so the backgrounded central can find it.

Smartphone (please complete the following information):
I'm using an iPhone XS and an iPad mini 4 running the latest version of iOS 13.

EDIT - some further detailed scenarios below.

I wonder whether strolling around an army base offers a realistic test of the RSSI distance measurement issues that will be encountered in the civilian work/shopping environment

Did you also test by having subjects walking around an actual supermarket? Office and Supermarket buildings are very often constructed in a cage-like structure, with lots of steel beams and supports, and offer very different Faraday cage effects to a purely brick-built home structure (or army barrack).

Mirrors ukhsa-collaboration/COVID-19-app-Android-BETA#14 in iOS app.

https://github.com/nhsx/COVID-19-app-iOS-BETA/blob/370a51857b8a680925adc85bfc2e08936a2fd77d/Sonar/Networking/ConfirmRegistrationRequest.swift#L55-L57

According to the review here: https://osf.io/preprints/lawarxiv/6fvgh

There are several GDPR compliance problems that must be cleaned up before this app can legally be allowed to be released and used by people in the European Union.

Page 6: Deprivation of the right of erasure (GDPR, art 17)
"The NHSX App appears to deny people access to the right to erasure (also called the 'right to be forgotten') without a specified lawful reason for doing so"

"The data can be deleted as long it is on your own device. Once it is uploaded, it becomes enmeshed in wider data, and the technical difficulties of deleting it at that point become tricky"

This would be a violation of the GDPR. Since you are obliged to delete data from your system on request by the user. It would be illegal and contrary to the law itself to release an application which specifically denies this right as a purposely built in functionality.

Then there is another issue:
Page 7: Unlawful deprivation of the right of access (GDPR, art 15)

Again, contrary to the law and legal obligations.

If you continue to read this document, you find more and more privacy violations and issues with its data collection and retention techniques.

It appears that the NHS application is being built deliberately to violate that law despite it being subject to fines to do so.

It appears that the NHS is planning to just steamroll over peoples privacy with an application on the premise of a "Install it or you might die" scare tactic and bully people into giving up their rights despite laws already enacted and in place to protect those rights and in the hope that people don't file lawsuits in order to draw attention to these privacy and legal violations.

It's morally wrong to give people this choice. Install a privacy violating phone tracking application, or suffer the consequences of potentially dying.

Steamrolling over peoples rights like this cannot be allowed to become an acceptable practice and allowing this application to do that will encourage other more unscrupulous people to take things a step further.

Hello I am new to GitHub and Xcode.
I have managed to load and run the NHS tacker app via an IoS simulator on my mac book pro.
However when I try to port the App to my iPhone or iPad the build fails with these errors:

Failed to register bundle identifier. The app identifier "uk.nhs.nhsx.sonar.internal" cannot be registered to your development team because it is not available. Change your bundle identifier to a unique string to try again.

Provisioning profile "iOS Team Provisioning Profile: *" doesn't include the aps-environment entitlement.

No profiles for 'uk.nhs.nhsx.sonar.internal' were found: Xcode couldn't find any iOS App Development provisioning profiles matching 'uk.nhs.nhsx.sonar.internal'.

I am sorry if this the wrong place to ask this question but does anybody have a potential solution please.
Thank you
Regards
Ken

Describe the bug

Individuals are tracked by Google Analytics.

When accessing the Privacy Policy tracking code is passed from the application to the covid19.nhs.uk website which is processed by Google Analytics. Data captured could be used to re-identify an individual.

https://github.com/nhsx/COVID-19-app-iOS-BETA/blob/370a51857b8a680925adc85bfc2e08936a2fd77d/Sonar/Appearance/LogoStrapline.swift#L45-L48

Expected behaviour

Individuals are NOT tracked by Google Analytics

With reference to the discussion in issue #2, I have some questions:

In reality, on iOS, backgrounded services can often be killed if one launches other apps that require a lot of RAM, e.g. games, or even visiting big webpages.

I am curious to know how the effectiveness of the app's backgrounded services is monitored, if at all, outside of 'laboratory'/test conditions?

Are there any built-in (opt-in) diagnostic analytics to monitor whether this is actually working as expected/intended in real-life / in the wild, under regular users' normal usage patterns?

Or is this understanding of backgrounded services' behaviour based solely upon on observations made during test conditions?

"To measure is to know"

Thanks.

Describe the bug
Most of the view controllers in this codebase are lacking calls to super.xxx when overriding viewDidLoad and viewWillAppear. While this may not cause any obvious issues, it is against standard coding practice. Was this an intentional design, or an oversight?

Describe the bug
The README.md could be enriched with a description of the registration process. If someone could help and submit a pull request, with the changes suggestion after verification of what I say...

To Reproduce
How it works only provide very high level description.

Expected behaviour
Add a section at the end maybe...

Additional information

Registration process

• Send registration request (to Google FCM Firebase Cloud Messaging) (in Sonar/Registration/ConcreteRegistrationService.register() via notificationCenter.addObserver(forName: PushTokenReceivedNotification, ...))
  • receive FCM pushToken and call requestRegistration(pushToken)
  • send confirmRegistration/secondRegistration request (to NHS?/api/devices) with activationCode, FCM pushToken, partialPostCode (provided by user) via ResgistrationService::requestRegistration (moreover networking/RequestFactory::registrationRequest(pushToken) enrich the request with deviceModel and OSVersion before submission)
  • on response, define registration as:
    • id from response.id (provided by server)
    • secretKey from response.secretKey (provided by server), our Key?
    • broadcastRotationKey from response.serverPublicKey (after convertion by Bluetooth/BroadcastIdBroadcastRotationKeyConverter::fromData)
    • Stored in KeyChain in 2 part:
      • partialRegistration = id+secretKey (via SecureRegistrationStorage.set)
      • broadcastRotationKey (via SecureBroadcastRotationKeyStorage.save)

Describe the bug
Bluetooth capability on Android device acting as peripheral enters irrecoverable failure state after circa 700 - 1000 connect requests without disconnect from central. Bluetooth on Android may still detect connection requests but stops accepting connection, service/characteristic discovery and characteristic read/write. There is no warning from Android. The device needs to be rebooted to recover. In the COVID-19 app, this means the Android device (peripheral) will appear operational but undetectable by centrals.

To Reproduce
Steps to reproduce the behaviour:

1. Set one Android device (tested on Pixel 2) as peripheral, advertising a service and a readable or writable characteristic.
2. Set another device (Android / iOS, tested on Samsung J6 Android) as central, scanning for the service, making a connection to the peripheral and writing or reading the characteristic.
3. Repeat connect, read/write characteristic in a loop, without calling disconnect in each cycle.
4. Peripheral will eventually stop accepting connections, or even if it accepts connections, read/write characteristic will fail.
5. If step 3 is changed to include a disconnect after read/write characteristic, the cycle can run indefinitely and bluetooth will remain functional.

Expected behaviour
Peripheral should accept connect, read/write characteristics requests indefinitely, and remain robust against missing disconnect calls from centrals. This is a device / Android OS issue, but it has a direct impact on the COVID-19 app that relies on open connections and notifications for keep alive. It will mean some Android devices carried by people in high population areas will silently fail without warning, requiring device reboot.

Where can I find the source code for the version of the app that is using the Apple/Google API. Are you guys working on that too?

Hello I am trying to understand this statement

There are currently a couple of ways to do development with remote notifications:

./bin/pu.sh is a script forked from pu.sh. There are instructions there for obtaining credentials from an Apple Developer account. However, we are out of available APN keys, so you'll need to obtain that from another developer. Run the script with the path to one of the example notifications to send a remote notification through Apple: ./bin/pu.sh "Example Notifications/2_potential_diagnosis.apns. You will also need to set the following environment variables to configure the script:
TEAMID
KEYID
SECRET - the fully expanded path to the .p8 key.
BUNDLEID
DEVICETOKEN - retrieved from the console when running the application

I have found all the relevant values except for DEVICETOKEN - how do i find this please?

When do I run the pu.sh script and what does it do.

Otherwise I can build and run the app on my iPhone and iPad. However i am informed that the "App setup failed"
Does anybody have any comments on the above please?
Thank you
Ken

Describe the bug/improvement
In terms of paths to onboarding for the app, many user often download an app and possibly launch once but never even finish setup.
In this event, without the user having authorised bluetooth access and notifications, the app will not work and will have no way to tell the user it's not working.

New launch flow
Steps:

1. User downloads the app on an iPhone with iOS 12 or later (vast majority of devices)
2. On first launch of the app , it triggers something like:

if #available(iOS 12.0, *) {
            UNUserNotificationCenter.current().requestAuthorization(options: [.provisional, .alert, .badge, .sound]) { (granted, error) in
            }
        }

3. This will not trigger any notification authorisation dialogs initially
4. The app then schedules a notification (which it can cancel if onboarding completes) which reminds the user to finish setting up the app to be safe
5. Then even if the user quits before authorising full notifications, quiet notifications can still be displayed in the user's Notification Center and on the lock screen with the finish setup message

Docs
https://developer.apple.com/documentation/usernotifications/unauthorizationoptions/2993019-provisional
Smartphone (please complete the following information):
All devices running iOS 12 and later, >95% of active iOS devices

Describe the bug/improvement
A potential improvement to the app to improve the number of people who download it would be to provide statisics of the current number of infections in the users area and so the current risk to the user of contracting Covid 19.

Given that the app asks users to inform them if they have symptoms and this information is transmitted to the central server. The app could provide a report of the percentage of people who have reported symptoms in the users current vicinity in the last 10 days and the rate of increase of reports in that vicinity This could be used to provide a localised green, amber or red score for the area.

Such information would make the app more useful to people and so increase the liklihood of downloading it which makes it more effective. It would also allow people to avoid riskier areas in real time which would itself lower the rates of infection in a hotspot.

Such a feature would require the app to send location information to the server when the user reports symptoms which would need approval but most people would agree to provide this if asked.

After creating the .secret directory and copying the xconfig file I execute the make-environment script and the following is output.

steve@zephyr COVID-19-app-iOS-BETA % ./bin/make-environment < Sonar/Environments/environment.json > .secret/Environment.swift
./bin/make-environment:9:in `<main>': undefined method `result_with_hash' for #<ERB:0x007fc399a20850> (NoMethodError)

Is this a ruby version issue?