Office of the Chief Information Officer delivering eHealth Ireland, Dr. Steevens? Hospital Steevens? Lane Dublin 8 Ph: 01 635 2742 Fax: 01 635 2740 27*? August 2020 FOI C20 436 Mr. Ken Foxe Email: ken?iriehttoknow.ie By email Dear Mr. Foxe, I refer to your request, which you have made under the Freedom of Information Act 2014 for access to records held by the HSE request: copies of any records held referring or relating to concerns raised in a paper by Trinity College Dublin about data sharing on the Covid?19 tracker. For avoidance of doubt, it is the academic paper referred to in the following newspaper article: irishtimes. com-"b 'trinity?researchers -auestion-data-sent? from-gooele-phone-apps-l. 43102] .7 I would prefer to receive this information electronically, ideally in its original electronic format. I wish to advise you that following consideration of the provisions of the Act I have made a ?nal decision to grant you access in full. Please find attached a schedule of records a copy all the records requested. Rights of Appeal In the event that you are not happy with this decision you may seek a review ofthis decision by writing to the Freedom of Information Unit. 3rd Floor. Scott Building. Midland Regional Hospital, Tullamorc seeking an internal review of the matter and referring to or enclosing a copy of this letter. The level ofthis has been set at (=30 and payment should be made by way of bank draft. money order, postal order or personal cheque. and made payable to Health Service Executive. Should you wish to make payment by electronic means please contact You should submit this within 4 weeks from the date of this notification. where a day is de?ned as a working day excluding the weekend and public holidays. The making of a late appeal may be permitted in appropriate circumstances. The review will involve a complete reconsideration ot'the matter by a more senior member of the staffofthis body and the decision will be communicated to you within 3 weeks. Should you have any questions or concerns please contact me at- Yours sincerely, Cathy lief/(1? F01 Decision Maker. Of?ce oft/1e Chief Information Officer Ken Forte F01 Record Date From To Hangm? Doug Leith (TC Car MacCriosta (HSE) 5mm ?0?me HSE Covid Tracker App Traf?c 0W0 "#2020 Stephen Farrell (TC D) Gar MacC riostaLHSEl HSE Covid Tracker App Traf?c 09m 7f 2 020 Doug Leith (TCD) Gar MacCriosta (HSE) HSE ovid Tracker App TralTIc 110202020 Doug Leiih (TCD) Gar MaeCriosta (HSE) HSE Covid Tracker App Certi?cate Pinn' 2107f2020 Doug Leilh Gar MacCriosta (HSE) European ('ovid Apps l2l07f2020 Doug Leilh (TCD) Gar MacCriosta (HSE) European Covid Apps Analysis 1 330102020 Gar MacCriosta App Steering Group Forwarded: Doug Leith IZFONZOZO l4f07f2020 Doug Leith (TCDJ Gar MacCriosla (HSE) HSE Covid Tracker App SSL Pinning 4r'07t2020 Muiris O'Connor (Doll) Gar MacCriosta (HSE) Requesting Meeting I #0102020 Mui ris O'Connor (Doll) Coordinate Response Requesting Meeting 1 5/030? 020 Gar MacCriosta Fran Thompson (HSE) Muiris O'Connor(DuH} Doug Con?rming meeting 510712020 Stephen Farrell (TCD) Gar MacCriusla (HSE) Confirming Availibilty and Discussing Stephen Farrell l-lS Ef?ol-l Meeting follow up 2 020 (Ear MacCriosla Meeting lbll0w up I 1707! 2020 Stephen Farrell (TCD) Meeting follow up I NOW 2020 Stephen Farrell (TC D) Meeting follow up Gar MacCriosta Do HIS FUT CD Meeting follow up WOTQOZO Stephen Farrell (TCD) HS EIDOH Meeting follow up WUTIZOZO Gar MacCriosm Meeting followup HOWE 020 Gar MaeCriosta Do HISFUT Meeting follow up I 020 Fran Thompson Gonglc HSE Covid App 81?0712020 David Burke (Google) HSE Discussing Google Privacy 81"071?2020 David Burke (Googlc) Fran Thompson (HSE) Organising Meeting 05108f2020 David Burke (Google) Frail 'l'hompsom (HSE) Meeting follow up 1) 7th July TCD 9 HSE Report From: Doug Leith Sent: 07 July 2020 16:27 To: Gar T. MacCriosta Cc: Stephen Farrell Subject: hse app traf?c CAUTION: This email originated from outside of the organisation. Do not click links or open attachments unless you recognise the sender and know the content is safe. Hi Gar, Just been having a look at the traf?c generated by the HSE contact tracing app now that its live (I've also been looking at the other apps across Europe over the last few days). I see that most of the requests (the stats and exposure check ones in particular, which are made quite frequently) carry a ?Authorization? header which has a persistent identi?er attached and so can be used to link the requests together. That makes it akin to setting a cookie. Is it intentional that requests from the same device can be linked together? If not, can it be disabled by changing the app settings? Thanks. Doug 2) 7??July TCD a HSC Report Sent: 07 July 2020 19:18 To: Stephen Farrell Cc: Gar T. MacCriosta Subject: Re: hse app traffic This email originated from outside of the organisation. Do not click links or open attachments unless you recognise the sender and know the content is safe. yes, agreed. its disappointing alright. On 7 Jul 2020, at 19:16, Stephen Farrell _rote: Hiya, Also worth noting that none of the other country's services we're monitoring require any kind of authentication for downloading TEKs. And indeed it seems kind of unnecessary to do that. I'd say removing the requirement for authorisation on that endpoint now and announcing that the client will drop the header would be a good start. That should all be easy enough. I'm not sure how easy it would be to ?x the SafetyNet stuff, but that also seems like it'd be needed to me. I'd also not be surprised if there's similar work to be done on the metrics. Cheers, S. On 07/07/2020 16:27, Doug Leith wrote: Hi Gar, Just been having a look at the traf?c generated by the HSE contact tracing app now that its live (I?ve also been looking at the other apps across Europe over the last few days). I see that most of the requests (the stats and exposure check ones in particular, which are made quite frequently) carry a ?Authorization? header which has a persistent identi?er attached and so can be used to link the requests together. That makes it akin to setting a cookie. Is it intentional that requests from the same device can be linked together? If not, can it be disabled by changing the app settings? Thanks. Doug 3) 9Lh July TCD a HSE Fr?m= Doug Leith Sent: 09 July 2020 16:40 To: Gar T. MacCriosta Cc: Stephen Farrell Subject: Re: hse app traffic CAUTION: This email originated from outside of the organisation. Do not click links or open attachments unless you recognise the sender and know the content is safe. is this connection to ?rebase a bug gar? i can?t ?nd any mention of it in the docs, and its a one off connection only. looking at the app code it seems to come from initialisation of a react native ?rebase push notifications service, but I don?t think that service is used by the ?nal app is it? i have measurements of the back end traf?c from all the european apps, apart from denmark, and am just writing that up now. would be happy to add a comment that the covidtracker ?rebase connection is made in error doug On 7 Jul 2020, at 16:29, Doug Lelth_ wrote: oh, and I guess you realise that the safetynet attestation at startup makes calls to google that send a bunch of device info, including the hardware serial number On 7 Jul 2020, at 16:27, Doug Leith wrote: Hi Gar, Just been having a look at the traf?c generated by the HSE contact tracing app now that its live (I?ve also been looking at the other apps across Europe over the last few days). I see that most of the requests (the stats and exposure check ones in particular, which are made quite frequently) 4 carry a ?Authorization" header which has a persistent identi?er attached and so can be used to link the requests together. That makes it akin to setting a cookie. Is it intentional that requests from the same device can be linked together? If not, can it be disabled by changing the app settings? Thanks. Doug 4) a Sent: 11 July 2020 18:51 To: Gar T. MacCriosta Cc: Stephen Farrell Subject: cert pinning? CAUTION: This email originated from outside of the organisation. Do not click links or open attachments unless you recognise the sender and know the content is safe. Gar, Would I be right in supposing that CovidTracker doesn't use certificate pinning for The relevant lines in the source code are commented out and I don't see any cert hashes in the apk itself. Doug 5) 12th July TCD HSE Sent: 12 July 2020 14:17 To: Gar T. MacCriosta Cc: Stephen Farrell; Brendan Jennings Subject: analysis of back end traf?c from european gaen apps CAUTION: This email originated from outside of the organisation. Do not click links or open attachments unless you recognise the sender and know the content is safe. Gar, Attached is a report on our analysis of the traffic between European GAEN-based contact tracing apps and backend servers. As might be expected, the health authority client apps are pretty well behaved, although we point out some ways that the HSE app could be improved most are obvious enough i think but we?d be happy to expand on the reasoning behind these recommendations if it would be helpful (e.g.why use of SafetyNet should be confined to TEK uploads, as is done in the Danish app for example). If an update to the HSE app is pushed out we can update the report to reflect that. The main privacy issue, however, is the intrusive behaviour of Google Play Services, which is really a good bit worse than we expected. Its hard to see how that can be ignored, especiallyas of people across Europe have installed these apps in good faith. We contacted Dave Burke about 10 days ago but have had no response, perhaps because there?s little they can say but its hard to know. I'd be interested in your own view on how best to respond to that. Might be worth having a call early next week (am cc'ing Brendan too) Regards, Doug 6) 12th July TCD 9 HSE Report From: Doug Leith Sent: 12 July 2020 14:17 To: Gar T. MacCriosta Cc: Stephen Farrell; Brendan Jennings Subject: analysis of back end traf?c from european gaen apps CAUTION: This email originated from outside of the organisation. Do not click links or open attachments unless you recognise the sender and know the content is safe. Gar, Attached is a report on our analysis of the traf?c between European GAEN-based contact tracing apps and backend servers. As might be expected, the health authority client apps are pretty well behaved, although we point out some ways that the HSE app could be improved - most are obvious enough I think but we?d be happy to expand on the reasoning behind these recommendations if it would be helpful (e.g.why use of SafetyNet should be con?ned to TEK uploads, as is done in the Danish app for example). If an update to the HSE app is pushed out we can update the report to reflect that. The main privacy issue, however, is the intrusive behaviour of Google Play Services, which is really a good bit worse than we expected. Its hard to see how that can be ignored, especially as of people across Europe have installed these apps in good faith. We contacted Dave Burke about 10 days ago but have had no response, perhaps because there?s little they can say but its hard to know. I'd be interested in your own view on how best to respond to that. Might be worth having a call early next week (am cc'ing Brendan too) Rega rd 5, Doug 7) 114ir .J ah; --??Origlnal Message-#- From: Gar T. MacCriosta Sent: Monday 13 July 2020 09:00 To: Tim.Willou hb pjakelly- Ben Clone Robert - Ton Fl nn Mooney Michael Porter rah Gibney Barry Lowry (OGCIO) Owen Harrison (0600) Muiris O'Conno Niall Sinnott Fran Thompson Subject: Fw: analysis of back end traf?c rom european gaen apps From: Doug Leith Sent: 12 July 2020 14:17 To: Gar T. MacCriosta Cc: Stephen Farrell; Brendan Jennings Subject: analysis of back end traffic from european gaen apps CAUTION: This email originated from outside of the organisation. Do not click links or open attachments unless you recognise the sender and know the content is safe. Ga r, Attached is a report on our analysis of the traffic between European GAEN-based contact tracing apps and backend servers. As might be expected, the health authority client apps are pretty well behaved, although we point out some ways that the HSE app could be improved - most are obvious enough I think but we'd be happy to expand on the reasoning behind these recommendations if it would be helpful (e.g.why use of SafetyNet should be con?ned to TEK uploads, as is done in the Danish app for example). If an update to the HSE app is pushed out we can update the report to re?ect that. The main privacy issue, however, is the intrusive behaviour of Google Play Services, which is really a good bit worse than we expected. its hard to see how that can be ignored, especially as of people across Europe have installed these apps in good faith. We contacted Dave Burke about 10 days ago but have had no response, perhaps because there's little they can say but its hard to know. I'd be interested in your own view on how best to respond to that. Might be worth having a call early next week (am cc'ing Brendan too) Regards, Doug 8) 14+h July Fr?m= Doug Leith Sent: 14 July 2020 21:46 To: Gar T. MacCriosta Cc: Stephen Farrell Subject: pinning CAUTION: This email originated from outside of the organisation. Do not click links or open attachments unless you recognise the sender and know the content is safe. apologies gar, you?re right of course that there?s cert pinning in the hse app. my mistake, i'll get the text corrected. doug 10 9) 14? July DOH HSE Sent: 14 July 2020 18:27 To: Gar T. MacCriosta Subject: FW: Request for a meeting - Friday 113m CAUTION: This email originated from outside of the organisation. Do not click links or open attachments unless you recognise the sender and know the content is safe. Ga r, deliberately didn't include you in the email below because a part of my motivation for the meeting I have requested is to ask SFI to come up with a more effective and constructive way of engaging with you as the HSE lead on the Covid Tracker App. Myself, yourself, Fran and Niall can have a huddle before this meeting by way of preparation. Chat soon, Muiris ?uiris O'Connor Assistant Secretary, and Health Analytics Division El Rolnn Slalnte Department of Health Bloc 1, Plaza Miesach, 50 - 58 Sraid Bhag?id iochtarach, Baile Atha Cliath, 002 XW14 Block 1, Miesian Plaza, 50 - 58 Lower Baggot Street, Dublin, DOZ XW14 11 10) 14"-uly SFI Coord mate Response Message-? From: Muiris O'Connor Sent: Tuesday 14 Jul 2020 18:23 To: Michael Ryan iaran Seoighe Noel O'Connor 'Brendan Jennings'?Kim Lavelle Dolores Mel ar? Cc: Fran Thompson Barry Low Niall Sinnott Sarah Gibnev Subject: Request for a meeting - Friday llam Dear Michael, Ciaran and SFI colleagues, Further to your meeting with Sarah and Gar last week and Gar's subsequent receipt of the attached paper, I would like to hold a meeting with you to understand the status of this paper in the context of your very welcome and proactive support for the Irish health service's sincere efforts to utilise science and technology as part of our national response to Covid-19. As you know, we are committed to working with you on a range of work programmes relating to the development, deployment and further re?nement of the Covid Tracker App. I know that you have worked on this and in other areas to assemble teams of experts under key headings of immediate relevance and interest in the context of the unprecedented health challenges experienced here and internationally over recent months. Once again, Douglas Leith and Stephen Farrell have bounced a paper to Gar, which contains a range of sweeping presumptions and assertions relating to the privacy of the app. Although framed in the format of a scientific paper, it is journalistic in much of its narrative; it is incorrect on certain key points and it is unclear how and whether it has been peer-reviewed. It is also unclear to us how this work fits into the wider SFI exercises such as the review of our code base and the work on the Exposure Notification Services. A meeting this week would be much appreciated. I have a zoom call set up (details below) for 11am on Friday but have wider availability on Friday morning if there is another timeslot that works better for you. If Friday doesn't suit, please suggest further options. Kindest regards, Muiris inuiris O'Connor Assistant Secretary, and Health Analytics Division An Roinn Sla'inte Department of Health 12 11) 15?" July HSE 9 From: Gar T. MacCriosta Sent: 15 July 2020 17:01 To: Fran Thompson; Muiris_0Connor- Brendan Jennings; Noel O'Connor; Douglas Leith; Stephen Farrell Sublect: TCD Paper Review Hi all I'm hoping we can set up a meeting in advance of publication of Doug/Stephen's paper to understand and provide feedback and clari?cations. I?ve been struggling to ?nd a time, does Friday 17th suit for 30 mins. Sl?n Gar 13 12) 15'th July TCD a From: stephen Farrel Sent: 15 July 2020 17:53 To: Gar T. MacCriosta; Fran Thompson; Muiris_0Connor_ Brendan Jennings; Noel O'Connor; Douglas Leith Subject: Re: TCD Pa per Review Hiya, Friday 10:30 works for me. On 15/07/2020 17:01, Gar T. MacCriosta wrote: all I'm hoping we can set up a meeting in advance of publication of Doug/Stephen's paper Great, we?d like that too. To be open: I think that if the upshot of that was "the HSE have said they plan to change a,b,c" that'd be great from my POV. Where a,b,c might be roughly: a using the refreshToken/authToken for getting TEKs since they act as a cookie drop the leftover ?rebase call think whether or not SafetyNet is needed (it may only really be needed e.g. when uploading the code and keys) and whether/how to split the metrics into non-medical and medical security contexts (Doug - please chime in there if I've missed anything.) I'd guess a should be straightforward. might need a bit more chat. That leaves the question of how to handle the leaks out of GPS, which I don't expect the HSE to be able to ?x of course. Though maybe HSE+other GAEN app owners working together might add up to enough leverage to get that sorted out? The mail infrastructure thing is probably a different set of people on a different call so we can probably leave that alone Friday unless you wanna cover it too. And I would encourage DNSSEC too - you never know when a DNS registrar might get borked;-) to understand and provide feedback and clarifications. Hopefully we have most of 'em handled already. (Esp pinning, where we've ?xed our text.) Will send the latest text to this list tomorrow sometime. But comments by mail are most welcome in the meantime too. 14 Cheers I've been struggling to ?nd a time, does Friday 17th sult for 30 mins. Sl?n Gar 15 13) 17thluly TCD a Hsr/DoH From: Stephen Farrell Sent: 17 July 2020 20:51 To: Gar T. MacCriosta; Fran Thompson; Muiris_0Connor- Brendan Jennings; Noel O'Connor; Douglas Leith Subject: Re: TCD Paper Review Hiya, Enjoy the time off! We've tried to address the points below in our latest text. Hopefully you'll agree when it pops out;-) FWIW, i think the only one where i'd disagree with how you characterise things is the assertion that users have consented to GPS telemetry already that may be the legal fiction on which the s/w biz depends, but it is nonetheless, a fiction. But that's not the HSE's fault and there's nothing you could do about it. Cheers, S. On 17/07/2020 20:39, Gar T. MacCriosta wrote: Hi all Thanks for the update Stephen, here are my notes and takeaways. I?m 000 until 27th will follow up when I return. Gar Tracker Recommendations Firebase library reference - removed resolved Apply separate security context for metrics (app contact tracing metrics) to be reviewed by COVID Tracker team Evaluate use of SafetyNet use; recommend only using for TEK uploads under review will review with COVID Tracker team and via eHealth Network with EU counterparts in Germany, Italy and Denmark Reevaluate implementation of authorisationToken and refreshToken under review will review with COVID Tracker team and via eHealth Network with EU counterparts in Germany, Italy and Denmark Google Requests Provide better documentation on GAEN HSE to follow up with Google/Apple and request timeline on release of documentation Provide a quiet mode for Google Play Services that reduces the data shared with Google - HSE to discuss with Google Clarify the future governance of GAEN as a piece of global health infrastructure HSE to raise with Google/Apple and raise in EU eHealth Network as a matter for discussion HSE Requests for Clari?cation 16 Clarify the context for the development of the COVID lracxer app and the GAEN API in the paper Development was done in response to a global COVID-19 pandemic that was shutting down societies GAEN in development since Feb/March 2020 - at the time number of cases rising sharply globally and timely response was essential Timeliness in?uenced design choices for both Apple Google, the selection of Googie Play Services as a vehicle for delivery of GAEN has consequences Google Play Services is an existing Google service and was used as a vehicle to deploy GAEN to Android devices Google Play Services had an existing set of metrics telemetry that were collected prior to the release of GAEN with the consent of users According to Google GAEN does not have access to the Google Play Services data [listed in the doc) nor do the apps that are entitled to use GAEN including COVID Tracker HSE as a health provider were challenged with providing a solution that could work on the vast majority of devices. At time of writing this still remains the only viable option to deliver apps like this. Sent: 17 July 2020 12:41 To: Gar T. MacCriosta; Fran Thompson; Muiris_0Conno- Brendan JenningS; Noel O'Connor; Douglas Leith Subject: Re: TCD Paper Review 17 14) 17?? July HEE 9 From: Gar T. MacCriosta Sent: 17 July 2020 14:54 To: Stephen Farrell; Fran Thompson; Muiris_OConnor- Brendan Jennings; Noel O'Connor,- Douglas Leith Subject: Re: TCD Paper Review thanks Doug and Stephen, appreciate you both sharing your concerns and listening to ours I'll send my notes on later today. Slan Gar 18 15) 17?" July TCD 9 From: Stephen Farrell Sent: 18 July 2020 00:25 To: Fran Thompson; Gar T. MacCriosta; Doug Leith Cc: Muiris_OConnor Brendan Jennings; Noel O'Connor Subiect: Re: TCD Paper Review Hiya, On 18/07/2020 00:03, Fran Thompson wrote: Doug Steven Thanks for the additional info and for the call today. I found it informative and it was good to understand your perspective. Agreed. I found almost all the conversation very useful, so thanks for that. As you may know both Gar and myself are on a weeks leave Again - Enjoyl but we are going to review the Information you both provided, as an ytial step Gar will touch base with a number of other EU countries to better understand the their rational for making their decisions on app security. I wouldn't over-emphasise urgency in that (meaning for this discussion) - my own guess is that there's some time to go before RSSI handling will be approaching optimal, and we're not yet there, and "optimal" may not turn out that good anyway, sadly. From the POV of dealing with our report, it is entirely suf?cient for now to say that you've said you want to consider the issues and let the handling of those pan out as it does. {That said, please do try ditch the cookie as soon as you can - it'll be a good thing you'll enjoy having done, and i'li be delighted to offer praise then:-) I must confess to having a strong emphasis on security of the back end thus driven a number of the design decisions in a certain direction but i am open to review provided this does not compromise our objectives namely strong functional requirements combined with privacy and security. Sure. We have some measurements of TEK publication running and have published the scripts for that. Yours is the only service requiring a local file (with a refreshToken value) that cannot be pushed to github. All of the rest are 19 openly accessible over the Internet without any such need. I suspect that AWS can handle the level of chaff/spam you might see related to this app TBH. I'd not be surprised if they didn't really notice should an Irish-focused entity try such an attack. Ingi i. VCN?jifNX?pY?th 8a. =hitp?13a?zf?f-?EE?git?u Diagram nip at On the Google and Apple front we will engage with them on our return from leave to share the concerns raised. Yep. That'll not be a weekend exercise. I'd be very happy to support efforts to help them improve. Like all orgs they have many good-actor employees but can corporately do the wrong thing. I will keep the SH team updated on developments. As you appreciate this is a public health emergency and we do not have time for perfect solutions. we must act now and make compromies, however we can improve as we progress. We will aim to have app that is acceptable for all who choose to use it. Again thanks for the open and frank discussions today. Indeed. In my experience We always learnt from Openly discussing with people whose opinions diverge from my own. Maybe someday I'll even get wise based on that;-) Cheers, S. Regards Fran The HSE's Office of the Chief Information Officer, Delivering Fran Thompson Interim Chief Information Of?cer Original message From: "Gar T. MacCriosta" 20 17/07/2020 20:59 To: Doug Cc: Stephen Fran Thompson Brendan Jennings Subject: Re: TCD Paper Review Muiris_OConn Noel O'Connor thanks for sharing Doug we will raise with Google and share if we get more info From: Doug Leith Sent: 17 July 2020 20:57 To: Gar T. MacCriosta Cc: - an Thompson; Muiris_OConnoWrendan Jennings; Noel O'Connor Subject: Re: TCD Paper Review CAUTION: This email originated from outside of the organisation. Do not click links or open attachments unless you recognise the sender and know the content is safe. Thanks Gar. One more thing to add to this. In Google's recent response to us they say: "We do collect telemetry data from the EN API, and the goal of that is to verify that basic functionality (Le. the EN mechanism) is working and to provide an early warning signal to investigate speci?c device models in the event of any problems. No user-identifying information of the EN system is logged by design (the public health authority is the GDPR controller here)." and a bit later they add more detail: "So far, the telemetry has helped us to identify critical early issues in EN deployments around the world. We found issues with the signing of keys HA apps download from the server. We were able to identify device models that did not support the initial version of EN due to lack of support of BLE multi-advertising and work around this limitation. We were able to ensure that supported device models perform BLE scans often enough for the system to be effective.? I told Google l'd share that with you, so consider it shared. I guess its clear, but its relevance to our discussion is that it con?rms that the data sharing with Google speci?cally includes data related to operation of the Exposure Notification service, in addition to all the usual stuff Google Play Services may do. i found the fact that they mention public health authority as data controller a bit curious, I guess the implication is that the data is anonymous so consent is not needed, but that's just supposition by me. Also, maybe that means this data sharing should be included in the DPIA and like paperwork, but over to you on that. Doug On 17 Jul 2020, at 20:39, Gar T. MacCriost? wrote: Hi all Thanks for the update Stephen, here are my notes and 21 takeaways. I'm 000 until 27th will follow up when I return. Slan Gar COVID Tracker Recommendations - Flrebase library reference - removed resolved 0 Apply separate security context for metrics (app contact tracing metrics) - to be reviewed by COVID Tracker team 0 Evaluate use of SafetyNet use; recommend only using for TEK uploads - under review will review with COVID Tracker team and via eHealth Network with EU counterparts in Germany, Italy and Denmark . Reevaluate implementation of authorisationToken and refreshToken - under review will review with COVID Tracker team and via eHealth Network with EU counterparts in Germany, Italy and Denmark Google Requests 0 Provide better documentation on GAEN - HSE to follow up with Google/Apple and request timeline on release of documentation . Provide a quiet mode for Google Play Services that reduces the data shared with Google - HSE to discuss with Google 0 Clarify the future governance of GAEN as a piece of global health Infrastructure - HSE to raise with Google/Apple and raise In EU eHealth Network as a matter for discussion HSE Requests for Clari?cation - Clarify the context for the development of the COVID Tracker app and the GAEN API In the paper 0 Development was done in response to a global COVID-19 pandemic that was shutting down societies - GAEN in development since Feb/March 2020 - at the time number of cases rising sharply globally and timely response was essential - Timeliness influenced design choices for both Apple Google, the selection of Google Play Services as a vehicle for delivery of GAEN has consequences 0 Google Play Services is an existing Google service and was used as a vehicle to deploy GAEN to Android devices - Google Play Services had an existing set of metrics telemetry that were collected prior to the release of GAEN with the consent of users 0 According to Google GAEN does not have access to the Google Play Services data (listed In the doc) nor do the apps that are entitled to use GAEN including COVID Tracker - HSE as a health provider were challenged with providing a solution that could work on the vast majority of devices. At time of writing this still remains the only viable option to deliver apps like this. From: 12:41 To: Gar T. MacCriosta- Fran Thompson; Brendan Jennings; Noel O'Connor; Muiris_OConnorm Douglas Leith Su Ject: e: aper Review 22 1(5) .17" TCD a Sent: 17 July 2020 12:41 To: Gar T. MacCriosta; Fran Thompson; Muiris_OConnor-Brendan Jennings; Noel O'Connor; Douglas Leith Subject: Re: TCD Paper Review CAUTION: This email originated from outside of the organisation. Do not click links or open attachments unless you recognise the sender and know the content is safe. 23 17) 17th July l-lSE a HSE Meeting Notes Follow?up From: Gar T. MacCriosta Sent: 17 July 2020 20:39 To: Stephen Farrell; Fran Thompson; Muiris_OConnor? Brendan Jennings; Noel O'Connor; Douglas Leith Subject: Re: TCD Paper Review HI all Thanks for the update Stephen, here are my notes and takeaways. l'm 000 until 27th will follow up when I return. Sl?n Gar COVID Tracker Recommendations 0 Firebase library reference - removed resolved . Apply separate security context for metrics (app contact tracing metrics) - to be reviewed by COVID Tracker team . Evaluate use of SafetyNet use; recommend only using for TEK uploads - under review will review with COVID Tracker team and via eHealth Network with EU counterparts in Germany, Italy and Denmark . Reevaluate implementation of authorisationToken and refreshToken - under review will review with COVID Tracker team and via eHealth Network with EU counterparts in Germany, Italy and Denmark Goggle Reguests . Provide better documentation on GAEN - HSE to follow up with Google/Apple and request timeline on release of documentation . Provide a quiet mode for Google Play Services that reduces the data shared with Google - HSE to discuss with Google . Clarify the future governance of GAEN as a piece of global health infrastructure - HSE to raise with Google/Apple and raise in EU eHealth Network as a matter for discussion HSE Rguests for Clarification . Clarify the context for the development of the COVID Tracker app and the GAEN API in the paper . Development was done in response to a global COVID-19 pandemic that was shutting down societies . GAEN in development since Feb/March 2020 - at the time number of cases rising sharply globally and timely response was essential . Timeliness influenced design choices for both Apple Google, the selection of Google Play Services as a vehicle for delivery of GAEN has consequences . Google Play Services is an existing Google service and was used as a vehicle to deploy GAEN to Android devices 24 25 Google Play Services had an existing set of metrics 8: telemetry that were collected prior to the release of GAEN with the consent of users According to Google GAEN does not have access to the Google Play Services data (listed in the doc) nor do the apps that are entitled to use GAEN including COVID Tracker HSE as a hearth provider were challenged with providing a solution that could work on the vast majority of devices. At time of writing this still remains the only viable option to deliver apps like this. 18) 17?h July a From: Stephen Farrell Sent: 17 July 2020 12:41 To: Gar T. MacCriosta; Fran Thompson; Muiris_OConnor_Brendan Jennings; Noel O'Connor; Douglas Leith Subject: Re: TCD Paper Review Hi all, Thanks for the call this momlng. My ta ke-aways for things-to-do on our side below plus one note about a detail we didn't cover. Comments welcome if I missed something or mucked up describing things (which happens all the time:-) Things-to-do: - add a note after the discussion of covidtracker in the intro that we chatted and that "the HSE have acknowledged the issues described here and have said they'll work to address them (though of course they may not agree with our recommendations)." Happy to accept suggestions if there's a better way to say that - ack that you have a plan for issue tracking that just hasn't landed yet - provide some more context in the intro all this happening speedily during a pandemic - add some recommendations for what to do about the GPS issues (docs, "quiet" button, governance) at the end The thing we didn't cover: the requestToken/authToken cookie is also used on the "checkin" and metrics APIs. That's a bit more defensible than having it on the TEK download, as the user has opted-in to that, but I'm unclear if you want or need to be able to correlate that a sequence of metrics or checkins comes from one handset/person, and it's not (afaics) clear from your documentation either, though I may have missed it being somewhere there. I'd say in removing the cookie from the TEK download API (as I hope you'll you probably also wanna consider if you do need that cookie for metrics/checkins or not and if you do, make sure that the documentation is clear that opting-in means all the metrics/checkins uploaded can be correlated (and/or that even though you could correlate, you ditch that info, same as with IP addresses). FWIW, I think it'd be better from a protocol- privacy POV if you could not correlate those, and I suspect it might lead to more people opting-in if you cannot, but I don't know whether the backend use of that data requires correlation over time. 26 Cheers, S. If you don't need the correlation but do want some anti-spam measure, I'd be happy to chat about designs If you want - could be that the Danish "everyone uses the same cookie? approach with a time-based tweak could do the Job for example. Though you'd need to think ab0ut replay?detection a bit esp if you will support QUIC over dlfferent data-centres. 27 19) 17Th July HSE From: Gar T. MacCriosta Sent: 17 July 2020 20:39 To: Stephen Farrell; Fran Thompson; Muiris_OConnor_ Brendan Jennings; Noel O'Connor; Douglas Leith Subject: Re: TCD Paper Review Hi all Thanks for the update Stephen, here are my notes and takeaways. I'm 000 until 27th will follow up when I return. Slan Gar COVID Tracker Recommendations Firebase library reference - removed resolved Apply separate security context for metrics (app contact tracing metrics) - to be reviewed by COVID Tracker team Evaluate use of SafetyNet use; recommend only using for TEK uploads - under review will review with COVID Tracker team and via eHealth Network with EU counterparts in Germany, Italy and Denmark Reevaluate implementation of authorisationToken and refreshToken - under review will review with COVID Tracker team and via eHealth Network with EU counterparts in Germany, Italy and Denmark Google Reguests Provide better documentation on GAEN - HSE to follow up with Google/Apple and request timeline on release of documentation Provide a quiet mode for Google Play Services that reduces the data shared with Google - HSE to discuss with Google Clarify the future governance of GAEN as a piece of global health infrastructure - HSE to raise with Google/Apple and raise in EU eHealth Network as a matter for discussion HSE Requests for Clarification 28 Clarify the context for the development of the COVID Tracker app and the GAEN API in the paper Development was done in response to a global COVID-19 pandemic that was shutting down societies GAEN in development since Feb/March 2020 - at the time number of cases rising sharply globally and timely response was essential Timeliness in?uenced design choices for both Apple Google, the selection of Google Play Services as a vehicle for delivery of GAEN has consequences Google Play Services is an existing Google service and was used as a vehicle to deploy GAEN to Android devices . Google Play Services had an existing set of metrics telemetry that were collected prior to the release of GAEN with the consent of users . According to Google GAEN does not have access to the Google Play Services data (listed in the doc) nor do the apps that are entitled to use GAEN including COVID Tracker . HSE as a health provider were challenged with providing a solution that could work on the vast majority of devices. At time of writing this still remains the only viable option to deliver apps like this. Sent: 17 July 2020 12:41 To: Gar T. MacCriosta; Fran Thompson; Muiris_OConno_ Brendan Jennings; Noel O'Connor; Douglas Leith Subject: Re: TCD Paper Review CAUTION: This email originated from outside of the organisation. Do not click links or open attachments unless you recognise the sender and know the content is safe. 29 20?- My llSE 9 From: Gar T. MacCrlosta Sent: 17 July 2020 20:58 To: Stephen Farrell; Fran Thompson; Muiris_OConnor_ Brendan Jennings; Noel O'Connor; Douglas Leith Subject: Re: TCD Paper Review thanks Stephen I get where you are coming from and appreciate that you don't agree. Enjoy the weekend Sl?n Gar From: Stephen Farrell Sent: 17 July 2020 20:51 To: Gar T. MacCriosta; Fran Thompson; Muiris_OConnor_Brendan Jennings; Noel O'Connor; Douglas Leith Subject: Re: TCD Paper Review Hiya, Enjoy the time offl We've tried to address the points below in our latest text. Hopefully you'll agree when it pops out;-) FWIW, I think the only one where I'd disagree with how you characterise things is the assertion that users have consented to GPS telemetry already - that may be the legal fiction on which the s/w biz depends, but it Is nonetheless, a fiction. But that's not the HSE's fault and there's nothing you could do about it. Cheers, 5. On 17/07/2020 20:39, Gar T. MacCrlosta wrote: Hi all Thanks for the update Stephen, here are my notes and takeaways. I'm 000 until 27th will follow up when I return. Sl?n Gar Tracker Recommendations 30 Firebase library reference removed resolved Apply separate security context for metrics (app contact tracing metrics) - to be reviewed by COVID Tracker team Evaluate use of SafetyNet use; recommend only using for TEK uploads under review will review with COVID Tracker team and via eHealth Network with EU counterparts in Germany, Italy and Denmark Reevaluate implementation of authorisationToken and refreshToken - under review will review with COVID Tracker team and via eHealth Network with EU counterparts in Germany, Italy and Denmark Google Requests Provide better documentation on GAEN - HSE to follow up with Google/Apple and request timeline on release of documentation Provide a quiet mode for Google Play Services that reduces the data shared with Google - HSE to discuss with Google Clarify the future governance of GAEN as a piece of global health infrastructure - HSE to raise with Google/Apple and raise in EU eHealth Network as a matter for discussion HSE Requests for Clari?cation Clarify the context for the development of the COVID Tracker app and the GAEN API in the paper Development was done in response to a global COVID-19 pandemic that was shutting down societies GAEN in development since Feb/March 2020 - at the time number of cases rising sharply globally and timely response was essential Timeliness in?uenced design choices for both Apple 8: Google, the selection of Google Play Services as a vehicle for delivery of GAEN has consequences Google Play Services is an existing Google service and was used as a vehicle to deploy GAEN to Android devices Google Play Services had an existing set of metrics telemetry that were collected prior to the release of GAEN with the consent of users According to Google GAEN does not have access to the Google Play Services data (listed in the doc} nor do the apps that are entitled to use GAEN including COVID Tracker HSE as a health provider were challenged with providing a solution that could work on the vast majority of devices. At time of writing this still remains the only viable option to deliver apps like this. From: Stephen Farrell Sent: 17 July 2020 12:41 To: Gar T. MacCriosta; Fran Thompson; Muiris_0Connor- Brendan Jennings; Noel O'Connor; Douglas Leith Subject: Re: TCD Paper Review CAUTION: This email originated from outside of the organisation. Do not click links or open attachments unless you recognise the sender and know the content is safe. Need information and advice on Go to 9 A3 a 97;; firux-VW i? 56? 92.3 i 92i?r?71p Kngr?CngahggliAozuzl 31 an fhaisnOls sa rOomhphost seo (ceangalt?in san OIreamh) faoi rOn. Baineann SO leis an t6 ar seoladh chuige athin agus to so ar intinn go bhfaigh?dh siadsan athin 9 agus gurb iadsan athin a dhOanfaidh breithnlO air. M05 rud nach tusa an duine ar leis 0, to cosc iomiOn ar aon fhaisnois atO arm, a Os?id, a chraobhscaoileadh, a scaipeadh, a nochtadh, a fhoiisi?, no a chineOil . Seains gurb iad tuairimO pearsanta an Oder ato san rOOmhphost agus nach tuairimo FSS lad. MO fuair t0 an rOOmhphost seo trO dhearmad, bheadh muid buOoch d0 gcuirfe? in iOil don Deasc SeirbhOsO ECT ar an nguthQn ag +353 818 300300 no ar an r?omhphost chuig service. desk@hse.' le< .- agus ansin glan an r?omhphost seo ded' choras.? "Information in this email (including attachments) is confidential. It Is intended for receipt and consideration only by the intended recipient. If you are not an addressee or intended recipient, any use, dissemination, distribution, disclosure, publication or copying of information contained in this email is strictly prohibited. Opinions expressed in this email may be personal to the author and are not necessarily the opinions of the HSE. If this email has been received by you in error we would be grateful if you could immediately notify the ICT Service Desk by telephone at +353 818 or by email to and thereafter delete this e-mail from your system" 32 21) 18?h July HSE 9 Google On Sat, Jul 18, 2020 at 2:13 AM Fran Thompson wrote: Dave, We have not been introduced but Ireland, Gar has been dealing with you and the team for the past few weeks. I would like to thanks you and the whole Google team for the help, support, guidance and hard work to get this project over the line. The launch has been an enormous success and had been accepted as such widely in the press, social media and Government. Our app build on your technology augments our existing efforts which our testing and tracing functions and as such are another part of our armoury to manage and reduce the spread of Covid. Success always brings challenges and one of these is how we accommodate people who want to remain fully private and do not want anyone to know about them a real challenge for both of us. I am on leave next week would welcome a discussion when I am back to explore with you a number of topics this including 1. Future Releases of ENS 2. Other initiatives that support Covid efforts 3. Speed of releasing Apps through the playstore review process Again thanks for all the support in getting our app live. Regards Fran 33 From: Gar T. MacCriosta? Sent: Saturday 18J To: Fran Thompson Ben Cloney Subject: Fwd: Another report on covid tracing apps FYI Sent from my iPhone Begin forwarded message: Date: 18 July 2020 at 05' To: "Gar T. MacCriosta" Cc: Yul Kwon Subject: Fwd: Another report on covid tracing apps This email originated from outside of the organisation. Do not click links or open attachments unless you recognise the sender and know the content is safe. FYI Forwarded From: Dave Burke Date: Fri, Jul 17, 2020 at 9:10 PM Subject: Re: An To:DougLe?h Cc: Ste hen Farrell Vint Cerf Ted Hardie I oug, Only getting a chance to respond We regard Google Play services as an intrinsic part of the phone?s operating system. Running with Play services disabled, while possible, is not a recommended con?guration for regular users and it?s important to note that many key aspects of the system will fail to work in that con?guration. For example, Google Play services handles system/security updates to keep the phone updated with the latest system security patches to protect the user. Play services provides app malware scanning viaPIay Protect. Play services provides emergency location services so emergency responders can locate you accurately when dialing the emergency number. Play services also provides a range of core functionality needed for normal operation of the phone and apps such as account authentication, push notifications, location services, etc. Incidentally, Google location services can be switched off independently (with no bearing on EN) via the Location settings, including: 34 . Google Location Services (aka Google Location Accuracy) which uses data anonymously to improve the accuracy of location provided to any apps or services with the location permission . Google Location History, an opt-in, account level setting that provides users with features such as personalized maps and recommendations based on places they?ve visited. Back on the topic of EN, the reason the EN module ships in Google Play services is because it?s an updatable part ofthe operating system, thereby enabling us to make EN available to all devices quickly, and update the EN module based on the rapidly changing understanding of epidemiology and feedback from health authorities. For example, this week we launched with new features based on feedback from several European health authorities. Aside: as promised earlier, we now publish release notes and the EN settings include the version number for comparison. In terms of public documentation, as mentioned in a previous discussion we have been working on writing documentation on the implementation details, along with key source code, and information on EN telemetry (including the information above about the pipeline that does not log IP addresses). This will go out at the start of the week. I?m happy to send you a pointer so you can reference it. Dave On Fri, Jul 17, 2020 at 1:15 AM Doug Leith? wrote: Dave, Thanks for getting back to us on this, much appreciated. Following up on Stephen?s response (sorry for the slow reply, I took a break from things yesterday) I will say that much of what you report on here has little bearing on our partnership with Apple to provide technology for countries like Ireland to successfully implement mobile exposure notification to combat There is no connection between your general observations about Android telemetry and using exposure noti?cation apps. That doesn?t seem quite right to me so, if I may, here?s my chain of thought - so you can point out where you see it going wrong. As I understand it because EN is part of Google Play Services, anyone using an EN-based contact tracing app on Android must enable Google Play Services. Enabling Google Play Services results in various communications between GPS and Google backend servers to happen (we can come back to the details of what those requests are). For example, someone wanting to use the Irish contact tracing app but who previously kept GPS disabled (such as myself) has to enable GPS ifthey want to use the app. That seems the crux ofthe matter to me, have I misunderstood If that?s right, then the logic is that connections made by GPS are indeed linked to use of EN, since EN is part of GPS and can't be used separately from it. That seems clear enough to me, but if I have it wrong please do correct me. I understand that EN is a separate software component within GPS, but if one can't be used without the other then it seems to me that 35 distinction isn't really relevant for users. If that's right, then the more Important question for me is what connections are made by GPS when minimally con?gured (minimal in the sense that its just enough to allow a contact tracing app based in EN to be used), and how to con?gure GPS in that minimal way. I don?t really have full answers to either of those, just what I see when I take measurements on the handset I have when I?ve tried to minimally configure it. If you're agreeable I think it? be useful if you guys could engage with us on how to minimally con?gure GPS and on what connections, if any, are made when minimally configured. If it would be helpful we might organise a short call (the bandwidth is much higher than these slow email exchanges). We do collect telemetry data from the EN API, and the goal of that is to verify that basic functionality the EN mechanism) is working and to provide an early warning signal to investigate speci?c device models in the event of any problems. No user-identifying information of the EN system is logged by design (the public health authority is the GDPR controller here). To be honest, that's the first time I?ve heard anyone say that. Its not written in the DPIA of the Irish app as far as I?m aware although I haven?t read it super carefully - I understand that?s probably their problem, not yours, so I?ll follow up with them. Deidenti?ed log messages, such as whether BLE functionality is working, are uploaded to Google In such a way that no persistent or pseudonymous identifiers are associated with the log message. This logging system also explicitly breaks any link between log messages from the same device. Further, identi?ers such as IP addresses that are required to deliver the log message are not logged to disk in this logging pipeline. Thanks for that, that? 5 good to know and helpful. Can you point me towards docs with more details on the identifiers used and how the logging system breaks the link to the device as you know the devil is in the detail with these things. If you're agreeable, maybe I could also share details of the potential identifiers I see within messages sent by GPS and you guys can clarify how they are generated and the way that the link with the device is broken Regarding scrubbing of IP addresses from log messages in particular, that seems a important point to me. GPS makes connections to Google servers really quite frequently and its not clear to me why they need to be so frequent. When I read the Google privacy docs I ?nd online they seem to say pretty clearly that IP addresses are used to estimate location (we quote those docs in our report, so you check there to see the ones I mean), and so on the face of it the frequent connections potentially allow tracking of handset location in quite a fine-grained way. Is it written down somewhere I can cite (other than this email) that log messages are treated differently from others, and also details as to which messages have scrubbed and which do not You know, its starting to seem to me that the lack of public documentation, or at least 36 easily discoverable documentation, might be a big part of the problem here. Telemetry for EN can also be disabled entirely via the Usage and Diagnostics Checkbox. Yes, I discovered that option just a few days back - not exactly hidden, but certainly not prominently displayed Regards, Doug 37 23} 20?? July Google HSE From: Dave Burke? Sent: 20 July 2020 16:45 To: Fran Thompson Cc: Gar T. MacCriosta; Ben Cloney; Julia Gonzales-Manton Subject: Re: FW: Another report on covid tracing apps CAUTION: email onglnatad from outsrde of the organisation Do not click links or open attachments unless you recognise the sender and know the content I8 safe. Hi Fran, Nice to meet (virtually). I would welcome a discussion. Our leave times aren't optimised as l'm out the week you get but let's get something on schedule for 2 weeks from now. Copying Julia from my side. Than ks, Dave 38 24) 3h Aug Google 9 Follow ups From: Dave Burke Sent: 05 August 2020 05:44 To: Fran Thompson; Gar T. MacCriosta Cc: Yul Kwon Subject: Follow ups CAUHON: This email originated from outside of the organisation. Do not click links or open attachments unless you recognise the sender and know the content l8 safe. Hi Fran, and Gar. Nice talking with you today. Two follow ups below. Trinity report transparency . Recent publications from us around transparency: 0 Open sourced EN implementation code 0 Documented the (narrow) EN telemetry design 0 Added note in EN documentation on general Android platform telemetry 0 Published release notes for each EN version Risks and mitigations for the EN protocol. . Existing documentation on general Google Android telemetry (published years ago): 0 Device configuration service 0 Google has a Takeout tool where you can download this data for your device 0 Data logging can be reduced with the Usage and Diagnostics checkbox 0 Our perspective in brief: 0 We welcome observations from researchers that help us focus on further opportunities in the Android operating system in general. 0 However, we are very concerned about the paper?s implications that ENS is creating an issue with data collection on Android, when in fact it is not. I By design, the Exposure Noti?cations System does not receive information about the end-user. . Google does not log user-identifiable information. - As an extra layer of protection, Google uses a deidentified logger for Exposure Noti?cations traf?c. - As a result, installing an EN app does not change the privacy pro?le for the user. In fact EN apps are amongst the most privacy?scrutinized apps there are. 0 The metrics and telemetry this report describes are an industry practice. This helps ensure that devices remain up-to-date and keep people and systems safe from 39 attacks. This information is publicly available on Google help pages for years (also, these critiques of telemetry apply equally to other OSes/devices): 0 We consider Google Play Services a critical part of a GMS phone. It?s a big part of the "Google" in "Google Android" and crucial to ensure a properly functioning phone. For example it includes functionality for: System/security updates to keep the phone updated with the latest system security patches to protect the user. Google account security System health battery and crashes). Backup and restore Parental controls Android Emergency Location Service Push noti?cations for apps 0 The reason the ENS module ships in Google Play services is because it?s an updatable layer on Google Android devices, thereby enabling EN to be available on all devices quickly, updating of the EN module based on the rapidly changing understanding of epidemiology and feedback from health authorities, can run persistently in a battery efficient way. EN settings audit log bug We believe this was a known issue during pre-release testing that we pushed to alpha channel partners but did not go public. If you happen to have a bugreport from the device when it happened we can con?rm for sure. Thanks, Dave