The Internal Tension of New Web APIs

Mike Zornek reacts to Apple’s decision to decline support for several new APIs on privacy foundations:

But if I’m reading the tea leaves right, and history is a model to follow, what requires “native device” code today will be possible in the web browser of the future. WebAssembly shows great early promise in providing rich cross-platform code opportunities. If you are a 1Password user like me, you are probably already enjoying some WebAssembly today.

However, to build rich user experiences on a mobile device using WebAssembly or inside a normal web app requires access to the sensors and systems of that device. With this collective blocking of access (along with the lack of side loading options on iOS and the ban of non-WebKit rendering in App Store apps) Apple has positioned their own native and financial interests over the favor of an open web.

Here’s the tension: if we give web apps this kind of functionality, we necessarily give it to websites, too. I understand why many developers of web languages ache for these APIs, but I think they are an enormous mistake.

I recognize that this comes across as curmudgeonly, but I do not want desktop app functionality for websites. These technologies surely enable some wonderful experiences but, more often, they create clever new ways to abuse users’ privacy and security. The most popular use of WebAssembly amongst the top million websites, as ranked by Alexa, is to surreptitiously mine cryptocurrency. A website should not be able to have that kind of power, and I welcome greater delineation between the web and desktop-class software.