vvigor_zab_home_15kpx.jpg
Virological Intelligence Global Organisation for Research

Privacy & Ethics

vvigor_secure_data_architecture_v3_12kpx.jp2

draft: ETHICS & PRIVACY POLICY: PART 1.

Simplicity is at the core of our privacy architecture.

A. ETHICS - DOES THE VIGOR Secure APP DO GOOD?

The data that you will need to share with us in order for your VIGOR Certification to be validated and to show that it is clearly your Certificate and no-one else's will be as little as possible, it will be encrypted on your phone and and will be transmitted and stored very securely. That information will be the minimum necessary for us to ensure that your certificate was correctly validated by a medical practitioner and to enable national and international authorities to be confident that you are the holder of a valid certificate. Data that you choose to donate to assist global research will never be associated with the identity data required for your certification.

"...every action and moral choice, aims, it is thought, at some good..."
Aristoteles. “Ethics”. Apple Books. p33

This epidemiological data will be encrypted on your phone and will be uploaded to a completely different cloud data system from your certification data. You will have complete freedom to donate the data that you wish. We will ask you for your postal code in order to tap into environmental data about the area in which you live but will will not retain that postal code, it will be deleted as soon as the environmental data has been found.

We recognise the issues concerning COVID-19 Immunity-based Licensing / Passports addressed by Govind Persad, JD, PhD and Ezekiel J. Emanuel, MD, PhD on 6/05/2020 (JAMA. doi:10.1001/jama.2020.8102) namely:

(i) It may be preferable to characterise such certifications as Licenses not Passports? This is because they are likely to have a fairly short expiry date and to offer different classes or levels of COVID-19 health status, comparable with documents such as driving or aviation licenses.

As a result the personal information that you donate will not be capable of being connected back to you and your privacy will be secure.

(ii) A national government may decide to subject citizens to an examination or other additional validation procedure regarding their rights and responsibilities before awarding such a license.

(iii) Concerns regarding Ethical Values of liberty, maximising benefits, priority to least disadvantaged people and treating people equally. The authors deal with these points in their article which is summarised in fig 1 below. In summary they conclude that citizens having access to such a scheme, if well implemented, is a net benefit to society.

(iv) Persad & Emanuel raise ethical concerns over implementation regarding inaccurate antibody testing, antibodies may not indicate immunity, licenses may incentivise people to seek infection and licenses may be forged or based on false information. VIGOR addresses those concerns as follows:

(a) INACCURATE ANTIBODY TESTING: the VIGOR Secure App will use machine learning to only accept recognised tests, most likely those approved by a national government;
(b) ANTIBODIES MAY NOT INDICATE IMMUNITY: the VIGOR Secure App will use machine learning to only accept recognised tests, most likely those approved by a national government;
(c) LICENSES MAY INCENTIVISE PEOPLE TO SEEK INFECTION: the VIGOR Secure App will be bound by government policy and insofar as there is scope for inaccurate reporting or for self attestation that infection was not intentional VIGOR provides a secure validation system ensuring that only medically approved approved professionals can certify a COVID-19 event, such as a test, hospital discharge or vaccination;
(d) LICENSES MAY BE FORGED OR BASED ON FALSE INFORMATION: VIGOR will require that a mobile device, a phone or tablet running either iOS (iPhone5s or later or equivalent iPad) or Android (supported versions to be determined) incorporating a camera and a geolocation system is used to record and upload the COVID-19 event information. The cloud based system will validate the record received using the identity of the supervising professional, geolocation, timestamp and images captured by the device's camera and issue the result as a unique html file published as a web page, containing sufficient information to determine the identity of the citizen to whom it relates and the event recorded and then delete the database record. Only the participant's device will know the UUID based url of the web page result. Once the citizen has accessed the web page they can save it, print it and/or merely bring it up to display on their device. The web page contains a QR Code which automatically opens the unique web page in order to validate the certificate. Hence any inspecting person, armed with a web browser and a linked camera, can very quickly check the validity of any purported VIGOR Certificate, whether presented to them on a device or on a piece of paper, card or printed plastic. Hence an invalid QR Code will not open web page of the VIGOR server and a valid QR code being used by the wrong person will be identified because the person identified on the web page will not be the presenting individual.
vcovid_19_immunity_based_licensing_and_ethical_valuesb.jpg
Persad G, Emanuel EJ. The ethics of COVID-19 immunity-based licenses.
vcovid_19_immunity_based_licensing_implementation_concernsb.jpg
Persad G, Emanuel EJ. The ethics of COVID-19 immunity-based licenses.

B. ETHICS

DOES THE VIGOR Secure APP MEET CURRENT EUROPEAN ASSOCIATION FOR COMPUTING MACHINERY GUIDANCE REGARDING THE DESIGN AND DEPLOYMENT OF CONTACT TRACING SYSTEMS issued 5th May 2020?

Although the VIGOR Secure App does not offer a contact tracing service the ethical considerations are similar and hence this appears an appropriate up-to-date standard to apply.

ACM recommend the following principles and practices:

(i) CROSS BORDER INTEROPERABILITY (using a technical architecture that incorporates cross-border interoperability): the VIGOR Secure App is deliberately designed to use common industry standard code and systems. Insofar as unique machine learning of image identification is developed this will not in practice reduce cross border inter operability.

(ii) USER OPT IN AND OPT OUT (an opt-in mechanism for app activation and deactivation/reactivation): the VIGOR Secure App will require users to accept our privacy policy before using the App and will provide an user controlled deactivation feature. The user will be able to reactivate the App by, again, accepting the privacy policy. When deactivated the App will be reduced to its factory install state, with all data derived from past use removed and with zero ability to create any external communication.

(iii) INFORMED CONSENT (user consent to sharing personal information): the VIGOR Secure App will require the user's consent before every time the user uploads any data to our servers. At such time they will be able to review what they are proposing to send and to cancel their upload if they wish. The single caveat to this rule is that Certification data is not permitted be retained on their device, to avoid any possible analysis and reverse engineering. Hence before the test procedure is run the user will need to agree that the results will be uploaded and then removed from their device or if the upload is blocked the data will in any event be deleted. The test procedure requires a viable internet connection before it can be commenced.

(iv) SECURE DISPOSAL OR RETENTION OF PERSON DATA (either non-retention, or password protection and encryption, for all sensitive personal data): the VIGOR Secure has incorporated privacy by design and security by design from day 1 of development and security is combined with rigourously not collecting any more data than is actually required for the task at hand. Hence the VIGOR App and associated cloud services embody the following privacy protecting features:

(a) All data associated with the system is encrypted;
(b) All encrypted personal data uploaded as part of the certification procedure is deleted from the Google Cloud server as soon as the Certificate web page has been published hence the only retained data outside the user's device is that contained in the web page and that is the minimum required to identify the citizen, the event and the expiry date of the certificate. Certificates would be published from sub folders based on their expiry date hence no individual searchable records of the web pages published would be required;
(c) All encrypted personal data uploaded as part of the epidemiological research procedure is stored on an Amazon Web Services cloud system, entirely separate from the personal data used in certification. So the research data is only ever connected to the certification data whilst on the user's own encrypted device;
(d) The research data collected does include a single piece of readily identifiable personal data, the participant's postcode. This is required by the statisticians in order to obtain environmental data related to the participant's location. However, that postcode is not retained. As soon as the environmental data has been obtained the postcode is deleted.

(v) TRANSPARENCY (public disclosure of app and server source code, expert vetting of the code during development, and public disclosure of the technology's solicitation and procurement and any conflicts of interest among developers): from the outset the VIGOR Secure App has been developed as an open source public domain pro-bono project so transparency is an integral part of our policy.

ETHICS & PRIVACY POLICY: PART 2

PRIVACY - WHAT DATA DOES THE VIGOR Secure APP COLLECT, HOW IS IT PROTECTED AND HOW DOES A CITIZEN RETAIN CONTROL OF THEIR PERSONAL DATA?

A. PRIVACY - WHAT DATA IS COLLECTED?

The VIGOR project has been designed to embody principles of simplicity and transparency because we recognise the simplicity aids security, speed, usability and deliverability and transparency aids adoption through the development of trust.

Accordingly we only operate the processes and collect the data strictly required for the following purposes:

(i) to enable us to be confident that a COVID-19 event record received is valid;
(ii) to enable the person to whom the COVID-19 event record relates to be able to prove that the record applies to them;
(iii) to enable the epidemiologists and statisticians to receive high quality data whilst not receiving anything that could in any way compromise the participant's security and privacy. This means that a participant is never identified, other than in one situation. If they enroll in the follow-up study and if they wish to receive emailed reminders then their email address will we recorded in a separate management system. That will contain nothing about their anonymous identifier in the research data project, merely an email address and the month in which a reminder is due, hence this simple management system will have zero knowledge of whether the participant has responded with data or not.

We now list the data that we do obtain in each case

1. Data for Certification
[List fields]
2. Data for epidemiological research
[List fields]
3. Data for epidemiological research follow-up reminders
[List fields]

B. PRIVACY - HOW DO WE PROTECT THAT DATA?

Q1. THE REWARDS FOR CRACKING CERTIFICATES ARE CONSIDERABLE, SO THE APP WILL BE A TARGET FOR SERIOUS ATTACK. HOW HAS THE APP BEEN PROTECTED?

Agreed, this is a concern for us. At the moment the encryption in the app is around verifying signed data. We currently use SHA-512 RSA Signatures to sign data between server and client, this will be used to produce a signature to verify the certificate for example.

The test data upload will use SHA-512 RSA Encryption to make sure it is preserved during transmission and while stored on the server.

The code is modular and different algorithms or encryption methods can easily be used if needed. All encryption is done using standard C# cryptography libraries

Q2. DECRYPTED INFORMATION WOULD BE VERY EASY TO TIE UP WITH SOCIAL MEDIA INFORMATION FOR HIGH QUALITY IDENTITY THEFT OR SPEAR PHISHING.

Our privacy protection strategy requires careful thought and consideration. We have always recognised that privacy will be one of the main issues and although we want to collect good quality epidemiological data we know that if the app is shunned by the general population because of privacy concerns that will likely result in no useful epidemiological data.

We have set out our responses to initial questions raised by Dr Dan Smith below but accept that, as in any design scenario, the built outcome is based on compromises and hence can generally be refined and improved with the benefit of other's experience.

We have set out our responses to initial questions raised by Dr Dan Smith below but accept that, as in any design scenario, the built outcome is based on compromises and hence can generally be refined and improved with the benefit of other's experience.

A. CERTIFICATION DATA

Personal data is encrypted for upload and stored in an encrypted state on a secure database server while waiting to be processed. It would then be processed, the certificate would be produced and published as an HTML file on a web server and the personal data in the database would be deleted. This leaves two vulnerable areas for attack:

(i) Decrypting data while on route to or from a secure server as the certification data package does contain personal data. This as one of the most vulnerable areas of the system for attack, however it is necessary for generation of the certificate so we need to employ suitable security methods. At present we’re using encryption and database security provided by Firebase. We have also considered data sharding but we’re not sure if this is appropriate at this point. We plan to review this with UEA experts and determine the most appropriate methods.

(ii) Retrieve data from unique certificate web page - in the current model, the web page (that contains test result, passport number and name) is stored at a unique URL. At present this URL is made unique by a 32 character UUID. This web server will be made secure and will not be searchable or indexable (by either search engines externally or by internal staff). The only way to retrieve a web page is by getting the UUID - which is only stored on the person’s device. We came to the decision that a 32 character UUID is secure enough as it is impossible to guess.

(iii) Other security in place will offer protection from DDOS attacks.

(iv) We will monitor requests by IP address and apply a limit of something like 100 requests/second from a single IP. We can adjust this limit in the light of experience and also whitelist certain IP addresses (e.g. airports).

(v) If the user loses their device without recording their 32 character code they will not be able to retrieve their test certificate - they’ll be warned about this. We decided not to create a certificate account management system because this would likely create enormous overhead and complexity and make the system significantly slower and create a potential attack vector since verifying the certificate would require the password to be known it doesn’t add to the security.

B. EPIDEMIOLOGICAL DATA

(i) Basic security here comes through encryption before transit and whilst stored waiting to be processed into the data lake, if that is the ultimate depository. Once the data has been processed into the data lake the protocols for accessing data will we understand prevent searching for single individual data. This is security that will need to be built into the business processes.

(ii) We recognise the need to balance the quality of the epidemiological data with the increased opportunity that higher quality data may create for de-anonymising through pattern analysis. The data points creating vulnerability are postcode, sex, ethnicity, residence type and occupation. We have agreed with Professor Kulinskaya that we will request a participant's full postcode which will be used to add existing environmental data to the response before the postcode is deleted and not retained. Using only sex, ethnicity, residence type and occupation together with other data it will be difficult to positively identify any individual, dependent on the size and range of the data collected. Our key responsibility is to ensure that there are no data points which enable this research data to be tied back into the certification data that we are also processing. Hence our strategy of not retaining that data, only storing the certificate html pages, as described above.

(iii) The inherent security lies in the volume of data sets when combined with the absence of any specific personal identification markers being within the data donated by the participant. So the encrypted data uploaded by their mobile device will not contain any personal or device identifiers, other than their postcode which will be used temporarily before being permanently removed.

(iv) We intend that data is only released for analysis after a certain volume of responses has been received, hence ensuring a sufficient level of dilution of any individual data set.

Q3. FRAUDULENT OR COMPROMISED CERTIFICATES WOULD BE VALUABLE

(i) We’ve considered this and have tried to make them less valuable by having the certificate stored in an online web page on our server. Certificates will be very difficult to produce fraudulently in the first place, however if this scenario occurs then they could only be useful if checked by an app that is being used offline.

(ii) If our app scans a certification QR code while off-line will only be able to check encryption signatures, which could be produced fraudulently, we’ll continue to make this difficult, but it will always be possible.

(iii) However, when online our app will check the data against the online certificate. To compromise this system would mean firstly breaking all encryption and security controls to produce the off-line certificate and then also planting a valid certificate on our web servers. Also, if this were to happen, upon discovery the fraudulent certificate could simply be taken down rendering online verification useless again. While this scenario isn’t completely impossible we hope to have rendered it so difficult and so easily reversible that it makes the process less valuable to those that would attempt it.

Q4. IT WILL NEED SOME VERY SERIOUS PENETRATION TESTING IF WE'RE TO HAVE CONFIDENCE IN IT. WHAT HAVE THEY DONE?

(i) The system is under iterative development and will be ready for penetration testing soon. We regularly review our security policy and our app security implementation. We will seek out third parties to conduct an external security audit of the system and we will also be looking at penetration testing. In addition to this the app’s source code will be released under an open source license, this will allow experts from around the world to comment on and improve the code, especially the security.

(ii) The system has been designed from the ground up with security and privacy protection as the key feature. Accordingly we have separate data streams, unique IDs stored solely on the user's own mobile device and uploading only the data required for processing on the cloud server. All other processing happens solely on the user's device.

Q5. WHAT ENCRYPTION IS BEING USED? WHO HAS THE KEYS?

(i) Encryption is currently RSA SHA-512, though this has been made modular in the code and wouldn’t be difficult to change if desired.

(ii) We have created a new legal entity, Virological Intelligence Grobal Organsiation for Research Limited (VIGOR). This will hold the private keys, with directors' ultimately responsible.

(iii) We recognise that the security of the private keys is of paramount importance and we will implement a system for them to be obfuscated from all single individuals at the company. The only way to recover the keys will be to combine information held privately by at least 2 separate people, directors of the company.

Q6. VIGOR's GDPR INTERPRETATION WILL NEED SIGNING OFF BY THE DATA PROTECTION PEOPLE

(i) Our view is that if data collected can NEVER be linked to an individual, or to a household, or to a fairly exact location then it is not personal data and hence is outside the EU GDPR. We propose that this applies to the epidemiological data but not to the certification data.

(ii) The EU says: "Personal data that has been rendered anonymous in such a way that the individual is not or no longer identifiable is no longer considered personal data. For data to be truly anonymised, the anonymisation must be irreversible."

(iii) Hence our approach where we split the data stream on the user's device so that the epidemiological data can never be related or joined to the limited personal data that we do hold in relation to the Certification. Accordingly we believe that the epidemiological data should not be treated as personal data - provided it can never be related or joined to the personal data, the certification data that we do store.

(iv) If this cannot be accepted then we believe that our methods of preserving the privacy of the epidemiological data will meet the GDPR requirements. However, we note the requirement to remove personal data on the request of the data subject. That cannot apply to the epidemiological data as we do not know, and have never known, the individual to who each record relates.

(v) We agree that our interpretation will need to be signed off by those responsible.

By way of context Nick Lightbody was previously in practice as a commercial solicitor and Matthew Haughton has previously had a role as a Data Protection Officer at a college, has training in GDPR in his current professional business role and is responsible for overseeing GDPR compliance as a governor at his daughter’s school. Accordingly we look forward to engaging with the relevant data protection teams to explore our policy compliance.

ETHICS & PRIVACY POLICY: PART 3

PRIVACY - HOW DOES THE CITIZEN RETAIN CONTROL OF THEIR DATA?

When the user first installs the App, in order to start using it they need first to select the language, currently the App offers English, Polish, Chinese and Spanish and then they need to review and accept the VIGOR Privacy Policy. If it is not accepted then the App cannot be used. At any time the user can click a button which deactivates the App, after checking they really want to do this and warning that all data will be deleted and will be irrecoverable.

On restarting the App the user then has a factory settings empty App and must again select the language and accept the Privacy Policy in order to commence using the App.

vpx_trans.png
vpx_trans.png
vemail_blue2.jpg
vpx_trans.png
vpx_trans.png
vpx_trans.png
vtwitter_blue.jpg
vpx_trans.png
vpx_trans.png
vpx_trans.png
vlinkedin_blue.jpg
vpx_trans.png
vpx_trans.png