dave burke

First US apps based on Google and Apple Exposure Notification System expected in ‘coming weeks’

Posted by | Android, Android Nougat, api, Apple, Apps, Bluetooth, Canada, computing, coronavirus, COVID-19, dave burke, exposure notification, Google, Health, location services, mass surveillance, mobile applications, mobile software, operating systems, privacy, smartphones, TC, United States | No Comments

Google Vice President of Engineering Dave Burke provided an update about the Exposure Notifications System (ENS) that Google developed in partnership with Apple as a way to help public health authorities supplement contact-tracing efforts with a connected solution that preserves privacy while alerting people of potential exposure to confirmed cases of COVID-19. In the update, Burke notes that the company expects “to see the first set of these apps roll out in the coming weeks” in the U.S., which may be a tacit response to some critics who have pointed out that we haven’t seen much in the way of actual products being built on the technology that was launched in May.

Burke writes that 20 states and territories across the U.S. are currently “exploring” apps that make use of the ENS system, and that together those represent nearly half (45%) of the overall American populace. He also shared recent updates and improvements made to both the Exposure Notification API as well as to its surrounding documentation and information that the companies have shared in order to answer questions from state health agencies, and hopefully make its use and privacy implications more transparent.

The ENS API now supports exposure notifications between countries, which Burke says is a feature added based on nations that have already launched apps based on the tech (that includes Canada, as of today, as well as some European nations). It’s also now better at using Bluetooth values specific to a wider range of devices to improve nearby device detection accuracy. He also says they’ve improved the reliability for both apps and debugging tools for those working on development, which should help public health authorities and their developer partners more easily build apps that actually use ENS.

Burke continues that there’s been feedback from developers that they’d like more detail about how ENS works under the covers, and so they’ve published public-facing guides that direct health authorities about test verification server creation, code revealing its underlying workings and information about what data is actually collected (in a de-identified manner) to allow for much more transparent debugging and verification of proper app functioning.

Google also explains why it requires that an Android device’s location setting be turned on to use Exposure Notifications — even though apps built using the API are explicitly forbidden from also collecting location data. Basically, it’s a legacy requirement that Google is removing in Android 11, which is set to be released soon. In the meantime, however, Burke says that even with location services turned off, no app that uses the ENS will actually be able to see or receive any location data.

Powered by WPeMatico

Apple and Google update joint coronavirus tracing tech to improve user privacy and developer flexibility

Posted by | Android, Apple, Apps, Bluetooth, Cédric O, contacts tracing, coronavirus, COVID-19, cryptography, dave burke, Europe, european union, France, Germany, Google, Health, privacy, TC | No Comments

Apple and Google have provided a number of updates about the technical details of their joint contact tracing system, which they’re now exclusively referring to as an “exposure notification” technology, since the companies say this is a better way to describe what they’re offering. The system is just one part of a contact tracing system, they note, not the entire thing. Changes include modifications made to the API that the companies say provide stronger privacy protections for individual users, and changes to how the API works that they claim will enable health authorities building apps that make use of it to develop more effective software.

The additional measures being implemented to protect privacy include changing the cryptography mechanism for generating the keys used to trace potential contacts. They’re no longer specifically bound to a 24-hour period, and they’re now randomly generated instead of derived from a so-called “tracing key” that was permanently attached to a device. In theory, with the old system, an advanced enough attack with direct access to the device could potentially be used to figure out how individual rotating keys were generated from the tracing key, though that would be very, very difficult. Apple and Google clarified that it was included for the sake of efficiency originally, but they later realized they didn’t actually need this to ensure the system worked as intended, so they eliminated it altogether.

The new method makes it even more difficult for a would-be bad actor to determine how the keys are derived, and then attempt to use that information to use them to track specific individuals. Apple and Google’s goal is to ensure this system does not link contact tracing information to any individual’s identity (except for the individual’s own use) and this should help further ensure that’s the case.

The companies will now also be encrypting any metadata associated with specific Bluetooth signals, including the strength of signal and other info. This metadata can theoretically be used in sophisticated reverse identification attempts, by comparing the metadata associated with a specific Bluetooth signal with known profiles of Bluetooth radio signal types as broken down by device and device generation. Taken alone, it’s not much of a risk in terms of exposure, but this additional step means it’s even harder to use that as one of a number of vectors for potential identification for malicious use.

It’s worth noting that Google and Apple say this is intended as a fixed length service, and so it has a built-in way to disable the feature at a time to be determined by regional authorities, on a case-by-case basis.

Finally on the privacy front, any apps built using the API will now be provided exposure time in five-minute intervals, with a maximum total exposure time reported of 30 minutes. Rounding these to specific five-minute duration blocks and capping the overall limit across the board helps ensure this info, too, is harder to link to any specific individual when paired with other metadata.

On the developer and health authority side, Apple and Google will now be providing signal strength information in the form of Bluetooth radio power output data, which will provide a more accurate measure of distance between two devices in the case of contact, particularly when used with existing received signal strength info from the corresponding device that the API already provides access to.

Individual developers can also set their own parameters in terms of how strong a signal is and what duration will trigger an exposure event. This is better for public health authorities because it allows them to be specific about what level of contact actually defines a potential contact, as it varies depending on geography in terms of the official guidance from health agencies. Similarly, developers can now determine how many days have passed since an individual contact event, which might alter their guidance to a user (i.e. if it’s already been 14 days, measures would be very different from if it’s been two).

Apple and Google are also changing the encryption algorithm used to AES, from the HMAC system they were previously using. The reason for this switch is that the companies have found that by using AES encryption, which can be accelerated locally using on-board hardware in many mobile devices, the API will be more energy efficiency and have less of a performance impact on smartphones.

As we reported Thursday, Apple and Google also confirmed that they’re aiming to distribute next week the beta seed version of the OS update that will support these devices. On Apple’s side, the update will support any iOS hardware released over the course of the past four years running iOS 13. On the Android side, it would cover around 2 billion devices globally, Android said.

Coronavirus tracing: Platforms versus governments

One key outstanding question is what will happen in the case of governments that choose to use centralized protocols for COVID-19 contact tracing apps, with proximity data uploaded to a central server — rather than opting for a decentralized approach, which Apple and Google are supporting with an API.

In Europe, the two major EU economies, France and Germany, are both developing contact tracing apps based on centralized protocols — the latter planning deep links to labs to support digital notification of COVID-19 test results. The U.K. is also building a tracing app that will reportedly centralize data with the local health authority.

This week Bloomberg reported that the French government is pressuring Apple to remove technical restrictions on Bluetooth access in iOS, with the digital minister, Cedric O, saying in an interview Monday: “We’re asking Apple to lift the technical hurdle to allow us to develop a sovereign European health solution that will be tied our health system.”

While a German-led standardization push around COVID-19 contact tracing apps, called PEPP-PT — that’s so far only given public backing to a centralized protocol, despite claiming it will support both approaches — said last week that it wants to see changes to be made to the Google-Apple API to accommodate centralized protocols.

Asked about this issue an Apple spokesman told us it’s not commenting on the apps/plans of specific countries. But the spokesman pointed back to a position on Bluetooth it set out in an earlier statement with Google — in which the companies write that user privacy and security are “central” to their design.

Judging by the updates to Apple and Google’s technical specifications and API framework, as detailed above, the answer to whether the tech giants will bow to government pressure to support state centralization of proximity social graph data looks to be a strong “no.”

The latest tweaks look intended to reinforce individual privacy and further shrink the ability of outside entities to repurpose the system to track people and/or harvest a map of all their contacts.

The sharpening of the Apple and Google’s nomenclature is also interesting in this regard — with the pair now talking about “exposure notification” rather than “contact tracing” as preferred terminology for the digital intervention. This shift of emphasis suggests they’re keen to avoid any risk of their role being (mis)interpreted as supporting broader state surveillance of citizens’ social graphs, under the guise of a coronavirus response.

Backers of decentralized protocols for COVID-19 contact tracing — such as DP-3T, a key influence for the Apple-Google joint effort that’s being developed by a coalition of European academics — have warned consistently of the risk of surveillance creep if proximity data is pooled on a central server.

Apple and Google’s change of terminology doesn’t bode well for governments with ambitions to build what they’re counter-branding as “sovereign” fixes — aka data grabs that do involve centralizing exposure data. Although whether this means we’re headed for a big standoff between certain governments and Apple over iOS security restrictions — à la Apple vs the FBI — remains to be seen.

Earlier today, Apple and Google’s EU privacy chiefs also took part in a panel discussion organized by a group of European parliamentarians, which specifically considered the question of centralized versus decentralized models for contact tracing.

Asked about supporting centralized models for contact tracing, the tech giants offered a dodge, rather than a clear “no.”

“Our goal is to really provide an API to accelerate applications. We’re not obliging anyone to use it as a solution. It’s a component to help make it easier to build applications,” said Google’s Dave Burke, VP of Android engineering.

“When we build something we have to pick an architecture that works,” he went on. “And it has to work globally, for all countries around the world. And when we did the analysis and looked at different approaches we were very heavily inspired by the DP-3T group and their approach — and that’s what we have adopted as a solution. We think that gives the best privacy preserving aspects of the contacts tracing service. We think it’s also quite rich in epidemiological data that we think can be derived from it. And we also think it’s very flexible in what it could do. [The choice of approach is] really up to every member state — that’s not the part that we’re doing. We’re just operating system providers and we’re trying to provide a thin layer of an API that we think can help accelerate these apps but keep the phone in a secure, private mode of operation.”

“That’s really important for the expectations of users,” Burke added. “They expect the devices to keep their data private and safe. And then they expect their devices to also work well.”

DP-3T’s Michael Veale was also on the panel — busting what he described as some of the “myths” about decentralized contacts tracing versus centralized approaches.

“The [decentralized] system is designed to provide data to epidemiologists to help them refine and improve the risk score — even daily,” he said. “This is totally possible. We can do this using advanced methods. People can even choose to provide additional data if they want to epidemiologists — which is not really required for improving the risk score but might help.”

“Some people think a decentralized model means you can’t have a health authority do that first call [to a person exposed to a risk of infection]. That’s not true. What we don’t do is we don’t tag phone numbers and identities like a centralized model can to the social network. Because that allows misuse,” he added. “All we allow is that at the end of the day the health authority receives a list separate from the network of whose phone number they can call.”

MEP Sophie in ‘t Veld, who organzied the online event, noted at the top of the discussion they had also invited PEPP-PT to join the call but said no one from the coalition had been able to attend the video conference.

Powered by WPeMatico

Google launches the first developer preview of Android 11

Posted by | Android, api, Apps, BlackBerry Priv, computing, dave burke, Google, Google Play, machine learning, Mobile, mobile operating system, operating system, operating systems, PIXEL, smartphones, Software, TC | No Comments

With the days of desert-themed releases officially behind it, Google today announced the first developer preview of Android 11, which is now available as system images for Google’s own Pixel devices, starting with the Pixel 2.

As of now, there is no way to install the updates over the air. That’s usually something the company makes available at a later stage. These first releases aren’t meant for regular users anyway. Instead, they are a way for developers to test their applications and get a head start on making use of the latest features in the operating system.

With Android 11 we’re keeping our focus on helping users take advantage of the latest innovations, while continuing to keep privacy and security a top priority,” writes Google VP of Engineering Dave Burke. “We’ve added multiple new features to help users manage access to sensitive data and files, and we’ve hardened critical areas of the platform to keep the OS resilient and secure. For developers, Android 11 has a ton of new capabilities for your apps, like enhancements for foldables and 5G, call-screening APIs, new media and camera capabilities, machine learning, and more.”

Unlike some of Google’s previous early previews, this first version of Android 11 does actually bring quite a few new features to the table. As Burke noted, there are some obligatory 5G features like a new bandwidth estimate API, for example, as well as a new API that checks whether a connection is unmetered so apps can play higher-resolution video, for example.

With Android 11, Google is also expanding its Project Mainline lineup of updatable modules from 10 to 22. With this, Google is able to update critical parts of the operating system without having to rely on the device manufacturers to release a full OS update. Users simply install these updates through the Google Play infrastructure.

Users will be happy to see that Android 11 will feature native support for waterfall screens that cover a device’s edges, using a new API that helps developers manage interactions near those edges.

Also new are some features that developers can use to handle conversational experiences, including a dedicated conversation section in the notification shade, as well as a new chat bubbles API and the ability to insert images into replies you want to send from the notifications pane.

Unsurprisingly, Google is adding a number of new privacy and security features to Android 11, too. These include one-time permissions for sensitive types of data, as well as updates to how the OS handles data on external storage, which it first previewed last year.

As for security, Google is expanding its support for biometrics and adding different levels of granularity (strong, weak and device credential), in addition to the usual hardening of the platform you would expect from a new release.

There are plenty of other smaller updates as well, including some that are specifically meant to make running machine learning applications easier, but Google specifically highlights the fact that Android 11 will also bring a couple of new features to the OS that will help IT manage corporate devices with enhanced work profiles.

This first developer preview of Android 11 is launching about a month earlier than previous releases, so Google is giving itself a bit more time to get the OS ready for a wider launch. Currently, the release schedule calls for monthly developer preview releases until April, followed by three betas and a final release in Q3 2020.

Powered by WPeMatico