FreshRSS

🔒
❌ About FreshRSS
There are new available articles, click to refresh the page.
Yesterday — June 1st 2020Your RSS feeds

Apple has just patched the recent iOS 13.5 jailbreak

By Zack Whittaker

Well that didn’t last long.

Apple has patched a security vulnerability that allowed hackers to build a jailbreak tool allowing deep access to the iPhone software.

In a security advisory, Apple acknowledged that it had fixed the vulnerability in iOS 13.5.1, posted Monday. The technology giant credited the unc0ver team, which released the jailbreak just last week, for finding the vulnerability.

Although details of the vulnerability are not yet public, Apple typically works quickly to patch vulnerabilities that allow jailbreaks, fearing that the same vulnerability could also be abused by malicious hackers.

In a tweet, one of the lead jailbreakers confirmed that updating to iOS 13.5.1 will close the vulnerability and render the jailbreak useless.

I can confirm the new *OS updates have patched the kernel vulnerability used by the #unc0ver jailbreak.

If you are on iOS 13.5, stay and save blobs.

If you are not on iOS 13.5, update to it with the IPSW using a computer while it is still being signed and save blobs.

— @Pwn20wnd (@Pwn20wnd) June 1, 2020

Jailbreaking is a popular way to allow users to break free from Apple’s “jail” — hence the term — that prevents deep access to an iPhone’s operating system. Apple has does this to improve device security and to reduce the surface area in which hackers can attack the software. But jailbreakers say breaking through those restrictions allows them greater customization over their iPhones in a way that most Android users are already used to.

Security experts typically advise against jailbreaking as it can expose a device owner to a greater range of attacks, while advising users to install their devices and software as soon as update become available.

Apple said iOS 13.5.1 also comes with new Memoji stickers and other bug fixes and improvements.

Update today. If security isn’t your thing, at least do it for the Memoji stickers.

Before yesterdayYour RSS feeds

TinyML is giving hardware new life

By Walter Thompson
Adam Benzion Contributor
A serial entrepreneur, writer, and tech investor, Adam Benzion is the co-founder of Hackster.io, the world's largest community for hardware developers.

Aluminum and iconography are no longer enough for a product to get noticed in the marketplace. Today, great products need to be useful and deliver an almost magical experience, something that becomes an extension of life. Tiny Machine Learning (TinyML) is the latest embedded software technology that moves hardware into that almost magical realm, where machines can automatically learn and grow through use, like a primitive human brain.

Until now building machine learning (ML) algorithms for hardware meant complex mathematical modes based on sample data, known as “training data,” in order to make predictions or decisions without being explicitly programmed to do so. And if this sounds complex and expensive to build, it is. On top of that, traditionally ML-related tasks were translated to the cloud, creating latency, consuming scarce power and putting machines at the mercy of connection speeds. Combined, these constraints made computing at the edge slower, more expensive and less predictable.

But thanks to recent advances, companies are turning to TinyML as the latest trend in building product intelligence. Arduino, the company best known for open-source hardware is making TinyML available for millions of developers. Together with Edge Impulse, they are turning the ubiquitous Arduino board into a powerful embedded ML platform, like the Arduino Nano 33 BLE Sense and other 32-bit boards. With this partnership you can run powerful learning models based on artificial neural networks (ANN) reaching and sampling tiny sensors along with low-powered microcontrollers.

Over the past year great strides were made in making deep learning models smaller, faster and runnable on embedded hardware through projects like TensorFlow Lite for Microcontrollers, uTensor and Arm’s CMSIS-NN. But building a quality dataset, extracting the right features, training and deploying these models is still complicated. TinyML was the missing link between edge hardware and device intelligence now coming to fruition.

Tiny devices with not-so-tiny brains

Tia Health gets over $24 million to build a network of holistic health clinics and virtual services for women

By Jonathan Shieber

Tia Health, the developer of a network of digital wellness apps, clinics and telehealth services designed to treat women’s health holistically, has raised $24.275 million in a new round of funding.

The company said the financing would support the expansion of its telehealth and clinical services to new markets, although co-founder and chief executive Carolyn Witte would not disclose, where, exactly those locations would be.

Co-founded initially as a text-based tool for women to communicate and receive advice on sexual health and wellness, Witte and her co-founder Felicity Yost always had bigger ambitions for their business.

Last year, Tia launched its first physical clinic in New York and now boasts a team of 15 physicians, physician assistants, registered nurses, therapists and other treatment providers. The support staff is what helps keeps cost down, according to Witte.

“We reduce the cost of care by 40% [and] we do that through collaborative care staffing. [That] leverages mid-level providers like nurse practitioners to deliver higher-touch care at lower cost,” she said. 

Tia closed its most recent round before shelter-in-place went into effect in New York on March 17, and since then worked hard to port its practices over to telehealth and virtual medicine, Witte said.

Two days later, Tia went live with telehealth services and the company’s membership of 3,000 women responded. Witte said roughly half of the company’s patients have used the company’s telehealth platform. Since Tia began as an app first before moving into physical care services, the progression was natural, said Witte. The COVID-19 epidemic just accelerated the timeline. “In the last 90 days close to 50% of Tia’s 3,000 members have engaged in chat or video,” Witte said. 

The move to telehealth also allowed Tia to take in more money for its services. With changes to regulation around what kinds of care delivery are covered, telehealth is one new way to make a lot of money that’s covered by insurance and not an elective decision for patients.

“That has allowed us to give our patients the ability to use their insurance for that virtual care and bill for those services,” Witte said of the regulatory changes. 

The staff at Tia consists not just of doctors and nurse practitioners (there are two of each), but also licensed clinical therapists that provide mental health services for Tia’s patient population too.

“Before COVID we surveyed our 3,000 patients in NY about what they want and mental health was the most requested service,” said Witte. “We saw a 400% increase in mental health-related messages on my platform. We rolled out this behavioral health and clinical program paired with our primary care.”

As Tia continues to expand the services it offers to its patients, the next piece of the puzzle to provide a complete offering for women’s health is pregnancy planning and fertility, according to Witte.

The company sees itself as part of a movement to repackage a healthcare industry that has concentrated on treating specific illnesses rather than patient populations that have unique profiles and care needs.

Rather than focusing on a condition or medical specialization like cardiology, gastroenterology, gynecology or endocrinology, the new healthcare system treats cohorts or groups of people — those over 65, adult men and women, as groups with their own specific needs that cross these specializations and require different types of care.

We are really focused on collecting longitudinal data to better understand and treat women’s health,” said Witte. “A stepping stone in that regard is expanding our service line to support the pregnancy journey.” 

Tia’s latest round was led by new investor Threshold Ventures, with participation from Acme Ventures (also a new backer) and previous investors, including Define Homebrew, Compound and John Doerr, the longtime managing partner at KPCB.

When the company launched, its stated mission was to use women’s data to improve women’s health.

“We believe reproductive-aged women deserve a similar focus, and a new model of care designed end-to-end, just for us,” the company said in a statement

As Tia continues to stress, women have been “under-researched and underserved by a healthcare system that continues to treat us as ‘small men with different parts’ — all-too-often neglecting the complex interplay of hormones, gene regulation, metabolism and other sex-specific differences that make female health fundamentally distinct from male health. It’s time for that to change.”

But Tia won’t be changing anything on the research front anytime soon. The company is not pursuing any clinical trials or publishing any research around how the ways in which women’s menstrual cycles may affect outcomes or influence other systems, according to Witte. Rather the company is using that information in its treatment of individual patients, she said.

The company did just hire a head of research — an expert in reproductive genomics, which Witte said was to start to understand how the company can build out proof points around how Tia’s care model can improve outcomes. 

Tia will reopen its brick-and-mortar clinic in New York on June 1 and will be expanding to new locations over the course of the year. That expansion may involve partnerships with corporations or existing healthcare providers, the company said.

“By partnering with leading health systems, employers, and provider networks to scale our Connected Care Platform, and open new physical and digital Tia doors, we can make ‘the Tia Way’ the new standard of care for women and providers everywhere,” Tia said in a statement.

As it does so, the company said it will continue to emphasize its holistic approach to women’s health.

As the company’s founders write:

Being a healthy woman is all-too-often reduced to not having an STD or an abnormal Pap, but we know that the leading cause of death for women in America is cardiovascular disease. We also know that women are diagnosed with anxiety and depression at twice the rate of men, and that endocrine and autoimmune disorders are on the rise. In pregnancy, c-section and preterm birth rates continue to go up instead of down, as does maternal mortality, with the U.S. reporting more maternal deaths than any developed country in the world.

We believe that the solution is a preventive “whole women’s health” model…

A new Android bug, Strandhogg 2.0, lets malware pose as real apps and steal user data

By Zack Whittaker

Security researchers have found a major vulnerability in almost every version of Android, which lets malware imitate legitimate apps to steal app passwords and other sensitive data.

The vulnerability, dubbed Strandhogg 2.0 (named after the Norse term for a hostile takeover) affects all devices running Android 9.0 and earlier. It’s the “evil twin” to an earlier bug of the same name, according to Norwegian security firm Promon, which discovered both vulnerabilities six months apart. Strandhogg 2.0 works by tricking a victim into thinking they’re entering their passwords on a legitimate app while instead interacting with a malicious overlay. Strandhogg 2.0 can also hijack other app permissions to siphon off sensitive user data, like contacts, photos, and track a victim’s real-time location.

The bug is said to be more dangerous than its predecessor because it’s “nearly undetectable,” Tom Lysemose Hansen, founder and chief technology officer at Promon, told TechCrunch.

The good news is that Promon said it has no evidence that hackers have used the bug in active hacking campaigns. The caveat is that there are “no good ways” to detect an attack. Fearing the bug could still be abused by hackers, Promon delayed releasing details of the bug until Google could fix the “critical”-rated vulnerability.

A spokesperson for Google told TechCrunch that the company also saw no evidence of active exploitation. “We appreciate the work of the researchers, and have released a fix for the issue they identified.” The spokesperson said Google Play Protect, an app screening service built-in to Android devices, blocks apps that exploit the Strandhogg 2.0 vulnerability.

Standhogg 2.0 works by abusing Android’s multitasking system, which keeps tabs on every recently opened app so that the user can quickly switch back and forth. A victim would have to download a malicious app — disguised as a normal app — that can exploit the Strandhogg 2.0 vulnerability. Once installed and when a victim opens a legitimate app, the malicious app quickly hijacks the app and injects malicious content in its place, such as a fake login window.

When a victim enters their password on the fake overlay, their passwords are siphoned off to the hacker’s servers. The real app then appears as though the login was real.

Strandhogg 2.0 doesn’t need any Android permissions to run, but it can also hijack the permissions of other apps that have access to a victim’s contacts, photos, and messages by triggering a permissions request.

“If the permission is granted, then the malware now has this dangerous permission,” said Hansen.

Once that permission is granted, the malicious app can upload data from a user’s phone. The malware can upload entire text message conversations, said Hansen, allowing the hackers to defeat two-factor authentication protections.

The risk to users is likely low, but not zero. Promon said updating Android devices with the latest security updates — out now — will fix the vulnerability. Users are advised to update their Android devices as soon as possible.

Hackers release a new jailbreak that unlocks every iPhone

By Zack Whittaker

A renowned iPhone hacking team has released a new “jailbreak” tool that unlocks every iPhone, even the most recent models running the latest iOS 13.5.

For as long as Apple has kept up its “walled garden” approach to iPhones by only allowing apps and customizations that it approves, hackers have tried to break free from what they call the “jail,” hence the name “jailbreak.” Hackers do this by finding a previously undisclosed vulnerability in iOS that break through some of the many restrictions that Apple puts in place to prevent access to the underlying software. Apple says it does this for security. But jailbreakers say breaking through those restrictions allows them to customize their iPhones more than they would otherwise, in a way that most Android users are already accustomed to.

The jailbreak, released by the unc0ver team, supports all iPhones that run iOS 11 and above, including up to iOS 13.5, which Apple released this week.

Details of the vulnerability that the hackers used to build the jailbreak aren’t known, but it’s not expected to last forever. Just as jailbreakers work to find a way in, Apple works fast to patch the flaws and close the jailbreak.

Security experts typically advise iPhone users against jailbreaking their devices because breaking out of the walled garden allows users to download apps from third-party stores, vastly increasing the surface area for new vulnerabilities to exist and to be found.

The jailbreak comes at a time where the shine is wearing off of Apple’s typically strong security image. Last week, Zerodium, a broker for exploits, said it would no longer buy certain iPhone vulnerabilities because there were too many of them. It comes as Motherboard reports that hackers got their hands on a pre-release version of the upcoming iOS 14 release several months ago.

3 views on the life and death of college towns, remote work and the future of startup hubs

By Natasha Mascarenhas

The global pandemic has halted travel, shunted schools online and shut down many cities, but the future of college-town America is an area of deep concern for the startup world.

College towns have done exceedingly well with the rise of the knowledge economy and concentrating students and talent in dense social webs. That confluence of ideas and skill fueled the rise of a whole set of startup clusters outside major geos like the Bay Area, but with COVID-19 bearing down on these ecosystems and many tech workers considering remote work, what does the future look like for these cradles of innovation?

We have three angles on this topic from the Equity podcast crew:

  • Danny Crichton sees the death of college towns, and looks at whether remote tools can substitute for in-person connections when building a startup.
  • Natasha Mascarenhas believes connecting with other students is critical for developing one’s sense of self, and the decline of colleges will negatively impact students and their ability to trial and error their way to their first job.
  • Alex Wilhelm looks at whether residential colleges are about to be disrupted — or whether tradition will prevail. His is (surprise!) a more sanguine look at the future of college towns.

Startup hubs are going to disintegrate as college towns are decimated by coronavirus

Danny Crichton: One of the few urban success stories outside the big global cities like New York, Tokyo, Paris and London has been a small set of cities that have used a mix of their proximity to power (state capitals), knowledge (universities) and finance (local big companies) to build innovative economies. That includes places like Austin, Columbus, Chattanooga, Ann Arbor, Urbana, Denver, Atlanta and Minneapolis, among many others.

Over the past two decades, there was an almost magical economic alchemy underway in these locales. Universities attracted large numbers of bright and ambitious students, capitals and state government offices offered a financial base to the regional economy and local big companies offered the jobs and stability that allow innovation to flourish.

All that has disappeared, leading to some critics, like Noah Smith, to ask whether “Coronavirus Will End the Golden Age for College Towns”?

New nonprofit from Google Maps co-creator offers temporary ‘safe’ passes to aid COVID-19 reopening effort

By Darrell Etherington

There are a number of different technologies both proposed and in development to help smooth the reopening of parts of the economy even as the threat of the COVID-19 pandemic continues. One such tech solution launching today comes from Brian McClendon, co-founder of Keyhole, the company that Google purchased in 2004 that would form the basis of Google Earth and Google Maps. McClendon’s new CVKey Project is a registered nonprofit that is launching with an app for symptom self-assessment that generates a temporary QR code, which will work with participating community facilities as a kind of health “pass” on an opt-in basis.

Ultimately, CVKey Project hopes to launch an entire suite of apps dedicated to making it easier to reopen public spaces safely.  Apple and Google recently launched an exposure notification API that would allow CVKey to include those notifications in its apps. CVKey also plans to provide information about facilities open under current government guidelines and their policies to prevent the spread of COVID-19 as much as possible.

The core element of CVKey Project’s approach, however, is the use of a QR code generated by its app that essentially acts as a verification that you’re “safe” to enter one of these shared spaces. The system is designed with user privacy in mind, according to McClendon. Any identity or health data exists only on a user’s individual device — no date is ever uploaded to a cloud server or shared without a user’s consent. Information is also provided about what that sharing entails. Users voluntarily offer their health info, and the app never asks for location information. Most of what it does can be done without an internet connection at all, McClendon explains.

When you generate and scan a QR code at a participating location, a simple binary display (based on the location’s policies) indicates whether you’re cleared to pass. The location won’t see any specifics about your health information. The code simply transmits the particulars of shown symptoms (which ones and how recently, for instance), and then that is matched against the  public space’s policy. The app then provides a “go”/”no-go” response.

McClendon created CVKey Project with former Google Earth, Google Maps and Uber co-workers Manik Gupt and Waleed Kadous, as well as Dr. Marci Nielsen, a public health specialist with a long history of public and private institution leadership.

The apps created by CVKey Project will be available soon, and the nonprofit is looking for potential partners to participate in its program. Like just about everything else designed to address the COVID-19 crisis, it’s not a simple fix, but it could form part of a larger strategy that provides a path forward for dealing with the pandemic.

COVID-19 exposure notification settings begin to go live for iOS users with new update

By Darrell Etherington

Apple has released iOS 13.5, which includes support for the Exposure Notification API that it co-created with Google to support public health authorities in their contact-tracing efforts to combat COVID-19. The API requires third-party apps developed by public health authorities for use, and none have yet been released, but iOS device users already have access to COVID-19 Exposure Logging global settings.

As previewed in the beta release, you can access the Exposure Logging settings under the Settings app, then navigate to the Privacy subsection. From there, you can select the Health submenu and find the COVID-19 Exposure Logging setting, which will be off be default. It can’t be turned on at all until you actually get an authorized app to enable them, at which point you’ll receive a pop-up asking you to authorize Exposure Notifications access. Once you do, you can return here to toggle notifications off, and also manually delete your device’s exposure log should you choose to opt out.

Apple and Google both have emphasized that they want as much user control and visibility into the Exposure Notification API as possible. They’re using randomized, temporary identifiers that are not centrally stored to do the exposure notification, and are also forbidding the simultaneous use of geolocation services and the Exposure Notification API within the same app. This manual control is another step to ensure that users have full control over what info they share to participate in the system, and when.

Contact tracing is a time-tested strategy for combating the spread of infectious disease, and has traditionally worked by attempting to trace potential exposure by interviewing infected individuals and learning as much as possible about their movements during their infectious period. Modern connected devices mean that we can potentially make this far more efficient and accurate, but Google and Apple have worked with privacy experts to try to determine a way to make this happen without exposing users to privacy risks. Matching also happens locally on a user’s device, not in any centralized database.

Apple and Google are currently working with public health authorities who are building apps based on this API, and the companies also have noted that this is a temporary measure that has been designed from the beginning to be disabled once the threat of COVID-19 has passed.

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

By Darrell Etherington

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 developed 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 over 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 exposure 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) since 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.

Microsoft announces Project Reunion to make Windows app development easier again

By Frederic Lardinois

Microsoft today announced a major new initiative that will finally alleviate some of the persistent confusion around Windows app development. Project Reunion, as it is called, is meant to unify the Windows developer platform, which is currently broken up between Win32, which was long the standard way of building Windows app, and the Universal Windows Platform (UWP), which Microsoft started betting on during the ill-fated Windows 8 era (you may remember UWP under the “Metro-style apps” monicker).

This is a move the company signaled at its 2019 developer conference when Microsoft developer platform chief Kevin Gallo already talked about how developers had to Microsoft that they would like it to “decouple many parts of the Universal Windows Platform so that you can adopt them incrementally.” And that’s pretty much what the company is now doing with Project Reunion.

The idea here is to unify access to the existing Win32 and UWP APIs and decouple them from the operating system, using tools like the .NET package manager NuGet.

“This will provide a common platform for new apps,” Gallo writes in today’s announcement for Project Reunion. “Plus, it will help you update and modernize your existing apps with the latest functionality, whether they’re C++, .NET (including WPF, Windows Forms and UWP) or React Native.”

For now, Project Reunion consists of two components that you’ll be able to get your hands on soon. The first is WinUI 3 Preview 1, the latest preview version of Microsoft’s user interface framework for Windows.  “WithWinUI apps can have modern UI that adapts and scales across devices, regardless of whether building a new project or modernizing an existing app (including C++, WPF, and Windows Forms) incrementally,” explains Gallo.

The second is a new preview of WebView2, which now makes it easy to embed a Chromium-based WebView into Windows Forms, WPF, and UWP/ WinUI 3 apps. WebView 2 is decoupled from the operating system and “will bring the power of the Web to the full spectrum of Windows apps.”

It looks like Microsoft will do most of the work on Project Reunion out in the open by using a GitHub repo to share more about the project and to engage with the developer community.

Microsoft’s strategy around Windows app development has remained a bit chaotic over the last few years.

With UWP, Microsoft also hoped to emulate the app store model that had worked so well on mobile platforms. At the beginning of the Store, apps had to be written with UWP, but if you’re anything like me, you never bothered with the Microsoft Store because except for a few marquee apps and maybe a few games, there wasn’t really any reason to use it (and a lot of apps in it were of questionable quality), so last year, Microsoft already relaxed the requirements and allowed Win32 apps. If anything, today’s announcement is Microsoft’s way of salvaging some of the work on UWP and to bring some of the ideas from that framework to the broader Windows developer platform.

As part of today’s announcements around Windows, Gallo also noted that Windows Terminal 1.0, which allows developers to quickly run any executables — no matter whether it’s from a Windows Subsystem for Linux (WSL) distro or the Azure Cloud Shell — is now available for enterprise use.

Talking about the Windows Subsystem for Linux, Microsoft also today announced support for GPU compute workflows for Linux tools and support for Linux graphical user interface apps, so you can run a Linux GUI app directly on your Windows Machine without the need for a third-party X server, which was the case until now. Soon, WSL will also feature a simplified install experience that will let you use the ‘wsl.exe – install’ command to install Linux apps on Windows.

Microsoft updates Teams with new automation and scheduling tools, NDI support for broadcasting and more

By Frederic Lardinois

At its (virtual) Build developer conference, Microsoft today announced a slew of updates for its Teams collaboration and communications platform. Given that Microsoft now sees Teams as its hub for teamwork and collaboration through calls, chats, and audio and video meetings, it’s no surprise that it would highlight Teams across today’s announcements.

For the most part, the new features the company is adding to Teams are pretty straightforward.

For users, most of the important updates are around meetings in teams, where you’ll soon be able to schedule, manage and conduct virtual appointments through the Bookings app, for example. On the scheduling side, Teams is also getting new capabilities in the Shifts app, including new triggers and templates to enable auto-approvals for shift requests, for example, when a managers approval isn’t needed.

In the near future, Microsoft will also add a number of customizable templates to Teams to help new users get started. These include many standard business scenarios like event management and crisis response, as well as industry-specific templates for hospitals and bands, for example. The templates include pre-set channels, apps and guidance, the company says.

Soon, Microsoft will also make Power Virtual Agents chatbots available in the Teams app store, which will make creating and managing these bots easier.

Microsoft will also soon enable a new feature that makes it easier to integrated Power Apps and Power Automate business process templates into Teams, and Power BI users will soon be able to quickly share reports to Teams with the click of a single button.

Another new feature that will have a bit more of a niche audience is Network Device Interface (NDI) support – but that niche will be very happy to hear it’s coming. Currently, you can enable a similar feature in Skype, where it allows you to stream Skype interviews with multiple participants through your favorite streaming software and platform (think OBS, Wirecast, etc.). It allows you to receive separate video streams for every participant (though for reasons only known to the Skype team, you only get one audio feed, which makes dealing with any audio delays a nightmare).

Now, this is also coming to teams so that it’ll be easier for companies to create public or private broadcasts based on Teams chats. Teams will also get integrations with Skype TX, the hardware-based Skype solution that’s used by many broadcast networks to conduct remote interviews. NDI support should go live in Teams next month.

Microsoft launches Project Bonsai, its new machine teaching service for building autonomous systems

By Frederic Lardinois

At its Build developer conference, Microsoft today announced that Project Bonsai, its new machine teaching service, is now in public preview.

If that name sounds familiar, it’s probably because you remember that Microsoft acquired Bonsai, a company that focuses on machine teaching, back in 2018. Bonsai combined simulation tools with different machine learning techniques to build a general-purpose deep reinforcement learning platform, with a focus on industrial control systems.

It’s maybe no surprise then that Project Bonsai, too, has a similar focus on helping businesses teach and manage their autonomous machines. “With Project Bonsai, subject-matter experts can add state-of-the-art intelligence to their most dynamic physical systems and processes without needing a background in AI,” the company notes in its press materials.

“The public preview of Project Bonsai builds on top of the Bonsai acquisition and the autonomous systems private preview announcements made at Build and Ignite of last year,” a Microsoft spokesperson told me.

Interestingly, Microsoft notes that project Bonsai is only the first block of a larger vision to help its customers build these autonomous systems. The company also stresses the advantages of machine teaching over other machine learning approach, especially the fact that it’s less of a black box approach than other methods, which makes it easier for developers and engineers to debug systems that don’t work as expected.

In addition to Bonsai, Microsoft also today announced Project Moab, an open-source balancing robot that is meant to help engineers and developers learn the basics of how to build a real-world control system. The idea here is to teach the robot to keep a ball balanced on top of a platform that is held by three arms.

Potential users will be able to either 3D print the robot themselves or buy one when it goes on sale later this year. There is also a simulation, developed by MathWorks, that developers can try out immediately.

“You can very quickly take it into areas where doing it in traditional ways would not be easy, such as balancing an egg instead,” said Mark Hammond, Microsoft General Manager
for Autonomous Systems. “The point of the Project Moab system is to provide that
playground where engineers tackling various problems can learn how to use the tooling and simulation models. Once they understand the concepts, they can apply it to their novel use case.”

Ford to offer COVID-19 testing for symptomatic workers as part of reopening plan

By Kirsten Korosec

Ford said Saturday it will test hourly and salaried employees with suspected COVID-19 symptoms in four metro areas where it has major operations as it prepares to reopen facilities this month.

The automaker is expected to resume production and some operations at its North America facilities May 18. Aside from factory workers, Ford is also bringing back about 12,000 employees whose jobs cannot be done remotely such as vehicle testing and design. The company’s parts distribution centers reopened in North America on May 11.

Ford said it will initially use polymerase chain reaction (PCR) testing, which identifies if someone is actively infected. PCR tests are used to detect the presence of viral RNA, not the presence of the antibodies, which are the body’s immune response.

The automaker said it has signed contracts with health systems to conduct the testing. Ford will work with Beaumont Health for testing in Southeast Michigan, the University of Louisville Health in Louisville, Liberty Hospital in the Kansas City area and the University of Chicago Medical Center and UChicago Medicine-Ingalls Memorial Hospital in the Chicago area.

Collectively, Ford employs more than 72,000 people in Southeast Michigan, Louisville, Kansas City and Chicago.

The contracts will enable Ford to test employees with suspected symptoms with a goal of getting results back within 24 hours, according to the automaker’s medical director Dr. Walter Talamonti.

Testing results will be simultaneously shared with Ford doctors to help identify other employees who might have been in close contact with an infected worker. Those employees will be required to self-quarantine for 14 days.

The company is working on expanding testing, Ford CTO Ken Washington said in a statement. Washington added that Ford is looking into voluntary antibody testing in the future for its employees.

Ford released May 1 a back-to-work playbook that describes the protocols that it will put in place once production at its factories resume. Employees will have to complete a self-certification health check daily and have their temperature scanned upon arrival to any Ford facility. Face masks will also be required. Safety glasses with side shields or face shields will be required when jobs don’t allow for social distancing.

How will Europe’s coronavirus contact-tracing apps work across borders?

By Natasha Lomas

A major question mark attached to national coronavirus contact-tracing apps is whether they will function when citizens of one country travel to another. Or will people be asked to download and use multiple apps if they’re traveling across borders?

Having to use multiple apps when travelling would further complicate an unproven technology which seeks to repurpose standard smartphone components for estimating viral exposure — a task for which our mobile devices were never intended.

In Europe, where a number of countries are working on smartphone apps that use Bluetooth radios to try to automate some contact tracing by detecting device proximity, the interoperability challenge is particularly pressing, given the region is criss-crossed with borders. Although, in normal times, European Union citizens can all but forget they exist thanks to agreements intended to facilitate the free movement of EU people in the Schengen Area.

Currently, with many EU countries still in degrees of lockdown, there’s relatively little cross-border travel going on. But the European Commission has been focusing attention on supporting the tourism sector during the coronavirus crisis — proposing a tourism and transport package this week which sets out recommendations for a gradual and phased lifting of restrictions.

Once Europeans start traveling again, the effectiveness of any national contact-tracing apps could be undermined if systems aren’t able to talk to each other. In the EU, this could mean, for example, a French citizen who travels to Germany for a business trip — where they spend time with a person who subsequently tests positive for COVID — may not be warned of the exposure risk. Or indeed, vice versa.

In the U.K., which remains an EU member until the end of this year (during the Brexit transition period), the issue is even more pressing — given Ireland’s decision to opt for a decentralized app architecture for its national app. Over the land border in Northern Ireland, which is part of the U.K., the national app would presumably be the centralized system that’s being devised by the U.K.’s NHSX. And the NHSX’s CEO has admitted this technical division presents a specific challenge for the NHS COVID-19 app.

There are much broader questions over how useful (or useless) digital contact tracing will prove to be in the fight against the coronavirus. But it’s clear that if such apps don’t interoperate smoothly in a multi-country region such as Europe, there will be additional, unhelpful gaps opening up in the data.

Any lack of cross-border interoperability will, inexorably, undermine functionality — unless people give up travelling outside their own countries for good.

EU interoperability as agreed goal

EU Member States recognize this, and this week agreed to a set of interoperability guidelines for national apps — writing that: “Users should be able to rely on a single app independently of the region or Member State they are in at a certain moment.”

The full technical detail of interoperability is yet to be figured out — “to ensure the operationalisation of interoperability as soon as possible,” as they put it.

But the intent is to work together so that different apps can share a minimum of data to enable exposure notifications to keep flowing as Europeans travel around the region, as (or once) restrictions are lifted. 

Whatever the approach taken with approved apps, all Member States and the Commission consider that interoperability between these apps and between backend systems is essential for these tools to enable the tracing of cross-border infection chains,” they write. “This is particularly important for cross-border workers and neighbouring countries. Ultimately, this effort will support the gradual lifting of border controls within the EU and the restoration of freedom of movement. These tools should be integrated with other tools contemplated in the COVID-19 contact-tracing strategy of each Member State.”

European users should be able to expect interoperability. But whether smooth cross-border working will happen in practice remains a major question mark. Getting multiple different health systems and apps that might be calculating risk exposure in slightly different ways to interface and share the relevant bits of data in a secure way is itself a major operational and technical challenge.

However, this is made even more of a headache given ongoing differences between countries over the core choice of app architecture for their national coronavirus contact tracing.

This boils down to a choice of either a decentralized or centralized approach — with decentralized protocols storing and processing data locally on smartphones (i.e. the matching is done on-device); and centralized protocols that upload exposure data and perform matching on a central server which is controlled by a national authority, such as a health service.

While there looks to be clear paths for interoperability between different decentralized protocols — here, for example, is a detailed discussion document written by backers of different decentralized protocols on how proximity tracing systems might interoperate across regions — interoperability between decentralized and centralized protocols, which are really polar opposite approaches, looks difficult and messy to say the least.

And that’s a big problem if we want digital contact tracing to smoothly take place across borders.

(Additionally, some might say that if Europe can’t agree on a common way forward vis-à-vis a threat that affects all the region’s citizens, it does not reflect well on the wider “European project”; aka the Union to which many of the region’s countries belong. But health is a Member State competence, meaning the Commission has limited powers in this area.)

In the eHealth Network “Interoperability guidelines” document, Member States agree that interoperability should happen regardless of which app architecture a European country has chosen.

But a section on cross-border transmission chains can’t see a way forward on how exactly to do that yet [emphasis ours] — i.e. beyond general talk of the need for “trusted and secure” mechanisms:

Solutions should allow Member States’ servers to communicate and receive relevant keys between themselves using a trusted and secure mechanism.

Roaming users should upload their relevant proximity encounter information to the home country backend. The other Member State(s) should be informed about possible infected or exposed users*.

*For roaming users, the question of to which servers the relevant proximity contacts details should be sent will be further explored during technical discussions. Interoperability questions will also be explored in relation to how a users’ app should behave after confirmed as COVID-19 positive and the possible need for a confirmation of infection free.

Conversely, the 19 academics behind the proposal for interoperability of different decentralized contact-tracing protocols do include a section at the end of the document discussing how, in theory, such systems could plug into “alternatives”: aka centralized systems.

But it’s thick with privacy caveats.

Privacy risks of crossing system streams

The academics warn that while interoperability between decentralized and centralized systems “is possible in principle, it introduces substantial privacy concerns” — writing that, on the one hand, decentralized systems have been designed specifically to avoid the ability of an central authority being able to recover the identity of users; and “consequently, centralized risk calculation cannot be used without severely weakening the privacy of users of the decentralized system.”

While, on the other, if decentralized risk calculation is used as the “bridge” to achieve interoperability between the two philosophically opposed approaches — by having centralized systems “publish a list of all decentralized ephemeral identifiers it believes to be at risk of infection due to close proximity with positive-tested users of the centralized system” — then it would make it easier for attackers to target centralized systems with reidentification attacks of any positive-tested users. So, again, you get additional privacy risks.

“In particular, each user of the decentralized system would be able to recover the exact time and place they were exposed to the positive-tested individual by comparing their list of recorded ephemeral identifiers which they emitted with the list of ephemeral identifiers published by the server,” they write, specifying that the attack would reveal in which “15-minute” period an app user was exposed to a COVID-positive person.

And while they concede there’s a similar risk of reidentification attacks against all forms of decentralized systems, they contend this is more limited — given that decentralized protocol design is being used to mitigate this risk “by only recording coarse timing information,” such as six-hour intervals.

So, basically, the argument is there’s a greater chance that you might only encounter one other person in a 15-minute interval (and therefore could easily guess who might have given you COVID) versus a six-hour window. Albeit, with populations likely to continue to be encouraged to stay at home as much as possible for the foreseeable future, there is still a chance a user of a decentralized system might only pass one other person over a larger time interval too.

As trade-offs go, the argument made by backers of decentralized systems is they’re inherently focused on the risks of reidentification — and actively working on ways to mitigate and limit those risks by system design — whereas centralized systems gloss over that risk entirely by assuming trust in a central authority to properly handle and process device-linked personal data. Which is of course a very big assumption.

While such fine-grained details may seem incredibly technical for the average user to need to digest, the core associated concern for coronavirus apps generally — and interoperability specifically — is that users need to be able to trust apps to use them.

So even if a person trusts their own government to handle their sensitive health data, they may be less inclined to trust another country’s government. Which means there could be some risk that centralized systems operating within a multi-country region such as Europe might end up polluting the “trust well” for these apps more generally — depending on exactly how they’re made to interoperate with decentralized systems.

The latter are designed so users don’t have to trust an authority to oversee their personal data. The former are absolutely not. So it’s really chalk and cheese.

Ce n’est pas un problème?

At this point, momentum among EU nations has largely shifted behind decentralized protocols for coronavirus contact-tracing apps. As previously reported, there has been a major battle between different EU groups supporting opposing approaches. And — in a key shift — privacy concerns over centralized systems being associated with governmental “mission creep” and/or a lack of citizen trust appear to have encouraged Germany to flip to a decentralized model.

Apple and Google’s decision to support decentralized systems for the contact-tracing API they’re jointly developing, and due to release later this month (sample code is out already), has also undoubtedly weighted the debate in favor of decentralized protocols. 

Not all EU countries are aligned at this stage, though. Most notably France remains determined to pursue a centralized system for coronavirus contact tracing.

As noted above, the U.K. has also been building an app that’s designed to upload data to a central server. Although it’s reportedly investigating switching to a decentralized model in order to be able to plug into the Apple and Google API — given technical challenges on iOS associated with background Bluetooth access.

Another outlier is Norway — which has already launched a centralized app (which also collects GPS data — against Commission and Member States’ own recommendations that tracing apps should not harvest location data).

High-level pressure is clearly being applied, behind the scenes and in public, for EU Member States to agree on a common approach for coronavirus contact-tracing apps. The Commission has been urging this for weeks. Even as French government ministers have preferred to talk in public about the issue as a matter of technological sovereignty — arguing national governments should not have their health policy decisions dictated to them by U.S. tech giants.

“It is for States to chose their architecture and requests were made to Apple to enable both [centralized and decentralized systems],” a French government spokesperson told us late last month.

While there may well be considerable sympathy with that point of view in Europe, there’s also plenty of pragmatism on display. And, sure, some irony — given the region markets itself regionally and globally as a champion of privacy standards. (No shortage of op-eds have been penned in recent weeks on the strange sight of tech giants seemingly schooling EU governments over privacy; while veteran EU privacy advocates have laughed nervously to find themselves fighting in the same camp as data-mining giant Google.)

Commission EVP Margrethe Vestager could also be heard on BBC radio this week suggesting she wouldn’t personally use a coronavirus contact-tracing app that wasn’t built atop a decentralized app architecture. Though the Brexit-focused U.K. government is unlikely to have an open ear for the views of Commission officials, even piped through establishment radio news channels.

The U.K. may be forced to listen to technological reality though, if its workaround for iOS Bluetooth background access proves as flakey as analysis suggests. And it’s telling that the NHSX is funding parallel work on an app that could plug into the Apple-Google API, per reports in the FT, which would mean abandoning the centralized architecture.

Which leaves France as the highest-profile hold-out.

In recent weeks a team at Inria, the government research agency that’s been working on its centralized ROBERT coronavirus contacts-tracing protocol, proposed a third way for exposure notifications — called DESIRE — which was billed as an evolution of the approach “leveraging the best of centralized and decentralized systems.”

The new idea is to add a new secret cryptographically generated key to the protocol, called Private Encounter Tokens (PETs), which would encode encounters between users — as a way to provide users with more control over which identifiers they disclose to a central server, and thereby avoid the system harvesting social graph data.

“The role of the server is merely to match PETs generated by diagnosed users with the PETs provided by requesting users. It stores minimal pseudonymous data. Finally, all data that are stored on the server are encrypted using keys that are stored on the mobile devices, protecting against data breach on the server. All these modifications improve the privacy of the scheme against malicious users and authority. However, as in the first version of ROBERT, risk scores and notifications are still managed and controlled by the server of the health authority, which provides high robustness, flexibility, and efficacy,” the Inria team wrote in the proposal. 

The DP-3T consortium, backers of an eponymous decentralized protocol that’s gained widespread backing from governments in Europe — including Germany’s, followed up with a “practical assessment” of Inria’s proposal — in which they suggest the concept makes for “a very interesting academic proposal, but not a practical solution”; given limitations in current mobile phone Bluetooth radios and, more generally, questions around scalability and feasibility. (tl;dr this sort of idea could take years to properly implement and the coronavirus crisis hardly involves the luxury of time.)

The DP-3T analysis is also heavily skeptical that DESIRE could be made to interoperate with either existing centralized or decentralized proposals — suggesting a sort of “worst of both worlds” scenario on the cross-border functionality front. So, er…

One person familiar with EU Member States’ discussions about coronavirus-tracing apps and interoperability, who briefed TechCrunch on condition of anonymity, also suggested the DESIRE proposal would not fly given its relative complexity (versus the pressing need to get apps launched soon if they are to be of any use in the current pandemic). This person also pointed to question marks over required bandwidth and impact on device battery life. For DESIRE to work they suggested it would need universal uptake by all Europe’s governments — and every EU nation agreeing to adopt a French proposal would hardly carry the torch for nation state sovereignty.

What France does with its tracing app remains a key unanswered question. (An earlier planned debate on the issue in its parliament was shelved.) It is a major EU economy and, where interoperability is concerned, simple geography makes it a vital piece of the Western European digital puzzle, given it has land borders (and train links into) a large number of other countries.

We reached out to the French government with questions about how it proposes to make its national coronavirus contact-tracing app interoperable with decentralized apps that are being developed elsewhere across the EU — but at the time of writing it had not responded to our email.

This week in a video interview with BFM Business, the president of Inria, Bruno Sportisse, was reported to have expressed hope that the app will be able to interoperate by June — but also said in an interview that if the project is unsuccessful “we will stop it.”

“We’re working on making those protocols interoperable. So it’s not something that is going to be done in a week or two,” Sportisse also told BFM (translated from French by TechCrunch’s Romain Dillet). “First, every country has to develop its own application. That’s what every country is doing with its own set of challenges to solve. But at the same time we’re working on it, and in particular as part of an initiative coordinated by the European Commission to make those protocols interoperable or to define new ones.”

One thing looks clear: Adding more complexity further raises the bar for interoperability. And development time frames are necessarily tight.

The pressing imperatives of a pandemic crisis also makes talk of technological sovereignty sound a bit of, well, a bourgeois indulgence. So France’s ambition to single-handedly define a whole new protocol for every nation in Europe comes across as simultaneously tone-deaf and flat-footed — perhaps especially in light if Germany’s swift U-turn the other way.

In a pinch and a poke, European governments agreeing to coalesce around a common approach — and accepting a quick, universal API fix which is being made available at the smartphone platform level — would also offer a far clearer message to citizens. Which would likely help engender citizen trust in and adoption of national apps — that would, in turn, give the apps a greater chance of utility. A pan-EU common approach might also feed tracing apps’ utility by yielding fewer gaps in the data. The benefits could be big.

However, for now, Europe’s digital response to the coronavirus crisis looks messier than that — with ongoing wrinkles and questions over how smoothly different nationals apps will be able to work together as countries opt to go their own way.

Facebook to acquire Giphy in a deal reportedly worth $400 million

By Darrell Etherington

Facebook will acquire Giphy, the web-based animated gif search engine and platform provider, Facebook confirmed today, in a deal worth around $400 million, according to a report by Axios. Facebook said it isn’t disclosing terms of the deal. Giphy has grown to be a central source for shareable, high-engagement content, and its animated response gifs are available across Facebook’s platforms, as well as through other social apps and services on the web.

Most notably, Giphy provides built-in search and sticker functions for Facebook’s Instagram, and it will continue to operate in that capacity, becoming a part of the Instagram team. Giphy will also be available to Facebook’s other apps through existing and additional integrations. People will still be able to upload their own GIFs, and Facebook intends to continue to operate Giphy under its own branding and offer integration to outside developers.

Facebook says it will invest in additional tech development for Giphy, as well as build out new relationships for it on both the content side and the endpoint developer side. The company says that fully 50% of traffic that Giphy receives already comes from Facebook’s apps, including Instagram, Messenger, the FB app itself and WhatsApp .

Giphy was founded in 2013, and was originally simply a search engine for gifs. The website’s first major product expansion was an extension that allowed sharing via Facebook, introduced later in its founding year, and it quickly added Twitter as a second integration. According to the most recent data from Crunchbase, Giphy had raised $150.9 million across five rounds, backed by funders including DFJ Growth, Lightspeed, Betaworks, GV, Lerer Hippeau and more.

Google delays Android 11 by a month

By Frederic Lardinois

Google today announced that it is extending the preview period of Android 11 by about a month. So instead of launching a beta this month, as it had previously planned, it’ll release a fourth developer preview today instead. The first beta will officially launch on June 3, during an Android-centric online event it’ll hold in lieu of its I/O developer conference.

“When we started planning Android 11, we didn’t expect the kinds of changes that would find their way to all of us, across nearly every region in the world,” Google’s Android team writes today. “These have challenged us to stay flexible and find new ways to work together, especially with our developer community. To help us meet those challenges we’re announcing an update to our release timeline.”

Google notes that it wants to meet the needs of the Android ecosystem, which has obviously started work on early app testing for Android 11 based on the company’s guidance, with the current environment during the Coronavirus pandemic and the other priorities that come with that. Delaying the release by a month seems like a reasonable approach in this context.

Google says developers should target the Beta 1 release date of June 3 for releasing a compatible app to gather feedback from the larger group of Android Beta users. And that group will be larger because like with previous releases, Google will make over-the-air updates available to users who opt in to the beta and have a compatible device. The list of compatible devices for the beta remains to be seen, but it’ll likely include all recent Pixel phones, starting with the Pixel 2.

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

By Natasha Lomas

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.

Don’t expect to see Windows 10X dual-screen devices this year

By Frederic Lardinois

With Windows 10X, Microsoft introduced a new version of its flagship operating system last October that was specifically designed for dual-screen devices. The original plan was to launch the first set of Windows 10X dual-screen devices before the 2020 holidays and in February of this year, it announced a slew of tools to help developers get ready for this new form factor. Today, it announced that it is pivoting Windows 10X away from dual-screen devices for the time being. And that means we likely won’t see any dual-screen Windows devices anytime soon.

In a blog post today, Microsoft’s Windows and devices chief Panos Panay said that the company has made this decision because at this time, it wants to focus on what it’s customers need right now and to “focus on meeting customers where they are now.” While Panay doesn’t quite spell it out in his blog post, the idea here is clearly that given the unprecedented environment during the coronavirus pandemic, Microsoft doesn’t want to emphasize new form factors but put its efforts behind improving its existing tools and services.

“With Windows 10X, we designed for flexibility, and that flexibility has enabled us to pivot our focus toward single-screen Windows 10X devices that leverage the power of the cloud to help our customers work, learn and play in new ways,” Panay writes. “These single-screen devices will be the first expression of Windows 10X that we deliver to our customers, and we will continue to look for the right moment, in conjunction with our OEM partners, to bring dual-screen devices to market.”

A single-screen Windows 10X device sounds a lot like a regular laptop, 2-in-1 or tablet. Microsoft declined to define what these first Windows 10X devices will look like and only told us that there’s “more to come.” We’ll be here when that happens.

In his post today, Panay also stressed that the company wants to accelerate innovation in Windows 10 “to ensure that Windows devices are the best way to work, learn and play.” He didn’t share any further details of what exactly that means.

What Panay did say, though, is that Microsoft users now spend 4 trillion minutes a month on Windows 10. That’s an increase of 75 percent year-over-year.

Apple and Google release sample code, UI and detailed policies for COVID-19 exposure-notification apps

By Darrell Etherington

Apple and Google are providing additional resources for developers working with the first version of their Exposure Notification API, the development tools the companies have created and are working on in order to provide a cross-platform way for public health agencies to notify individuals of a potential exposure to a person with a confirmed case of COVID-19.

The first version of the Exposure Notification API, which Apple and Google renamed from the “Contact Tracing API” to more accurately reflect its actual use and purpose, was released to developers last week along with beta updates of iOS and Xcode. Today, Apple and Google are providing new sample resources for developers, including example UI assets, and sample code for both iOS and Android. These are designed as starting points that developers working on behalf of public health agencies can use to jumpstart their app development process.

The two companies have also released new policies that any developers working with the API must adhere to in order to get their apps approved for use. These include the following requirements:

  • They must be made by or for the use of an official government public health authority, and they can only be used for the purpose of responding to COVID-19.
  • They need to ask consent of a user to actually employ the API before it can actually be used.
  • They require a user’s consent to share a positive test result before broadcasting any such info with the public health authority operating the app.
  • They should only gather the minimum amount of info necessary for the purposes of exposure notification, and should use that only for the sake of COVID-19 response. In other words, these apps are explicitly forbidden from using your info for advertising or other purposes.
  • They can’t access or even seek permission to access a device’s Location Services, which provides specific geolocation data. Google and Apple note that apps already available from public health authorities that make use of location data will continue to be offered, but that no apps that make use of that info will also have access to the new Exposure Notification API.
  • There can only be one app per country, which is designed to avoid fragmentation and therefor encourage efficacy, though Apple and Google say that if a country is relying on a regional or state-based approach, they’re willing to work with authorities to support them in the best way possible. That basically means if a country notifies Apple that it’s going state-by-state with different apps, it’ll unlock the ability for multiple apps to appear in that country’s store, and that it can work with them flexibility in terms of whether the exposure notification mechanics within each state work across one another.

The companies say that they’re also going to continue the pace of updates released for their software and software development kits in advance of shipping the public version of the API to consumers starting later this month. Apple and Google had both targeted “mid-May” for the consumer-facing release of the API, with an eventual plan to release exposure notification as a system-level feature by sometime later this year.

You can take a look at the sample UI resources for both platforms below, which provide an idea of what notifications, settings screens and more will look like within the apps once they’re available. Of course, the individual apps will still vary depending on which public health authority (or developer working on their behalf) is creating the software.

[gallery ids="1983325,1983326,1983327,1983328,1983329,1983330,1983331,1983332"]

Apple and Google embarked on this unprecedented joint effort in response to outreach by a number of public health authorities who were embarking on developing their own contact-tracing app, and wanted access to specific aspects of iOS and Android to make those work. The companies decided to collaborate on a standard based on use of Bluetooth identifiers, not geolocation data, as a way to protect user identity, and also ensure the system can work in a variety of environments, including indoors where geolocation satellite services are unavailable.

Health authorities can also require that users input a unique code tied to the test they took, which can help them ensure that positive results are actually coming from verified, authorized tests rather than possibly just self-reported, or reported based on taking a test that hasn’t actually been approved by a health authority for COVID-19 diagnosis.

It’s important to note that the sample reference applications provided by both Google and Apple are not actually ever going to be available to users; they’re strictly for developers, but the companies are making them available in their entirety, including with their full source code, to developers in order to help them with their own efforts to build apps to respond to COVID-19 in a timely manner.

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

By Natasha Lomas

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, 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.

❌