add nhsx v apple/google api comparison

might be useful for Australia, as they released an app using their own
tech so comparisons could be made to nhsx tech.

nhs-v-google-apple.md

@@ -0,0 +1,40 @@
+# Original NHSx app vs Post-may Apple/Google API-based app
+
+* NHSx app builds a database of significant contacts (<2 metres for at least 15 mins) who can be alerted if the user reports symptoms (presumably a positive test, too) (from [independent](https://www.independent.co.uk/news/uk/home-news/coronavirus-app-nhs-contact-tracing-cyber-attack-hack-a9500401.html))
+  * Users could be notified of false positive if this was found out later
+* NHSx uses a centralised model (FIXME: Find decent source and explanation!)
+  * A centralised server figures out the matching process
+    * Phone has a unique key thats sent to other devices that come in contact
+    * If the user logs positive, device tells server their key is positive
+    * Other device asks NHS server if any device keys it's received are positive (**here, the server checks for matches**)
+    * If the key is found to have logged positive, the user is alerted
+  * The server knowing if your key has come into contact with someone could pose a risk of tracking by gov/hackers
+  * Could make tracking outbreaks on a national scale easier
+  * App connected to NHS account
+  * Battery-saving features on phones (especially iPhones) could pose a challenge to keeping the service running 24/7 on the device
+    * Even if not, Apple claimed NHSx solution would be less power-efficient
+
+* Apple/Google uses a semi-decentralized model (good ass diagram [here](https://www.bbc.co.uk/news/technology-52263244))
+  * Uses BLE to reduce power usage
+  * No NHS account, name or details need to be given
+  * When two phones meet, a unique key is created and exhanged between them
+  * When one logs a positive, the user agrees to upload the key to a central database
+  * All other phones regularly download the central database, and then check (**matches are searched for on-device**) for any keys they have received from other devices
+  * If the key is in the db, the user is alerted, but the central server does not know about the match.
+
+
+
+
+
+
+
+
+
+
+
+
+### Similar between the two
+
+* Risk of high false-positives/Self-certification being used maliciously
+  * This was more of a concern when the apps were in development, as conveninent testing (LFD) was not easily available so self-cert was the most likely way to log "positive" on the app
+