Industry committee  In the case of the API, you are getting consent because you have to download an app from the public health authority in order to enable that functionality.

Industry committee  In the case of Android, what you can see when you're downloading an app is there are very granular specifications of what data they're looking for. You can click on each type of data to see an explanation of why they are looking for it. Furthermore, you can deny the app access to

Industry committee  I mean, we're speaking about a hypothetical. The data that we're talking—

Industry committee  Yes, but the data that is on an Android or iOS device is simply a list of exposures that you've had to other nearby devices over a defined period of time. If someone was going to spoof your test results or was going to try to trigger—

Industry committee  I'm just processing this.... In the context of the data that's available on the phones, that would be extraordinarily difficult, because the Bluetooth records themselves are randomized and anonymized.

Industry committee  I think you're talking about general public health protections and border restrictions. From the point of view of the exposure notification API, you've noted an important element of how contact tracing must roll out and must be negotiated between public health authorities in dif

Industry committee  In the context of the exposure notification API, we've explicitly engineered it so that there is only the exchange of information about Bluetooth localization, and it isn't identifiable information for the public health authority. We would be communicating information about mobil

Industry committee  It sounds like you're describing two separate things. In terms of Bluetooth security, I can certainly follow up with what we've been doing to create a secure environment on Android phones. In the other context, particularly the one you have identified around false positives, th

Industry committee  Well, that verification would be up to the public health authority who's using that information to then request proximity data from the API in order to notify people that they've been close by. The next step from that is then to move to testing. The way the API would work is that

Industry committee  Once we roll out the API, there's a process engagement between Google and the government and the public health authority for the implementation. We need to make sure that they respect our terms and conditions and the terms of service around the API use before it's actually rolled

Industry committee  The way we've structured the app is that it's on device storage, and then it's uploading to public health authorities. It's meant to be binary that way, and any information sharing would be between the health authorities separate from our API or our OS movements.

Industry committee  In response to your first question, I think we're at only the initial stages of the rollout of either the API or the apps. To the second part of your question, I think it's up to the public health authorities and the governments to make the case to their citizens that there's a

Industry committee  I can speak only to the Android platform, on which you receive notifications when there are updates to either an app or the operating system itself, which give you a description of what is happening and why it's taking place. Then once again, even after the implementation of the

Industry committee  I'd say that we provide this technology to public health authorities in the pursuit of public health. I can't speak to what countries those might be and what conditions there may be. We're still in the early days and we're still in the process of actually rolling out the API.

Industry committee  I think we're still in the hypothetical when we're talking about the particular Apple-Google project.