Why I believe native apps are not doomed by progressive web apps

November 13, 2016

Recently I was reading Eric Elliot's Native Apps are Doomed (via lobste.rs), which puts forward the premise that most native apps on phones and tablets are going to be replaced by progressive web apps. I disagree with the article, but not for the reasons you might expect. In fact, I think the reason why progressive web apps are not going to replace native apps is summarized quite neatly by another recent web related story, of Firefox removing the Battery Status API. Firefox hasn't taken this step because the API doesn't work or isn't used. It's the other way around; the API works too well. As with a number of other web APIs, clever people are abusing the API to surreptitiously extract privacy-invasive information from people's browsers. This is the problem with a lot of powerful device-related APIs that are accessible to websites; many of them have turned out to be great ways to fingerprint devices or invade privacy in other ways.

In my opinion, this is the core problem of progressive web apps and the core advantage of native apps. Progressive web apps are fundamentally websites, yet to create an experience comparable to native apps they want access to powerful and invasive device APIs that are likely to be increasingly restricted or simply unavailable (as Battery Status is likely to end up). Given this, it's worth asking just why native apps get to have such powerful access (beyond simply 'history'). In my view, this has two parts.

First, native apps generally require active installation and then actively being invoked before they can do any harm; they don't just appear, running (not if the phone's OS has anything to say about it). This gives the phone's user a lot of chances to bail out or to limit the damage an intrusive app might do (even by something as simple as not running it very often because you're not interested in it). Second, native apps are generally at least a bit screened by the app store involved in an attempt (in part) to catch nasty apps. And if something egregious is later discovered in an app, the app store can generally do something about it. This is a deliberate choice on the part of app stores; they want to create user trust because users who trust apps to not be evil are users who are willing to install more of them.

It's pretty clear that you can't give progressive web apps either of these two things without making them basically an implementation technique for native apps, which is not really what people want for them. If you want the freedom of the web, you get the security problems of the web too and with them the limitations that phone browsers are going to impose on the web in order to protect their users.

(Permission popups for websites are not the answer, not if the phone actually cares about protecting people. First, you'd need far too many of them in order to give access to all the device APIs. Second, in practice pervasive popups lead to alert fatigue, causing users to blindly approve everything.)

PS: Given the privacy risks created by new browser-accessible device APIs, the easy approach for phone and tablet vendors is simply to not create them. While you might be able to create an API without privacy risks or with low privacy risks, it's clearly going to take more work and you risk screwing it up. Doing nothing, creating no API, definitely does not create privacy risks and it takes no work either, and you can tell people who want those APIs 'make a native app'.

Written on 13 November 2016.
« Modern shells and running shell scripts while seteuid
Open source and the problem of pure maintenance »

Page tools: View Source, Add Comment.
Search:
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Sun Nov 13 23:24:23 2016
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.