Google delays Android 11 by a month

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.

from Android – TechCrunch https://ift.tt/2WC6MiG
via IFTTT

How Apple reinvented the cursor for iPad

Even though Apple did not invent the mouse pointer, history has cemented its place in dragging it out of obscurity and into mainstream use. Its everyday utility, pioneered at Xerox Parc and later combined with a bit of iconic* work from Susan Kare at Apple, has made the pointer our avatar in digital space for nearly 40 years.

The arrow waits on the screen. Slightly angled, with a straight edge and a 45 degree slope leading to a sharp pixel-by-pixel point. It’s an instrument of precision, of tiny click targets on a screen feet away. The original cursor was a dot, then a line pointing straight upwards. It was demonstrated in the ‘Mother of all demos’ — a presentation roughly an hour and a half long that contained not only the world’s first look at the mouse but also hyper linking, document collaboration, video conferencing and more.

The star of the show, though, was the small line of pixels that made up the mouse cursor. It was hominem ex machina — humanity in the machine. Unlike the text entry models of before, which placed character after character in a facsimile of a typewriter, this was a tether that connected us, embryonic, to the aleph. For the first time we saw ourselves awkwardly in a screen.

We don’t know exactly why the original ‘straight up arrow’ envisioned by Doug Engelbart took on the precise angled stance we know today. There are many self-assured conjectures about the change, but few actual answers — all we know for sure is that, like a ready athlete, the arrow pointer has been there, waiting to leap towards our goal for decades. But for the past few years, thanks to touch devices, we’ve had a new, fleshier, sprinter: our finger.

The iPhone and later the iPad didn’t immediately re-invent the cursor. Instead, it removed it entirely. Replacing your digital ghost in the machine with your physical meatspace fingertip. Touch interactions brought with them “stickiness” — the 1:1 mating of intent and action. If you touched a thing, it did something. If you dragged your finger, the content came with it. This, finally, was human-centric computing.

Then, a few weeks ago, Apple dropped a new kind of pointer — a hybrid between these two worlds of pixels and pushes. The iPad’s cursor, I think, deserves closer examination. It’s a seminal bit of remixing from one of the most closely watched idea factories on the planet.

In order to dive a bit deeper on the brand new cursor and its interaction models, I spoke to Apple SVP Craig Federighi about its development and some of the choices by the teams at Apple that made it. First, let’s talk about some of the things that make the cursor so different from what came before…and yet strangely familiar.

—————————

The iPad cursor takes on the shape of a small circle, a normalized version of the way that the screen’s touch sensors read the tip of your finger. Already, this is different. It brings that idea of placing you inside the machine to the next level, blending the physical nature of touch with the one-step-removed trackpad experience.

Its size and shape is also a nod to the nature of iPad’s user interface. It was designed from the ground up as a touch-first experience. So much so that when an app is not properly optimized for that modality it feels awkward, clumsy. The cursor as your finger’s avatar has the same impact wherever it lands.

Honestly, the thinking could have stopped there and that would have been perfectly adequate. A rough finger facsimile as pointer. But the concept is pushed further. As you approach an interactive element, the circle reaches out, smoothly touching then embracing and encapsulating the button.

The idea of variable cursor velocity is pushed further here too. When you’re close to an object on the screen, it changes its rate of travel to get where you want to go quicker, but it does it contextually, rather than linearly, the way that OS X or Windows does.

Predictive math is applied to get you to where you’re going without you having to land precisely there, then a bit of inertia is applied to keep you where you need to be without over shooting it. Once you’re on the icon, small movements of your finger jiggle the icon so you know you’re still there.

The cursor even disappears when you stop moving it, much as the pressure of your finger disappears when you remove it from the screen. And in some cases the cursor possesses the element itself, becoming the button and casting a light ethereal glow around it.

This stir fry of path prediction, animation, physics and fun seasoning is all cooked into a dish that does its best to replicate the feel of something we do without thinking: reaching out and touching something directly.

These are, in design parlance, affordances. They take an operation that is at its base level much harder to do with a touchpad than it is your finger, and make it feel just as easy. All you have to do to render this point in crystal is watch a kid who uses an iPad all day try to use a mouse to accomplish the same task.

The idea that a cursor could change fluidly as needed in context isn’t exactly new. The I-Beam (the cursor type that appears when you hover over editable text) is a good example of this. There were also early experiments at Xerox Parc — the birthplace of the mouse — that also made use of a transforming cursor. They even tried color changes, but never quite got to the concept of on-screen elements as interactive objects — choosing to emulate functions of the keyboard.

But there has never been a cursor like this one. Designed to emulate your finger, but also to spread and squish and blob and rush and rest. It’s a unique addition to the landscape.

—————————

Given how highly scrutinized Apple’s every release is, the iPad cursor not being spoiled is a minor miracle. When it was released as a software update for existing iPads — and future ones — people began testing it immediately and discovering the dramatically different ways that it behaved from its pre-cursors.*

Inside Apple, the team enjoyed watching the speculation externally that Apple was going to pursue a relatively standard path — displaying a pointer on screen on the iPad — and used it as motivation to deliver something more rich, a solution to be paired with the Magic Keyboard. The scuttlebutt was that Apple was going to add cursor support to iPad OS, but even down to the last minute the assumption was that we would see a traditional pointer that brought the iPad as close as possible to ‘laptop’ behavior.

Since the 2018 iPad Pro debuted with the smart connector, those of us that use the iPad Pro daily have been waiting for Apple to ship a ‘real’ keyboard for the device. I went over my experiences with the Smart Keyboard Folio in my review of the new iPad Pro here, and the Magic Keyboard here, but suffice to say that the new design is incredible for heavy typists. And, of course, it brings along a world class trackpad for the ride.

When the team set out to develop the new cursor, the spec called for something that felt like a real pointer experience, but that melded philosophically with the nature of iPad.

A couple of truths to guide the process:

• The iPad is touch first.
• iPad is the most versatile computer that Apple makes.

In some ways, the work on the new iPad OS cursor began with the Apple TV’s refreshed interface back in 2015. If you’ve noticed some similarities between the way that the cursor behaves on iPad OS and the way it works on Apple TV, you’re not alone. There is the familiar ‘jumping’ from one point of interest to another, for instance, and the slight sheen of a button as you move your finger while ‘hovering’ on it.

“There was a process to figure out exactly how various elements would work together,” Federighi says. “We knew we wanted a very touch-centric cursor that was not conveying an unnecessary level of precision. We knew we had a focus experience similar to Apple TV that we could take advantage of in a delightful way. We knew that when dealing with text we wanted to provide a greater sense of feedback.”

“Part of what I love so much about what’s happened with iPadOS is the way that we’ve drawn from so many sources. The experience draws from our work on tvOS, from years of work on the Mac, and from the origins of iPhone X and early iPad, creating something new that feels really natural for iPad.”

And the Apple TV interface didn’t just ‘inspire’ the cursor — the core design team responsible works across groups, including the Apple TV, iPad OS and other products.

—————————

But to understand the process, you have to get a wider view of the options a user has when interacting with an Apple device.

Apple’s input modalities include:

• Mouse (Mac)
• Touchpad (Mac, MacBook, iPad)
• Touch (iPhone, iPad)
• AR (iPhone, iPad, still nascent)

Each of these modalities has situational advantages or disadvantages. The finger, of course, is an imprecise instrument. The team knew that they would have to telegraph the imprecise nature of a finger to the user, but also honor contexts in which precision was needed.

(Image:Jared Sinclair/Black Pixel)

Apple approached the experience going in clean. The team knew that they had the raw elements to make it happen. They had to have a touch sensitive cursor, they knew that the Apple TV cursor showed promise and they knew that more interactive feedback was important when it came to text.

Where and how to apply which element was the big hurdle.

“When we were first thinking about the cursor, we needed it to reflect the natural and easy experience of using your finger when high precision isn’t necessary, like when accessing an icon on the home screen, but it also needed to scale very naturally into high precision tasks like editing text,” says Federighi.

“So we came up with a circle that elegantly transforms to accomplish the task at hand. For example, it morphs to become the focus around a button, or to hop over to another button, or it morphs into something more precise when that makes sense, like the I-beam for text selection.“

The predictive nature of the cursor is the answer that they came up with for “How do you scale a touch analogue into high precision?”

But the team needed to figure out the what situations demanded precision. Interacting with one element over another one close by, for example. That’s where the inertia and snapping came in. The iPad, specifically, is multipurpose computer so it’s way more complex than any single-input device. There are multiple modalities to service with any cursor implementation on the platform. And they have to be honored without tearing down all of the learning that you’ve put millions of users through with a primary touch interface.

“We set out to design the cursor in a way that retains the touch-first experience without fundamentally changing the UI,” Federighi says. “So customers who may never use a trackpad with their iPad won’t have to learn something new, while making it great for those who may switch back and forth between touch and trackpad.”

The team knew that it needed to imbue the cursor with the same sense of fluidity that has become a pillar of the way that iOS works. So they animated it, from dot to I-beam to blob. If you slow down the animation you can see it sprout a bezier curve and flow into its new appearance. This serves the purpose of ‘delighting’ the user — it’s just fun — but it also tells a story about where the cursor is going. This keeps the user in sync with the actions of the blob, which is always a danger any time you introduce even a small amount of autonomy in a user avatar.

Once on the icon, the cursor moves the icon in a small parallax, but this icon shift is simulated — there are not layers here like on Apple TV, but they would be fun to have.

Text editing gets an upgrade as well, with the I-Beam conforming to the size of the text you’re editing, to make it abundantly clear where the cursor will insert and what size of text it will produce when you begin typing.

The web presented its own challenges. The open standard means that many sites have their own hover elements and behaviors. The question that the team had to come to grips with was how far to push conformity to the “rules” of iPad OS and the cursor. The answer was not a one-size application of the above elements. It had to honor the integral elements of the web.

Simply, they knew that people were not going to re-write the web for Apple.

“Perfecting exactly where to apply these elements was an interesting journey. For instance, websites do all manner of things – sometimes they have their own hover experiences, sometimes the clickable area of an element does not match what the user would think of as a selectable area,” he says. “So we looked carefully at where to push what kind of feedback to achieve a really high level of compatibility out the gates with the web as well as with third party apps.”

Any third-party apps that have used the standard iPad OS elements get all of this work for free, of course. It just works. And the implementation for apps that use custom elements is pretty straightforward. Not flick-a-switch simple, but not a heavy lift either.

The response to the cursor support has been hugely positive so far, and that enthusiasm creates momentum. If there’s a major suite of productivity tools that has a solid user base on iPad Pro, you can bet it will get an update. Microsoft, for instance, is working on iPad cursor support that’s expected to ship in Office for iPad this fall.

—————————

System gestures also feel fresh and responsive even on the distanced touchpad. In some ways, the flicking and swiping actually feel more effective and useful on the horizontal than they do on the screen itself. I can tell you from personal experience that context switching back and forth from the screen to the keyboard to switch between workspaces introduces a lot of cognitive wear and tear. Even the act of continuously holding your arm up and out to swipe back and forth between workspaces a foot off the table introduces a longer term fatigue issue.

When the gestures are on the trackpad, they’re more immediate, smaller in overall physical space and less tiring to execute.

“Many iPad gestures on the trackpad are analogous to those on the Mac, so you don’t have to think about them or relearn anything. However, they respond in a different, more immediate way on iPad, making everything feel connected and effortless,” says Federighi.

Remember that the first iPad multitasking gestures felt like a weird offshoot. An experiment that appeared useless at worst but an interesting curiosity at best. Now, on the home button free iPad Pro, the work done by the team that built the iPhone X shines brightly. It’s pretty remarkable that they built a system so usable that it even works on trackpad — one element removed from immediate touch.

Federighi says that they thought about rethinking 3 finger gestures altogether. But they discovered that they work just fine as is. In the case of anything that goes off of the edge you hit a limit and just push beyond it again to confirm and you get the same result.

There are still gaps in the iPad’s cursor paradigms. There is no support for cursor lock on iPad, making it a non starter for relative mouse movement in 3D apps like first person games. There’s more to come, no doubt, but Apple had no comment when I asked about it.

The new iPad cursor is a product of what came before, but it’s blending, rather than layering, that makes it successful in practice. The blending of the product team’s learnings across Apple TV, Mac and iPad. The blending of touch, mouse and touchpad modalities. And, of course, the blending of a desire to make something new and creative and the constraint that it also had to feel familiar and useful right out of the box. It’s a speciality that Apple, when it is at its best, continues to hold central to its development philosophy.

from iPhone – TechCrunch https://ift.tt/3dnbojI

How Apple reinvented the cursor for iPad

Even though Apple did not invent the mouse pointer, history has cemented its place in dragging it out of obscurity and into mainstream use. Its everyday utility, pioneered at Xerox Parc and later combined with a bit of iconic* work from Susan Kare at Apple, has made the pointer our avatar in digital space for nearly 40 years.

The arrow waits on the screen. Slightly angled, with a straight edge and a 45 degree slope leading to a sharp pixel-by-pixel point. It’s an instrument of precision, of tiny click targets on a screen feet away. The original cursor was a dot, then a line pointing straight upwards. It was demonstrated in the ‘Mother of all demos’ — a presentation roughly an hour and a half long that contained not only the world’s first look at the mouse but also hyper linking, document collaboration, video conferencing and more.

The star of the show, though, was the small line of pixels that made up the mouse cursor. It was hominem ex machina — humanity in the machine. Unlike the text entry models of before, which placed character after character in a facsimile of a typewriter, this was a tether that connected us, embryonic, to the aleph. For the first time we saw ourselves awkwardly in a screen.

We don’t know exactly why the original ‘straight up arrow’ envisioned by Doug Engelbart took on the precise angled stance we know today. There are many self-assured conjectures about the change, but few actual answers — all we know for sure is that, like a ready athlete, the arrow pointer has been there, waiting to leap towards our goal for decades. But for the past few years, thanks to touch devices, we’ve had a new, fleshier, sprinter: our finger.

The iPhone and later the iPad didn’t immediately re-invent the cursor. Instead, it removed it entirely. Replacing your digital ghost in the machine with your physical meatspace fingertip. Touch interactions brought with them “stickiness” — the 1:1 mating of intent and action. If you touched a thing, it did something. If you dragged your finger, the content came with it. This, finally, was human-centric computing.

Then, a few weeks ago, Apple dropped a new kind of pointer — a hybrid between these two worlds of pixels and pushes. The iPad’s cursor, I think, deserves closer examination. It’s a seminal bit of remixing from one of the most closely watched idea factories on the planet.

In order to dive a bit deeper on the brand new cursor and its interaction models, I spoke to Apple SVP Craig Federighi about its development and some of the choices by the teams at Apple that made it. First, let’s talk about some of the things that make the cursor so different from what came before…and yet strangely familiar.

—————————

The iPad cursor takes on the shape of a small circle, a normalized version of the way that the screen’s touch sensors read the tip of your finger. Already, this is different. It brings that idea of placing you inside the machine to the next level, blending the physical nature of touch with the one-step-removed trackpad experience.

Its size and shape is also a nod to the nature of iPad’s user interface. It was designed from the ground up as a touch-first experience. So much so that when an app is not properly optimized for that modality it feels awkward, clumsy. The cursor as your finger’s avatar has the same impact wherever it lands.

Honestly, the thinking could have stopped there and that would have been perfectly adequate. A rough finger facsimile as pointer. But the concept is pushed further. As you approach an interactive element, the circle reaches out, smoothly touching then embracing and encapsulating the button.

The idea of variable cursor velocity is pushed further here too. When you’re close to an object on the screen, it changes its rate of travel to get where you want to go quicker, but it does it contextually, rather than linearly, the way that OS X or Windows does.

Predictive math is applied to get you to where you’re going without you having to land precisely there, then a bit of inertia is applied to keep you where you need to be without over shooting it. Once you’re on the icon, small movements of your finger jiggle the icon so you know you’re still there.

The cursor even disappears when you stop moving it, much as the pressure of your finger disappears when you remove it from the screen. And in some cases the cursor possesses the element itself, becoming the button and casting a light ethereal glow around it.

This stir fry of path prediction, animation, physics and fun seasoning is all cooked into a dish that does its best to replicate the feel of something we do without thinking: reaching out and touching something directly.

These are, in design parlance, affordances. They take an operation that is at its base level much harder to do with a touchpad than it is your finger, and make it feel just as easy. All you have to do to render this point in crystal is watch a kid who uses an iPad all day try to use a mouse to accomplish the same task.

The idea that a cursor could change fluidly as needed in context isn’t exactly new. The I-Beam (the cursor type that appears when you hover over editable text) is a good example of this. There were also early experiments at Xerox Parc — the birthplace of the mouse — that also made use of a transforming cursor. They even tried color changes, but never quite got to the concept of on-screen elements as interactive objects — choosing to emulate functions of the keyboard.

But there has never been a cursor like this one. Designed to emulate your finger, but also to spread and squish and blob and rush and rest. It’s a unique addition to the landscape.

—————————

Given how highly scrutinized Apple’s every release is, the iPad cursor not being spoiled is a minor miracle. When it was released as a software update for existing iPads — and future ones — people began testing it immediately and discovering the dramatically different ways that it behaved from its pre-cursors.*

Inside Apple, the team enjoyed watching the speculation externally that Apple was going to pursue a relatively standard path — displaying a pointer on screen on the iPad — and used it as motivation to deliver something more rich, a solution to be paired with the Magic Keyboard. The scuttlebutt was that Apple was going to add cursor support to iPad OS, but even down to the last minute the assumption was that we would see a traditional pointer that brought the iPad as close as possible to ‘laptop’ behavior.

Since the 2018 iPad Pro debuted with the smart connector, those of us that use the iPad Pro daily have been waiting for Apple to ship a ‘real’ keyboard for the device. I went over my experiences with the Smart Keyboard Folio in my review of the new iPad Pro here, and the Magic Keyboard here, but suffice to say that the new design is incredible for heavy typists. And, of course, it brings along a world class trackpad for the ride.

When the team set out to develop the new cursor, the spec called for something that felt like a real pointer experience, but that melded philosophically with the nature of iPad.

A couple of truths to guide the process:

• The iPad is touch first.
• iPad is the most versatile computer that Apple makes.

In some ways, the work on the new iPad OS cursor began with the Apple TV’s refreshed interface back in 2015. If you’ve noticed some similarities between the way that the cursor behaves on iPad OS and the way it works on Apple TV, you’re not alone. There is the familiar ‘jumping’ from one point of interest to another, for instance, and the slight sheen of a button as you move your finger while ‘hovering’ on it.

“There was a process to figure out exactly how various elements would work together,” Federighi says. “We knew we wanted a very touch-centric cursor that was not conveying an unnecessary level of precision. We knew we had a focus experience similar to Apple TV that we could take advantage of in a delightful way. We knew that when dealing with text we wanted to provide a greater sense of feedback.”

“Part of what I love so much about what’s happened with iPadOS is the way that we’ve drawn from so many sources. The experience draws from our work on tvOS, from years of work on the Mac, and from the origins of iPhone X and early iPad, creating something new that feels really natural for iPad.”

And the Apple TV interface didn’t just ‘inspire’ the cursor — the core design team responsible works across groups, including the Apple TV, iPad OS and other products.

—————————

But to understand the process, you have to get a wider view of the options a user has when interacting with an Apple device.

Apple’s input modalities include:

• Mouse (Mac)
• Touchpad (Mac, MacBook, iPad)
• Touch (iPhone, iPad)
• AR (iPhone, iPad, still nascent)

Each of these modalities has situational advantages or disadvantages. The finger, of course, is an imprecise instrument. The team knew that they would have to telegraph the imprecise nature of a finger to the user, but also honor contexts in which precision was needed.

(Image:Jared Sinclair/Black Pixel)

Apple approached the experience going in clean. The team knew that they had the raw elements to make it happen. They had to have a touch sensitive cursor, they knew that the Apple TV cursor showed promise and they knew that more interactive feedback was important when it came to text.

Where and how to apply which element was the big hurdle.

“When we were first thinking about the cursor, we needed it to reflect the natural and easy experience of using your finger when high precision isn’t necessary, like when accessing an icon on the home screen, but it also needed to scale very naturally into high precision tasks like editing text,” says Federighi.

“So we came up with a circle that elegantly transforms to accomplish the task at hand. For example, it morphs to become the focus around a button, or to hop over to another button, or it morphs into something more precise when that makes sense, like the I-beam for text selection.“

The predictive nature of the cursor is the answer that they came up with for “How do you scale a touch analogue into high precision?”

But the team needed to figure out the what situations demanded precision. Interacting with one element over another one close by, for example. That’s where the inertia and snapping came in. The iPad, specifically, is multipurpose computer so it’s way more complex than any single-input device. There are multiple modalities to service with any cursor implementation on the platform. And they have to be honored without tearing down all of the learning that you’ve put millions of users through with a primary touch interface.

“We set out to design the cursor in a way that retains the touch-first experience without fundamentally changing the UI,” Federighi says. “So customers who may never use a trackpad with their iPad won’t have to learn something new, while making it great for those who may switch back and forth between touch and trackpad.”

The team knew that it needed to imbue the cursor with the same sense of fluidity that has become a pillar of the way that iOS works. So they animated it, from dot to I-beam to blob. If you slow down the animation you can see it sprout a bezier curve and flow into its new appearance. This serves the purpose of ‘delighting’ the user — it’s just fun — but it also tells a story about where the cursor is going. This keeps the user in sync with the actions of the blob, which is always a danger any time you introduce even a small amount of autonomy in a user avatar.

Once on the icon, the cursor moves the icon in a small parallax, but this icon shift is simulated — there are not layers here like on Apple TV, but they would be fun to have.

Text editing gets an upgrade as well, with the I-Beam conforming to the size of the text you’re editing, to make it abundantly clear where the cursor will insert and what size of text it will produce when you begin typing.

The web presented its own challenges. The open standard means that many sites have their own hover elements and behaviors. The question that the team had to come to grips with was how far to push conformity to the “rules” of iPad OS and the cursor. The answer was not a one-size application of the above elements. It had to honor the integral elements of the web.

Simply, they knew that people were not going to re-write the web for Apple.

“Perfecting exactly where to apply these elements was an interesting journey. For instance, websites do all manner of things – sometimes they have their own hover experiences, sometimes the clickable area of an element does not match what the user would think of as a selectable area,” he says. “So we looked carefully at where to push what kind of feedback to achieve a really high level of compatibility out the gates with the web as well as with third party apps.”

Any third-party apps that have used the standard iPad OS elements get all of this work for free, of course. It just works. And the implementation for apps that use custom elements is pretty straightforward. Not flick-a-switch simple, but not a heavy lift either.

The response to the cursor support has been hugely positive so far, and that enthusiasm creates momentum. If there’s a major suite of productivity tools that has a solid user base on iPad Pro, you can bet it will get an update. Microsoft, for instance, is working on iPad cursor support that’s expected to ship in Office for iPad this fall.

—————————

System gestures also feel fresh and responsive even on the distanced touchpad. In some ways, the flicking and swiping actually feel more effective and useful on the horizontal than they do on the screen itself. I can tell you from personal experience that context switching back and forth from the screen to the keyboard to switch between workspaces introduces a lot of cognitive wear and tear. Even the act of continuously holding your arm up and out to swipe back and forth between workspaces a foot off the table introduces a longer term fatigue issue.

When the gestures are on the trackpad, they’re more immediate, smaller in overall physical space and less tiring to execute.

“Many iPad gestures on the trackpad are analogous to those on the Mac, so you don’t have to think about them or relearn anything. However, they respond in a different, more immediate way on iPad, making everything feel connected and effortless,” says Federighi.

Remember that the first iPad multitasking gestures felt like a weird offshoot. An experiment that appeared useless at worst but an interesting curiosity at best. Now, on the home button free iPad Pro, the work done by the team that built the iPhone X shines brightly. It’s pretty remarkable that they built a system so usable that it even works on trackpad — one element removed from immediate touch.

Federighi says that they thought about rethinking 3 finger gestures altogether. But they discovered that they work just fine as is. In the case of anything that goes off of the edge you hit a limit and just push beyond it again to confirm and you get the same result.

There are still gaps in the iPad’s cursor paradigms. There is no support for cursor lock on iPad, making it a non starter for relative mouse movement in 3D apps like first person games. There’s more to come, no doubt, but Apple had no comment when I asked about it.

The new iPad cursor is a product of what came before, but it’s blending, rather than layering, that makes it successful in practice. The blending of the product team’s learnings across Apple TV, Mac and iPad. The blending of touch, mouse and touchpad modalities. And, of course, the blending of a desire to make something new and creative and the constraint that it also had to feel familiar and useful right out of the box. It’s a speciality that Apple, when it is at its best, continues to hold central to its development philosophy.

from Apple – TechCrunch https://ift.tt/3dnbojI

Discover is Facebook’s new effort to help people access websites for free — but with limits

Facebook has a new connectivity app called Discover to help those who can’t afford to get online access information on the web.

The service, available through mobile web and Android app, allows users to visit any website in text format (no video, images, audio and other elements that eat up large amounts of data) and consume a few megabytes of internet data.

For Discover, which is part of the company’s Free Basics initiative, Facebook is working with mobile operators in Bitel, Claro, Entel, and Movistar. Discover is currently available in Peru, where it is in the initial testing phase.

In Peru, Discover is offering 10MB of free data to users each day. A Facebook spokesperson told TechCrunch that the partner mobile operator determines the daily data allowance, and it anticipates operators in other countries where Discover would be tested to offer up to 20MB each day.

But nothing is set in stone. “We’ll be assessing how people are using Discover and the amount of daily data more during the trials and may work with our operator partners on adjustments going forward,” the spokesperson said, adding that mobile operators will also determine whether support for photos could be added to Discover.

Eliminating support for videos and images means that Discover users would be able to load dozens of websites in a day without running out of their data allowance.

Discover is the latest of a handful of internet connectivity efforts that Facebook has rolled out in recent years. The company maintains Internet.org, which offers unfettered access to dozens of websites in dozens of markets; and Express WiFi, which allows neighbourhood stores to sell small sachet of internet plans to users, in India. Facebook has partnered with more than 10,000 merchants and stores in the country to sell these data plans.

On the Internet.org website, the company also lists Connectivity Lab, another effort that is part of Free Basics initiative through which it is “exploring a variety of technologies, including high-altitude long-endurance planes, satellites and lasers” to bring more people online. At least one of those tests has been discontinued.

“During the coronavirus public health crisis, we believe it is particularly important to explore ways to help people stay connected and to increase access to health information and other resources on the internet. As part of our ongoing work to connect people to accurate health information, coronavirus health resources will be highlighted on the Discover homepage,” said Yoav Zeevi, a product manager at Facebook.

Facebook’s Free Basics initiative, which has helped tens of millions of people access internet, has also received scrutiny for its approach and some unintended consequences. Internet.org was banned in India after the local authority in the world’s second largest internet market found that the program violated net neutrality principles.

Zeevi said the company has heard the feedback and responded by allowing people to browse all websites. “Our work on Discover has been informed by our broader efforts — including our participation in the Contract for the Web — to expand connectivity and access to the open web while continuing to protect privacy,” he said. Tim Berners-Lee’s Contract for the Web has welcomed the launch of Discover.

Critics have argued that programs such as Internet.org, which has been discontinued in some additional markets, have also fuelled violence in real life.

As Facebook expands its connectivity efforts, some other companies have scaled down their initiatives. Earlier this year, Google discontinued its free Wi-Fi program called Station that offered internet access in more than 400 railway stations in India, and was available at public places in handful of other markets.

In 2018, Wikimedia shut down Wikipedia Zero, a program that allowed more than 800 million people to access the online encyclopaedia in 72 countries for free.

from Android – TechCrunch https://ift.tt/2WynIGN
via IFTTT

A security expert says India’s contact tracing app has flaws. New Delhi says they are ‘by design’

The Indian government has said that its contact tracing app Aarogya Setu “by design” fetches the location data of its 90 million users and allows them to view the concentration of people who have tested positive for the coronavirus in their vicinity.

New Delhi issued the statement after France-based security researcher Baptiste Robert found what he argues are design flaws and privacy issues.

The government said it has always disclosed that it fetches users’ location data, a feature that critics say falls short of the privacy protections offered by similar technologies, including the joint project run by Apple and Google.

Aarogya Setu’s privacy policy says the app — in addition to collecting location data of a user at the time of registration — also “continuously collects your location data and stores securely on your mobile device, a record of all the places you have been at 15-minute intervals.” The app uploads this data to its server along with the user’s digital ID if they test positive for COVID-19, or self-declare seeing symptoms that indicate that they might be infected with the infectious disease, it says.

Collecting location data is a complicated subject, regardless of the good intention of its developers and operators. On Monday, Google and Apple banned the use of location tracking on their coronavirus tracing technology.

While some developers have argued that they need access to location data to track how outbreaks move and identify hotspots, privacy advocates have cautioned that if this data ever gets exposed, it could ostracize those who are affected.

Robert’s other concern is that Aarogya Setu, which was launched early last month, allows anyone to view the concentration of people in 500 meters to up to 10 kilometers who are either suspicious they have coronavirus, or are certain that they have the disease. He told TechCrunch that he was able to develop a script and view similar data for any nook and cranny of the world’s second most populous nation.

He said the government, which introduced a nationwide lockdown in late March, could have kept the radius limited to 500 meters.

In response, New Delhi said that its system is designed in a way that would prevent any script from making bulk requests. Additionally, it said, “getting data for multiple latitude and longitude this way is no different from asking several people of their location’s COVID-19 statistics.”

“All this information is already public for all locations and hence does not compromise on any personal or sensitive data,” the response said.

Some people argued today that at a crisis like this, when thousands of people are dying, these “flaws” were the least of their concerns and that the app served a much greater purpose. But Aarogya Setu, which has amassed 90 million monthly active people in less than 35 days, has also ruffled some feathers for the way it is being scaled up. New Delhi said earlier this month that all government and private sector employees need to have this app installed on their smartphones.

On Tuesday, local authority in Noida city, home to more than 640,000 people, on the outskirts of Delhi, said those who did not have Aarogya Setu app installed on their phone would be fined or sent to prison.

from Apple – TechCrunch https://ift.tt/3fqRiGQ

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

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.

from iPhone – TechCrunch https://ift.tt/2YAcrZc

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

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.

from Apple – TechCrunch https://ift.tt/2YAcrZc