api

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

You can now install the first beta of Android 11

Posted by | Android, Android Nougat, api, computing, Gadgets, Google, Mobile, mobile app, operating systems, password manager, smart home devices, smartphones | No Comments

After a series of developer previews, Google today released the first beta of Android 11, and with that, it is also making these pre-release versions available for over-the-air updates. This time around, the list of supported devices only includes the Pixel 2, 3, 3a and 4.

If you’re brave enough to try this early version (and I wouldn’t do so on your daily driver until a few more people have tested it), you can now enroll here. Like always, Google is also making OS images available for download and an updated emulator is available, too.

Google says the beta focuses on three key themes: people, controls and privacy.

Like in previous updates, Google once again worked on improving notifications — in this case, conversation notifications, which now appear in a dedicated section at the top of the pull-down shade. From there, you will be able to take actions right from inside the notification or ask the OS to remind you of this conversation at a later time. Also new is built-in support in the notification system for what are essentially chat bubbles, which messaging apps can now use to notify you even as you are working (or playing) in another app.

Another new feature is consolidated keyboard suggestions. With these, Autofill apps and Input Method Editors (think password managers and third-party keyboards), can now securely offer context-specific entries in the suggestion strip. Until now, enabling autofill for a password manager, for example, often involved delving into multiple settings and the whole experience often felt like a bit of a hack.

For those users who rely on voice to control their phones, Android now uses a new on-device system that aims to understand what is on the screen and then automatically generates labels and access points for voice commands.

As for controls, Google is now letting you long-press the power button to bring up controls for your smart home devices (though companies that want to appear in this new menu need to make use of Google’s new API for this). In one of the next beta releases, Google will also enable media controls that will make it easier to switch the output device for their audio and video content.

In terms of privacy, Google is adding one-time permissions so that an app only gets access to your microphone, camera or location once, as well as auto-resets for permissions when you haven’t used an app for a while.

A few months ago, Google said that developers would need to get a user’s approval to access background location. That caused a bit of a stir among developers and now Google will keep its current policies in place until 2021 to give developers more time to update their apps.

In addition to these user-facing features, Google is also launching a series of updates aimed at Android developers. You can read more about them here.

Powered by WPeMatico

Apple and Google launch exposure notification API, enabling public health authorities to release apps

Posted by | Android, api, Apple, Apps, Bluetooth, computing, contact tracing, coronavirus, COVID-19, Google, Health, iOS, mobile app, operating systems, smartphones, Software, TC, United States | No Comments

Apple and Google today made available the first public version of their exposure notification API, which was originally debuted as a joint contact-tracing software tool. The partners later renamed it the Exposure Notification system to more accurately reflect its functionality, which is designed to notify individuals of potential exposure to others who have confirmed cases of COVID-19, while preserving privacy around identifying info and location data.

The launch today means that public health agencies can now use the API in apps released to the general public. To date, Apple and Google have only released beta versions of the API to help with the development process.

To be clear, this launch means that developers working on behalf of public health agencies can now issue apps that make use of it — Apple and Google themselves are not creating an exposure-notification or contact-tracing app. The companies say that many U.S. states and 22 countries across five continents have already asked for, and been provided access to, the API to support their development efforts, and they anticipate more being added going forward. So far, Apple and Google say they have conducted more than 24 briefings and tech talks for public health officials, epidemiologists and app developers working on their behalf.

The exposure notification API works using a decentralized identifier system that uses randomly generated temporary keys created on a user’s device (but not tied to their specific identify or info). Apple and Google’s API allows public health agencies to define what constitutes potential exposure in terms of exposed time and distance, and they can tweak transmission risk and other factors according to their own standards.

Further, Apple and Google will allow apps to make use of a combination of the API and voluntarily submitted user data that they provide through individual apps to enable public health authorities to contact exposed users directly to make them aware of what steps they should take.

During the course of the API’s development, Apple and Google have made various improvements to ensure that privacy is an utmost consideration, including encrypting all Bluetooth metadata (like signal strength and specific transmitting power), as that could potentially be used to determine what type of device was used, which offers a slim possibility of associating an individual with a specific device and using that as one vector for identification.

The companies have also explicitly barred use of the API in any apps that also seek geolocation information permission from users — which means some apps being developed by public health authorities for contact tracing that use geolocation data won’t be able to access the exposure notification API. That has prompted some to reconsider their existing approach.

Apple and Google provided the following joint statement about the API and how it will support contact-tracing efforts undertaken by public health officials and agencies:

One of the most effective techniques that public health officials have used during outbreaks is called contact tracing. Through this approach, public health officials contact, test, treat and advise people who may have been exposed to an affected person. One new element of contact tracing is Exposure Notifications: using privacy-preserving digital technology to tell someone they may have been exposed to the virus. Exposure Notification has the specific goal of rapid notification, which is especially important to slowing the spread of the disease with a virus that can be spread asymptomatically.

To help, Apple and Google cooperated to build Exposure Notifications technology that will enable apps created by public health agencies to work more accurately, reliably and effectively across both Android phones and iPhones. Over the last several weeks, our two companies have worked together, reaching out to public health officials scientists, privacy groups and government leaders all over the world to get their input and guidance.

Starting today, our Exposure Notifications technology is available to public health agencies on both iOS and Android. What we’ve built is not an app — rather public health agencies will incorporate the API into their own apps that people install. Our technology is designed to make these apps work better. Each user gets to decide whether or not to opt-in to Exposure Notifications; the system does not collect or use location from the device; and if a person is diagnosed with COVID-19, it is up to them whether or not to report that in the public health app. User adoption is key to success and we believe that these strong privacy protections are also the best way to encourage use of these apps.

Today, this technology is in the hands of public health agencies across the world who will take the lead and we will continue to support their efforts.

The companies previously announced plans to make Exposure Notification a system-level feature in a later update to both their respective mobile operating systems, to be released sometime later this year. That “Phase two” portion of the strategy might be under revision, however, as Google and Apple said they continue to be in conversation with public health authorities about what system-level features will be useful to them in development of their COVID-19 mitigation strategies.

Powered by WPeMatico

UK eyeing switch to Apple-Google API for coronavirus contacts tracing — report

Posted by | alpha, Android, api, Apple, apple inc, Apps, Australia, BBC, Bluetooth, ceo, Colombia, computing, estonia, Europe, Google, Health, instagram, ios 11, iPhone, ireland, Mobile, mobile app, National Health Service, NHS, NHSX, operating systems, privacy, Singapore, smartphone, smartphones, spokesperson, switzerland, The Financial Times, United Kingdom, wi-fi | No Comments

The UK may be rethinking its decision to shun Apple and Google’s API for its national coronavirus contacts tracing app, according to the Financial Times, which reported yesterday that the government is paying an IT supplier to investigate whether it can integrate the tech giants’ approach after all.

As we’ve reported before coronavirus contacts tracing apps are a new technology which aims to repurpose smartphones’ Bluetooth signals and device proximity to try to estimate individuals’ infection risk.

The UK’s forthcoming app, called NHS COVID-19, has faced controversy because it’s being designed to use a centralized app architecture. This means developers are having to come up with workarounds for platform limitations on background access to Bluetooth as the Apple-Google cross-platform API only works with decentralized systems.

The choice of a centralized app architecture has also raised concerns about the impact of such an unprecedented state data grab on citizens’ privacy and human rights, and the risk of state ‘mission creep‘.

The UK also looks increasingly isolated in its choice in Europe after the German government opted to switch to a decentralized model, joining several other European countries that have said they will opt for a p2p approach, including Estonia, Ireland and Switzerland.

In the region, France remains the other major backer of a centralized system for its forthcoming coronavirus contacts tracing app, StopCovid.

Apple and Google, meanwhile, are collaborating on a so-called “exposure notification” API for national coronavirus contacts tracing apps. The API is slated to launch this month and is designed to remove restrictions that could interfere with how contact events are logged. However it’s only available for apps that don’t hold users’ personal data on central servers and prohibits location tracking, with the pair emphasizing that their system is designed to put privacy at the core.

Yesterday the FT reported that NHSX, the digital transformation branch of UK’s National Health Service, has awarded a £3.8M contract to the London office of Zuhlke Engineering, a Switzerland-based IT development firm which was involved in developing the initial version of the NHS COVID-19 app.

The contract includes a requirement to “investigate the complexity, performance and feasibility of implementing native Apple and Google contact tracing APIs within the existing proximity mobile application and platform”, per the newspaper’s report.

The work is also described as a “two week timeboxed technical spike”, which the FT suggests means it’s still at a preliminary phase — thought it also notes the contract includes a deadline of mid-May.

The contracted work was due to begin yesterday, per the report.

We’ve reached out to Zuhlke for comment. Its website describes the company as “a strong solutions partner” that’s focused on projects related to digital product delivery; cloud migration; scaling digital platforms; and the Internet of Things.

We also put questions arising from the FT report to NHSX.

At the time of writing the unit had not responded but yesterday a spokesperson told the newspaper: “We’ve been working with Apple and Google throughout the app’s development and it’s quite right and normal to continue to refine the app.”

The specific technical issue that appears to be causing concern relates to a workaround the developers have devised to try to circumvent platform limitations on Bluetooth that’s intended to wake up phones when the app itself is not being actively used in order that the proximity handshakes can still be carried out (and contacts events properly logged).

Thing is, if any of the devices fail to wake up and emit their identifiers so other nearby devices can log their presence there will be gaps in the data. Which, in plainer language, means the app might miss some close encounters between users — and therefore fail to notify some people of potential infection risk.

Recent reports have suggested the NHSX workaround has a particular problem with iPhones not being able to wake up other iPhones. And while Google’s Android OS is the more dominant platform in the UK (running on circa ~60% of smartphones, per Kantar) there will still be plenty of instances of two or more iPhone users passing near each other. So if their apps fail to wake up they won’t exchange data and those encounters won’t be logged.

On this, the FT quotes one person familiar with the NHS testing process who told it the app was able to work in the background in most cases, except when two iPhones were locked and left unused for around 30 minutes, and without any Android devices coming within 60m of the devices. The source also told it that bringing an Android device running the app close to the iPhone would “wake up” its Bluetooth connection.

Clearly, the government having to tell everyone in the UK to use an Android smartphone not an iPhone wouldn’t be a particularly palatable political message.

This is effectively a form of Android Herd Immunity: for the good of Britain, vaccinate your friends by giving them Androids!

— Michael Veale (@mikarv) May 5, 2020

One source with information about the NHSX testing process told us the unit has this week been asking IT suppliers for facilities or input on testing environments with “50-100 Bluetooth devices of mixed origin”, to help with challenges in testing the Bluetooth exchanges — which raises questions about how extensively this core functionality has been tested up to now. (Again, we’ve put questions to the NHSX about testing and will update this report with any response.)

Work on planning and developing the NHS COVID-19 app began March 7, according to evidence given to a UK parliamentary committee by the NHSX CEO’s, Matthew Gould, last month.

Gould has also previously suggested that the app could be “technically” ready to launch in as little as two or three weeks time from now. While a limited geographical trial of the app kicked off this week in the Isle of Wight. Prior to that, an alpha version of the app was tested at an RAF base involving staff carrying out simulations of people going shopping, per a BBC report last month.

Gould faced questions over the choice of centralized vs decentralized app architecture from the human rights committee earlier this week. He suggested then that the government is not “locked” to the choice — telling the committee: “We are constantly reassessing which approach is the right one — and if it becomes clear that the balance of advantage lies in a different approach then we will take that different approach. We’re not irredeemably wedded to one approach; if we need to shift then we will… It’s a very pragmatic decision about what approach is likely to get the results that we need to get.”

However it’s unclear how quickly such a major change to app architecture could be implemented, given centralized vs decentralized systems work in very different ways.

Additionally, such a big shift — more than two months into the NHSX’s project — seems, at such a late stage, as if it would be more closely characterized as a rebuild, rather than a little finessing (as suggested by the NHSX spokesperson’s remark to the FT vis-a-vis ‘refining’ the app).

In related news today, Reuters reports that Colombia has pulled its own coronavirus contacts tracing app after experiencing glitches and inaccuracies. The app had used alternative technology to power contacts logging via Bluetooth and wi-fi. A government official told the news agency it aims to rebuild the system and may now use the Apple-Google API.

Australia has also reported Bluetooth related problems with its national coronavirus app. And has also been reported to be moving towards adopting the Apple-Google API.

While, Singapore, the first country to launch a Bluetooth app for coronavirus contacts tracing, was also the first to run into technical hitches related to platform limits on background access — likely contributing to low download rates for the app (reportedly below 20%).

Powered by WPeMatico

NHS COVID-19: The UK’s coronavirus contacts-tracing app explained

Posted by | Android, api, app-store, Apple, Apps, Australia, Bluetooth, contacts tracing apps, coronavirus, COVID-19, data protection law, estonia, Europe, european union, Germany, Google, Health, iOS, iPhone, ireland, mobile app, National Health Service, NHS COVID-19, northern ireland, operating systems, privacy, Security, Singapore, smartphone, smartphones, switzerland, TC, United Kingdom | No Comments

The UK has this week started testing a coronavirus contacts-tracing app which NHSX, a digital arm of the country’s National Health Service, has been planning and developing since early March. The test is taking place in the Isle of Wight, a 380km2 island off the south coast of England, with a population of around 140,000.

The NHS COVID-19 app uses Bluetooth Low Energy handshakes to register proximity events (aka ‘contacts’) between smartphone users, with factors such as the duration of the ‘contact event’ and the distance between the devices feeding an NHS clinical algorithm that’s being designed to estimate infection risk and trigger notifications if a user subsequently experiences COVID-19 symptoms.

The government is promoting the app as an essential component of its response to fighting the coronavirus — the health minister’s new mantra being: ‘Protect the NHS, stay home, download the app’ — and the NHSX has said it expects the app to be “technically” ready to deploy two to three weeks after this week’s trial.

However there are major questions over how effective the tool will prove to be, especially given the government’s decision to ‘go it alone’ on the design of its digital contacts-tracing system — which raises some specific technical challenges linked to how modern smartphone platforms operate, as well as around international interoperability with other national apps targeting the same purpose.

In addition, the UK app allows users to self report symptoms of COVID-19 — which could lead to many false alerts being generated. That in turn might trigger notification fatigue and/or encourage users to ignore alerts if the ratio of false alarms exceeds genuine alerts.

Keep calm and download the app?

How users will generally respond to this technology is a major unknown. Yet mainstream adoption will be needed to maximize utility; not just one-time downloads. Dealing with the coronavirus will be a marathon not a sprint — which means sustaining usage will be vital to the app functioning as intended. And that will require users to trust that the app is both useful for the claimed public health purpose, by being effective at shrinking infection risk, and also that using it will not create any kind of disadvantages for them personally or for their friends and family.

The NHSX has said it will publish the code for the app, the DPIA (data protection impact assessment) and the privacy and security models — all of which sounds great, though we’re still waiting to see those key details. Publishing all that before the app launches would clearly be a boon to user trust.

A separate consideration is whether there should be a dedicated legislation wrapper put around the app to ensure clear and firm legal bounds on its use (and to prevent abuse and data misuse).

As it stands the NHS COVID-19 app is being accelerated towards release without this — relying on existing legislative frameworks (with some potential conflicts); and with no specific oversight body to handle any complaints. That too could impact user trust.

The overarching idea behind digital contacts tracing is to leverage uptake of smartphone technology to automate some contacts tracing, with the advantage that such a tool might be able to register fleeting contacts, such as between strangers on the street or public transport, that may more difficult for manual contacts-tracing methods to identify. Though whether these sorts of fleeting contacts create a significant risk of infection with the SARS-CoV-2 virus has not yet been quantified.

All experts are crystal clear on one thing: Digital contacts tracing is only going to be — at very best — a supplement to manual contact tracing. People who do not own or carry smartphones or who do not or cannot use the app obviously won’t register in any captured data. Technical issues may also create barriers and data gaps. It’s certainly not a magic bullet — and may, in the end, turn out to be ill-suited for this use case (we’ve written a general primer on digital contacts tracing here).

One major component of the UK approach is that it’s opted to create a so-called ‘centralized’ system for coronavirus contacts tracing — which leads to a number of specific challenges.

While the NHS COVID-19 app stores contacts events on the user’s device initially, at the point when (or if) a user chooses to report themselves having coronavirus symptoms then all their contacts events data is uploaded to a central server. This means it’s not just a user’s own identifier but a list of any identifiers they have encountered over the past 28 days — so, essentially, a graph of their recent social interactions.

This data cannot be deleted after the fact, according to the NHSX, which has also said it may be used for “research” purposes related to public health — raising further questions around privacy and trust.

Questions around the legal bases for this centralized approach also remain to be answered in detail by the government. UK and EU data protection law emphasize data minimization as a key principle; and while there’s flexibility built into these frameworks for a public health emergency there is still a requirement on the government to detail and justify key data processing decisions.

The UK’s decision to centralize contacts data has another obvious and immediate consequence: It means the NHS COVID-19 app will not be able to plug into an API that’s being jointly developed by Apple and Google to provide technical support for Bluetooth-based national contacts-tracing apps — and due to be release this month.

The tech giants have elected to support decentralized app architectures for these apps — which, conversely, do not centralize social graph data. Instead, infection risk calculations are performed locally on the device.

By design, these approaches avoid providing a central authority with information on who infected whom.

In the decentralized scenario, an infected user consents to their ephemeral identifier being shared with other users so apps can do matching locally, on the end-user device — meaning exposure notifications are generated without a central authority needing to be in the loop. (It’s also worth noting there are ways for decentralized protocols to feed aggregated contact data back to a central authority for epidemiological research, though the design is intended to prevent users’ social graph being exposed. A system of ‘exposure notification’, as Apple and Google are now branding it, has no need for such data, is their key argument. The NHSX counters that by suggesting social graph data could provide useful epidemiological insights — such as around how the virus is being spread.)

At the point a user of the NHS COVID-19 app experiences symptoms or gets a formal coronavirus diagnosis — and chooses to inform the authorities — the app will upload their recent contacts to a central server where infection risk calculations are performed.

The system will then send exposure notifications to other devices — in instances where the software deems there may be at risk of infection. Users might, for example, be asked to self isolate to see if they develop symptoms after coming into contact with an infected person, or told to seek a test to determine if they have COVID-19 or not.

A key detail here is that users of the NHS COVID-19 app are assigned a fixed identifier — basically a large, random number — which the government calls an “installation ID”. It claims this identifier is ‘anonymous’. However this is where political spin in service of encouraging public uptake of the app is being allowed to obscure a very different legal reality: A fixed identifier linked to a device is in fact pseudonymous data, which remains personal data under UK and EU law. Because, while the user’s identity has been ‘obscured’, there’s still a clear risk of re-identification.

Truly ‘anonymous’ data is a very high bar to achieve when you’re dealing with large data-sets. In the NHS COVID-19 app case there’s no reason beyond spin for the government to claim the data is “anonymous”; given the system design involves a device-linked fixed identifier that’s uploaded to a central authority alongside at least some geographical data (a partial postcode: which the app also asks users to input — so “the NHS can plan your local NHS response”, per the official explainer).

The NHSX has also said future versions of the app may ask users to share even more personal data, including their location. (And location data-sets are notoriously difficult to defend against re-identification.)

Nonetheless the government has maintained that individual users of the app will not be identified. But under such a system architecture this assertion sums to ‘trust us with your data’; the technology itself has not been designed to remove the need for individual users to trust a central authority, as is the case with bona fide decentralized protocols.

This is why Apple and Google are opting to support the latter approach — it cuts the internationally thorny issue of ‘government trust’ out of their equation.

However it also means governments that do want to centralize data face a technical headache to get their apps to function smoothly on the only two smartphone platforms that matter.

Technical and geopolitical headaches

The specific technical issue here relates to how these mainstream platforms manage background access to Bluetooth.

Using Bluetooth as a proxy for measuring coronavirus infection risk is of course a very new and novel technology. Singapore was reported to be the first country to attempt this. Its TraceTogether app, which launched in March, reportedly gained only limited (<20%) uptake — with technical issues on iOS being at least partly blamed for the low uptake.

The problem that the TraceTogether app faced initially is the software needed to be actively running and the iPhone open (not locked) for the tracing function to work. That obviously interferes with the normal multitasking of the average iPhone user — discouraging usage of the app.

It’s worth emphasizing that the UK is doing things a bit differently vs Singapore, though, in that it’s using Bluetooth handshakes rather than a Bluetooth advertising channel to power the contacts logging.

The NHS COVID-19 app has been designed to listen passively for other Bluetooth devices and then wake up in order to perform the handshake. This is intended as a workaround for these platform limits on background Bluetooth access. However it is still a workaround — and there are ongoing questions over how robustly it will perform in practice. 

An analysis by The Register suggests the app will face a fresh set of issues in that iPhones specifically will fail to wake each other up to perform the handshakes — unless there’s also an Android device in the vicinity. If correct, it could result in big gaps in the tracing data (around 40% of UK smartphones run iOS vs 60% running Android).

Battery drain may also resurface as an issue with the UK system, though the NHSX has claimed its workaround solves this. (Though it’s not clear if they’ve tested what happens if an iPhone user switches on a battery saving mode which limits background app activity, for example.)

Other Bluetooth-based contract-tracing apps that have tried to workaround platforms limits have also faced issues with interference related to other Bluetooth devices — such as Australia’s recently launched app. So there are a number of potential issues that could trouble performance.

Being outside the Apple-Google API also certainly means the UK app is at the mercy of future platform updates which could derail the specific workaround. Best laid plans that don’t involve using an official interface as your plug are inevitably operating on shaky ground.

Finally, there’s a huge and complex issue that’s essentially being glossed over by government right now: Interoperability with other national apps.

How will the UK app work across borders? What happens when Brits start travelling again? With no obvious route for centralized vs decentralized systems to interface and play nice with each other there’s a major question mark over what happens when UK citizens want to travel to countries with decentralized systems (or indeed vice versa). Mandatory quarantines because the government picked a less interoperable app architecture? Let’s hope not.

Notably, the Republic of Ireland has opted for a decentralized approach for its national app, whereas Northern Ireland, which is part of the UK but shares a land border with the Republic, will — baring any NHSX flip — be saddled with a centralized and thus opposing choice. It’s the Brexit schism all over again in app form.

Earlier this week the NHSX was asked about this cross-border issue by a UK parliamentary committee — and admitted it creates a challenge “we’ll have to work through”, though it did not suggest how it proposes to do that.

And while that’s a very pressing backyard challenge, the same interoperability gremlins arise across the English Channel — where a number of European countries are opting for decentralized apps, including Estonia, Germany and Switzerland. While Apple and Google’s choice at the platform level means future US apps may also be encouraged down a decentralized route. (The two US tech giants are demonstrably flexing their market power to press on and influence governments’ app design choices internationally.)

So countries that fix on a ‘DIY’ approach for the digital component of their domestic pandemic response may find it leads to some unwelcome isolation for their citizens at the international level.

Powered by WPeMatico

Germany ditches centralized approach to app for COVID-19 contacts tracing

Posted by | Android, api, Apple, Apps, Bluetooth, contact tracing, coronavirus, COVID-19, decentralization, DP-3T, Europe, european commission, european union, France, Germany, Google, Health, iOS, mobile app, operating systems, p2p, PEPP-PT, privacy, smartphones, surveillance, United Kingdom | No Comments

Germany has U-turned on building a centralized COVID-19 contacts tracing app — and will instead adopt a decentralized architecture, Reuters reported Sunday, citing a joint statement by chancellery minister Helge Braun and health minister Jens Spahn.

In Europe in recent weeks, a battle has raged between different groups backing centralized vs decentralized infrastructure for apps being fast-tracked by governments which will use Bluetooth-based smartphone proximity as a proxy for infection risk — in the hopes of supporting the public health response to the coronavirus by automating some contacts tracing.

Centralized approaches that have been proposed in the region would see pseudonymized proximity data stored and processed on a server controlled by a national authority, such as a healthcare service. However concerns have been raised about allowing authorities to scoop up citizens’ social graph, with privacy experts warning of the risk of function creep and even state surveillance.

Decentralized contacts tracing infrastructure, by contrast, means ephemeral IDs are stored locally on device — and only uploaded with a user’s permission after a confirmed COVID-19 diagnosis. A relay server is used to broadcast infected IDs — enabling devices to locally compute if there’s a risk that requires notification. So social graph data is not centralized.

The change of tack by the German government marks a major blow to a homegrown standardization effort, called PEPP-PT, that had been aggressively backing centralization — while claiming to ‘preserve privacy’ on account of not tracking location data. It quickly scrambled to propose a centralized architecture for tracking coronavirus contacts, led by Germany’s Fraunhofer Institute, and claiming the German government as a major early backer, despite PEPP-PT later saying it would support decentralized protocols too.

As we reported earlier, the effort faced strident criticism from European privacy experts — including a group of academics developing a decentralized protocol called DP-3T — who argue p2p architecture is truly privacy preserving. Concerns were also raised about a lack of transparency around who is behind PEPP-PT and the protocols they claimed to support, with no code published for review.

The European Commission, meanwhile, has also recommended the use of decentralization technologies to help boost trust in such apps in order to encourage wider adoption.

EU parliamentarians have also warned regional governments against trying to centralize proximity data during the coronavirus crisis.

But it was Apple and Google jumping into the fray earlier this month by announcing joint support for decentralized contacts tracing that was the bigger blow — with no prospect of platform-level technical restrictions being lifted. iOS limits background access to Bluetooth for privacy and security reasons, so national apps that do not meet this decentralized standard won’t benefit from API support — and will likely be far less usable, draining battery and functioning only if actively running.

Nonetheless PEPP-PT told journalists just over a week ago that it was engaged in fruitful discussions with Apple and Google about making changes to their approach to accommodate centralized protocols.

Notably, the tech giants never confirmed that claim. They have only since doubled down on the principle of decentralization for the cross-platform API for public health apps — and system-wide contacts tracing which is due to launch next month.

At the time of writing PEPP-PT’s spokesman, Hans-Christian Boos, had not responded to a request for comment on the German government withdrawing support.

Boos previously claimed PEPP-PT had around 40 governments lining up to join the standard. However in recent days the momentum in Europe has been going in the other direction. A number of academic institutions that had initially backed PEPP-PT have also withdrawn support.

In a statement emailed to TechCrunch, the DP-3T project welcomed Germany’s U-turn. “DP-3T is very happy to see that Germany is adopting a decentralized approach to contact tracing and we look forward to its next steps implementing such a technique in a privacy preserving manner,” the group told us.

Berlin’s withdrawal leaves France and the UK the two main regional backers of centralized apps for coronavirus contacts tracing. And while the German U-turn is certainly a hammer blow for the centralized camp in Europe the French government appears solid in its support — at least for now.

France has been developing a centralized coronavirus contacts tracing protocol, called ROBERT, working with Germany’s Fraunhofer Institute and others.

In an opinion issued Sunday, France’s data protection watchdog, the CNIL, did not take active issue with centralizing pseudonymized proximity IDs — saying EU law does not in principle forbid such a system — although the watchdog emphasized the need to minimize the risk of individuals being re-identified.

It’s notable that France’s digital minister, Cédric O, has been applying high profile public pressure to Apple over Bluetooth restrictions — telling Bloomberg last week that Apple’s policy is a blocker to the virus tracker.

Yesterday O was also tweeting to defend the utility of the planned ‘Stop Covid’ app.

« Oui l’application #StopCovid est utile ». Volontaire, anonyme, transparente et temporaire, elle apporte les garanties de protection des libertés individuelles. À la disposition des acteurs sanitaires, elle les aidera dans la lutte contre le #COVID19 https://t.co/12xYG5Z8ZC

— Cédric O (@cedric_o) April 26, 2020

We reached out to France’s digital ministry for comment on Germany’s decision to switch to a decentralized approach but at the time of writing the department had not responded.

In a press release today the government highlights the CNIL view that its approach is compliant with data protection rules, and commits to publishing a data protection impact assessment ahead of launching the app.

If France presses ahead it’s not clear how the country will avoid its app being ignored or abandoned by smartphone users who find it irritating to use. (Although it’s worth noting that Google’s Android platform has a substantial marketshare in the market, with circa 80% vs 20% for iOS, per Kantar.)

A debate in the French parliament tomorrow is due to include discussion of contacts tracing apps.

We’ve also reached out to the UK’s NHSX — which has been developing a COVID-19 contacts tracing app for the UK market — and will update this report with any response.

In a blog post Friday the UK public healthcare unit’s digital transformation division said it’s “working with Apple and Google on their welcome support for tracing apps around the world”, a PR line that entirely sidesteps the controversy around centralized vs decentralized app infrastructures.

The UK has previously been reported to be planning to centralize proximity data — raising questions about the efficacy of its planned app too, given iOS restrictions on background access to Bluetooth.

“As part of our commitment to transparency, we will be publishing the key security and privacy designs alongside the source code so privacy experts can ‘look under the bonnet’ and help us ensure the security is absolutely world class,” the NHSX’s Matthew Gould and Dr Geraint Lewis added in the statement.

Update: The NHSX still hasn’t responded to the questions we sent it this morning about how the app will function but a spokesperson has now told the BBC it intends to push ahead with a centralized approach — and is planning to make use of a workaround to mitigate iOS restrictions by waking up the app in the background every time the phone detects another device running the same software.

Per the BBC: “It then executes some code before returning to a dormant state. This all happens at speed, but there is still an energy impact. By contrast, Apple’s own solution allows the matching to be done without the app having to wake up at all.”

When we followed up with NHSX’s press office to ask why we hadn’t received a response to our questions we were CC’d into another email to additional comms staff, one of whom responded to the group email without realizing our email address was included in the thread — writing: “I thought a line hadn’t been cleared? I checked the NHSEI process earlier and one hadn’t been through there.”

Powered by WPeMatico

Apple and Google are launching a joint COVID-19 tracing tool for iOS and Android

Posted by | Android, api, Apple, Bluetooth, computing, contact tracing, coronavirus, Covid19, Google, Health, Indoor Positioning System, MIT, operating system, operating systems, smartphones, Software, TC, terms of service | No Comments

Apple and Google’s engineering teams have banded together to create a decentralized contact tracing tool that will help individuals determine whether they have been exposed to someone with COVID-19.

Contact tracing is a useful tool that helps public health authorities track the spread of the disease and inform the potentially exposed so that they can get tested. It does this by identifying and “following up with” people who have come into contact with a COVID-19-affected person.

The first phase of the project is an API that public health agencies can integrate into their own apps. The next phase is a system-level contact tracing system that will work across iOS and Android devices on an opt-in basis.

The system uses on-board radios on your device to transmit an anonymous ID over short ranges — using Bluetooth beaconing. Servers relay your last 14 days of rotating IDs to other devices, which search for a match. A match is determined based on a threshold of time spent and distance maintained between two devices.

If a match is found with another user that has told the system that they have tested positive, you are notified and can take steps to be tested and to self-quarantine.

Contact tracing is a well-known and debated tool, but one that has been adopted by health authorities and universities that are working on multiple projects like this. One such example is MIT’s efforts to use Bluetooth to create a privacy-conscious contact tracing tool that was inspired by Apple’s Find My system. The companies say that those organizations identified technical hurdles that they were unable to overcome and asked for help.

Our own Jon Evans laid out the need for a broader tracing apparatus a week ago, along with the notion that you’d need buy-in from Apple and Google to make it happen.

The project was started two weeks ago by engineers from both companies. One of the reasons the companies got involved is that there is poor interoperability between systems on various manufacturer’s devices. With contact tracing, every time you fragment a system like this between multiple apps, you limit its effectiveness greatly. You need a massive amount of adoption in one system for contact tracing to work well.

At the same time, you run into technical problems like Bluetooth power suck, privacy concerns about centralized data collection and the sheer effort it takes to get enough people to install the apps to be effective.

Two-phase plan

To fix these issues, Google and Apple teamed up to create an interoperable API that should allow the largest number of users to adopt it, if they choose.

The first phase, a private proximity contact detection API, will be released in mid-May by both Apple and Google for use in apps on iOS and Android. In a briefing today, Apple and Google said that the API is a simple one and should be relatively easy for existing or planned apps to integrate. The API would allow apps to ask users to opt-in to contact tracing (the entire system is opt-in only), allowing their device to broadcast the anonymous, rotating identifier to devices that the person “meets.” This would allow tracing to be done to alert those who may come in contact with COVID-19 to take further steps.

The value of contact tracing should extend beyond the initial period of pandemic and into the time when self-isolation and quarantine restrictions are eased.

The second phase of the project is to bring even more efficiency and adoption to the tracing tool by bringing it to the operating system level. There would be no need to download an app, users would just opt-in to the tracing right on their device. The public health apps would continue to be supported, but this would address a much larger spread of users.

This phase, which is slated for the coming months, would give the contract tracing tool the ability to work at a deeper level, improving battery life, effectiveness and privacy. If its handled by the system, then every improvement in those areas — including cryptographic advances — would benefit the tool directly.

How it works

A quick example of how a system like this might work:

  1. Two people happen to be near each other for a period of time, let’s say 10 minutes. Their phones exchange the anonymous identifiers (which change every 15 minutes).
  2. Later on, one of those people is diagnosed with COVID-19 and enters it into the system via a Public Health Authority app that has integrated the API.
  3. With an additional consent, the diagnosed user allows his anonymous identifiers for the last 14 days to be transmitted to the system.
  4. The person they came into contact with has a Public Health app on their phone that downloads the broadcast keys of positive tests and alerts them to a match.
  5. The app gives them more information on how to proceed from there.

Privacy and transparency

Both Apple and Google say that privacy and transparency are paramount in a public health effort like this one and say they are committed to shipping a system that does not compromise personal privacy in any way. This is a factor that has been raised by the ACLU, which has cautioned that any use of cell phone tracking to track the spread of COVID-19 would need aggressive privacy controls.

There is zero use of location data, which includes users who report positive. This tool is not about where affected people are but instead whether they have been around other people.

The system works by assigning a random, rotating identifier to a person’s phone and transmitting it via Bluetooth to nearby devices. That identifier, which rotates every 15 minutes and contains no personally identifiable information, will pass through a simple relay server that can be run by health organizations worldwide.

Even then, the list of identifiers you’ve been in contact with doesn’t leave your phone unless you choose to share it. Users that test positive will not be identified to other users, Apple or Google. Google and Apple can disable the broadcast system entirely when it is no longer needed.

All identification of matches is done on your device, allowing you to see — within a 14-day window — whether your device has been near the device of a person who has self-identified as having tested positive for COVID-19.

The entire system is opt-in. Users will know upfront that they are participating, whether in app or at a system level. Public health authorities are involved in notifying users that they have been in contact with an affected person.

The American Civil Liberties Union appears to be cautiously optimistic.

“No contact tracing app can be fully effective until there is widespread, free, and quick testing and equitable access to healthcare. These systems also can’t be effective if people don’t trust them,” said ACLU’s surveillance and cybersecurity counsel Jennifer Granick. “To their credit, Apple and Google have announced an approach that appears to mitigate the worst privacy and centralization risks, but there is still room for improvement. We will remain vigilant moving forward to make sure any contract tracing app remains voluntary and decentralized, and used only for public health purposes and only for the duration of this pandemic.”

Apple and Google say that they will openly publish information about the work that they have done for others to analyze in order to bring the most transparency possible to the privacy and security aspects of the project.

“All of us at Apple and Google believe there has never been a more important moment to work together to solve one of the world’s most pressing problems,” the companies said in a statement. “Through close cooperation and collaboration with developers, governments and public health providers, we hope to harness the power of technology to help countries around the world slow the spread of COVID-19 and accelerate the return of everyday life.”

You can find more information about the contact tracing API on Google’s post here and on Apple’s page here including specifications.

Updated with comment from the ACLU.

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

Senegal’s NIMA Codes to launch address app in 15 African countries

Posted by | africa, Android, api, carsharing, commuting, IBM, kenya, location based service, NIMA Codes, north america, ovi, senegal, Snap, Startups, TC, transport, Uber, United States, west africa | No Comments

Senegalese startup NIMA Codes — a digital mapping service for locations without formal addresses — has upgraded its app and plans to go live in 15 African countries in 2020.

The pre-seed stage startup launched in 2018 around an API that uses mobile-phone numbers to catalog coordinates for unregistered homes and businesses in Senegal.

NIMA Codes is adding a chat tool to its platform, to help users locate and comment on service providers, and is integrating a photo-based location identifier, NIMA Snap, in the application.

“What we offer right now is a reliable street-addressing product. Because it’s very difficult for people…to communicate location in Africa and a lot of services are using location. So we need a service that can communicate reliable locations,” NIMA Codes co-founder and CEO Mouhamadou Sall told TechCrunch.

By several rankings, NIMA Codes has become a top-three downloaded navigation app in Senegal (for Android and iOS). The platform has 16,000 subscribed users and has recorded more than 100,000 searches, according to Sall.

He and co-founder Steven Sakayroun (a software engineer and IBM alum) came up with the idea for assigning location coordinates to mobile numbers in previous software development roles.

“If you look at street addresses in North America, in the end they are just a way to name longitude and latitude, because the computer doesn’t know what 6th Avenue really means,” Sall said.

Because mobile-phone penetration in Senegal and broader Africa is high, mobile numbers serve as a useful reference point to attach location information tagged for both homes and businesses, Sall explained. Mobile-phones can also serve as an entry point for people to input location coordinates to NIMA Codes’ database.

There are advantages to assigning coordinates to digits, versus letters, in Sub-Saharan Africa with its thousands of language groupings, Sall explained. “Nima Codes is a cross-border and language-agnostic solution,” he said.

Mouhamadou Sall

Sall believes that will work to the startup’s advantage when it expands services and database building to all 15 countries of the Economic Community of West African States by the end of 2020.

NIMA Codes is still plotting prospects for its best use-cases and revenue generation. It hasn’t secured partners yet and is still identifying how those downloading the app are using it. “Right now it’s mostly people who download the app…and register locations. Some delivery companies may be using it and not telling us,” said Sall.

Ecowas Countries

The startup plans to generate revenue through partnerships and API usage fees.

Sall believes NIMA Codes’ new image-based location and chat-based business search functions could come together — akin to Google Maps and finding nearby places — to create commercial revenue opportunities across merchants in West Africa’s large, informal economies.

Another obvious plug-in for NIMA Codes’ service is Africa’s fast-growing ride-hail and delivery markets. Sall points to 2019 data that Uber paid $58 million over three years for map and search services.The U.S. ride-hail company has also tested an image-based directions app called OKHi in Kenya. And there are reports of Uber’s imminent expansion into Senegal.

Whatever the application, Sall believes NIMA Codes is cornering a central point of demand in Sub-Saharan Africa.

“The use case is so big, you need to start with something and eventually expand,” he said.

“But everything wraps around having a reliable location service for people and small business.”

Powered by WPeMatico

Amazon introduces new $99 Eero mesh Wi-Fi routers

Posted by | Amazon, Amazon Hardware Event 2019, api, asus, computing, Eero, Europe, Gadgets, google onhub, hardware, linksys, Router, TC, telecommunications, tp-link, United States, wifi, wireless networking | No Comments

Amazon is launching a new generation of Eero router, the first new iteration of Eero hardware since it acquired the company earlier this year. The new router is $99 for one, or available in a three-pack for $249, and is available in the U.S. today and in Europe later this year.

Alongside the new hardware, Amazon has added even more specific voice commands for its routers, including the ability to turn on and off guest Wi-Fi via voice, as well as pause Wi-Fi access for specific devices on the network (Amazon showed off turning off the PlayStation Wi-Fi as one example). These features go above and beyond what’s currently available for third-party devices, but Amazon says it’s also making an API available and that routers from TP-Link, Asus, Linksys and Arris will able to take advantage, as well.
Image from iOS 5

Amazon’s intent with the revised Eero and Alexa commands is to make the whole process of setting up and managing a secure Wi-Fi network super easy for everyone.

Amazon’s updated Eero three-pack will cover a home up to 5,000 square feet in size, the company says, and provide speeds of up to 350 Mbps with dual-band 2.4 GHz and 5 GHz 802.11ac Wi-Fi, with 2 Ethernet ports per device for wired connections. They also include Bluetooth LE 5.0, which is used for simple setup via your smartphone.

The price point on the new Eero is certainly attractive, and more competitive than the previous version, which started at $149 for just a beacon alone, and $199 for the hub.

Powered by WPeMatico