Use of Firebase Remote Configuration and Google SafetyNet #215
Comments
|
This app is not worth any further cash investment... |
|
Yes. I think those are super-valid concerns. Seems that all the "big words" were said about privacy and how the government will better take care of the health data and even in this app they are not able to publish security and privacy audits (even if they promised that long time ago) and independent security auditors find out that they voluntarily send data to Google. I'd say this is yet another time where - even if we try to put confidence in those people who create the app and those who supervise it, they do everything possible to loose the small remnants of it. @MateuszRomanow -> yet again, you failed any confidence that anyone could have. It's a sad story, but no wonder only 0.7% of people decided to install the app. |
|
@doug-leith |
Like every other app it needs time to adopt. @potiuk if you though that it will be installed but everybody or at least by half of the population, it means that you have literally no experience with mobile app release. |
|
@potiuk |
It is very strange, the coronavirus is not well understood, but everyone knows there will be a second wave during autumn. NWO and EVENT 201 confirmed? |
|
We appreciate and are well aware of Dr. Leith's and Dr. Keller's work in the area of contact tracing apps, and are looking forward to elaborate on the subject. Is there a possibility we could meet for some more insights on Your security perspective? It would be greatly appreciated.
Dr Farrell, not Keller. Of course, happy to have a chat by zoom or whatever suits.
Our whole solution is based on Google reference architecture and hosted on GCP. CDN address that you mentioned is also powered by Google's object store. There is not much of a difference to be made here in terms of who keeps the data online.
We haven’t looked at your backend setup, only the data sent by the app itself, so I can’t comment on your backend storage arrangements. But I would suggest that for lots of reasons Google holding user data is not the same as a public health authority holding that data - one is that the oversight/governance frameworks for these are usually v different, another is the obvious potential conflict of interest with Google’s commercial interests.
But we understand the concerns and in most cases we remove client's IP before it reaches Google's edge.
The data that we observe is sent to Google is via Firebase requests made directly by the app, you’re therefore not in a position to remove the handset IP address before it reaches Google.
We do not enforce SafetyNet because early adopters in our country turned out to be running a lot of rooted devices. Our security auditors recommended that we show to the users that their device is rooted but do not deny. We are not happy about that. For now we chose to focus on the diagnosis verification with the help of our local health authority and skip the device validation. The idea to delay the check until the upload phase is very interesting.
Thanks for clarifying.
Could you elaborate why do you find Firebase that much of a threat compared to any other product or part of Google infrastructure involved?
Our comments relate to the network connections made by the app direct to Google Firebase. These create privacy concerns since they expose the device IP address (and so rough location) to Google. The identifiers embedded within these requests allow requests from the same handset to be linked together by Google, and so handset location over time tracked.
|
I strongly advise you to read a bit of historical entries here to get the context. I actually have more than 10 years of experience of developing mobile apps (including some that achieved tens of millions of installs) and this is precisely what I expected. That the adoption will be very small. Others (including government officially) believed otherwise. They thought that government promotion, marketing and finally even "incentivizing people" (the supermarket case) will change it. From the very beginning when G+A announced it, I keep on holding the position (and see it as the only chance for digital contact tracing) that people should not need to install the app at all. They should just enable it in the OS level. This is IMHO (and I think and write about it for a very long time) the only possible (and even that unsure) way to get widespread adoption. Google and Apple planned (and they still will IMHO) to enable Exposure Notification to make it work on the OS level. And I am sure it will come back. |
At Trinity College Dublin, Ireland we've been carrying out a security/privacy analysis of contact tracing apps in Europe. Based on our measurements it seems that the version of Protego Safe on Google Play uses Firebase Remote Configuration to periodically download settings. This seems inadvisable from a privacy perspective since it immediately results in sharing data with Google. This includes the IP address of the handset making the connection (which is a proxy for location), and since each request includes a firebase identifier requests from the same handset can be linked together over time. Since you already use the exp.staysafe.app server to deliver TEKs, we suggest that you also use that to deliver configuration settings and stop using Firebase. This would also help bring the app into line with other apps in Europe.
We also note that you use Google's SafetyNet service. That also involves sharing data with Google, including the device hardware serial number, a long lived handset identifier, which is undesirable from a privacy perspective. We also note that the current app code (i) does not properly enforce SafetyNet results (failing the check is ignored by the app) and (ii) checks are carried out within the app itself, which is contrary to Google guidelines as to best practice (it makes it easy to bypass checks on rooted phones). We therefore suggest that you stop using SafetyNet, except perhaps when uploading TEKs, which again would be in line with the approach adopted by other European apps.
The text was updated successfully, but these errors were encountered: