Apple deletes Steve Jobs's “Thoughts on Flash”

(1) https://webkit.org/web-inspector/enabling-web-inspector/

I suspect Apple has internally discussed it and concluded that it would too likely be abused and result in a poor user experience.

Also, Apple deliberately does not like background connections for battery saving reasons which is why everyone is required to use their push service, meaning iOS maintains a single energy efficient connection instead of each app maintaining their own TCP connection which may have no regard for energy efficiency.

I acknowledge it's possible that they don't want to remove reasons for people to rather make native apps, but given the other reasons, it would not be my first guess.

Apple does not want PWAs, they want all apps in the walled garden.

The rest is just “theatre”

Unfortunately that's often what it comes down to. Developers who don't care about the devices they target and their software stack.

Developers should be open to learn new tech, before they reject it. Sure, go the web app route, but don't do it because you look at iOS and the App Store and you "don't know how it works and don't want to have to know".

To me it's not surprising Google wants everything to be a browser with rich permissions that easy to track, search index, put ads on and monetize. This is why they want powerful PWA. This is why Chromebooks are basically... a browser.

Apple on the other hand has crafted a platform optimized for their philosophy of UX and design. And which is often incompatible with these PWA standards that have emerged, which are often honestly sloppy and indiscriminate in wasting a user's power, bandwidth and leeching their private data.

Apple and Google have diametrically opposed goals here.

- Apple wants a free and powerful web, but not a web so powerful it takes over your entire phone, because let's face it, the web is a giant balls of kludges, it's a miracle they work at all.

- Apple wants to save battery, to value user's privacy, and to allow the device to use its full potential through native APIs that are integrated with hardware functions etc. but not abused (which happens without at least cursory review process).

- Google doesn't care about wasting power, doesn't care about privacy, they run an ad business and a search engine. They want three things:

1. Everything everywhere should be the web.

2. The web should have access to everything on your device.

3. Google should own the web.

I want app developers to jump through more hoops than people making websites, and to need my express approval to run their app on my device. I absolutely do not want documents that “progressively” turn into apps. PWA is a bug not a feature.

This, as a user and as a reasonable developer, seems exactly right. The “progressive” part happens when I want it to and initiated by me, so the developer can’t shove it down my throat or trick me into enabling their “app”.

So much of this argument is down to entitled web devs and companies that want to take advantage of the fact I’m reading their website to start installing software, sending notifications, reading from sensors etc. without permission.

That’s not an application it’s malware.

Users actively go to their App Store and choose to download an app. They don’t just get something installed, or not, in some obscure part of their device’s storage, without ever knowing about it.

Well, yeah, which means to me that we'd never try to do this today, but rather would do this once that sort of capability exists. (Just like the people who constantly propose multitenant Workers-like hosting within Erlang. Obviously it could work once sandboxing exists within the runtime, but that's not true today.)

Note that the whole point of Firebase as a service/library—I picked this example for a reason—is to have a local live Javascript object graph whose state is synchronized over the network to a database somewhere; where you can walk it and read it and change it by doing regular Javascript things to it, as if it were a pure in-memory data structure.

If you want to expose that in WASM, you basically need to expose it by exposing Javascript object manipulation semantics to WASM. (Not with WASM holding the objects itself, but rather like any "remote/distributed object" protocol, where WASM holds a handle that references an object, and makes syscalls for dereferencing-get, dereferencing-set, etc., passing that handle.) Without this, what you're exposing isn't really "Firebase" per se, but just a regular database that you send some sort of graph-manipulation queries to.

And this is just one example among many of the sorts of arcane Javascript things where, if the hosting platform didn't allow them, then devs would find the hosting platform worthless and never engage with it.

This is the whole point of the GGP poster's post. They weren't talking about sandboxing NaCl/ZeroVM-like "the code runs in a sealed ABI abstraction that only exposes the syscalls necessary to read the keyboard/mouse and draw to the screen" games. You can easily do that. It's been done. Developers didn't engage in any meaningful way—nothing like the takeup of Newgrounds.

(Heck, it's downright simple to do one of these services yourself: pick an old game console with an HTML5 emulator implementation, e.g. one of the ones used on https://archive.org/details/internetarcade, as your abstract-machine runtime. Games, then, are arbitrary homebrew ROMs. Let people upload them; give them a customizable page that embeds them; wrap it in a trailer + payment-wall page ala itch.io if you like. Do fingerprint analysis to reject commercial ROMs. Done. This service could be built for a hackathon. Would anyone care to develop novel games for it? Pretty doubtful.)

Instead, what the GGP was talking about sandboxing, is almost-but-not-quite arbitrary Turing machines. Because that's what the Flash games/apps posted to Newgrounds really were, and moreover what the modern track-every-click special-gatcha-for-the-thousandth-player-of-the-day variety always are. They use every capability a computer has, such that "sandboxing" in the sense of removing those capabilities doesn't make sense. You can't restrict what capabilities such programs have access to, without just denying the entire design the software is based around. You can only constrain how the game uses those capabilities.

To put that another way: an SMTP server that doesn't let you send mail to certain large email hosting providers is effectively useless. But an SMTP server that doesn't let outgoing messages contain certain words (i.e. has an outbound spam filter) is quite useful. Restricting the what will just turn people away. Restricting the how has no such problem, since certain patterns of data-flow have no other use than to be nefarious.

(If you're curious why I'm even talking about WASM at all, then, if I'm not proposing to take advantage of any of the sandboxing WASM offers: it's just because it's much easier to do your static analysis against a symbolic-execution implementation of bytecode VM for a bytecode ISA like WASM; than it is to do symbolic-execution of an interpreted language with complex syntax, like JS. But if you were willing to go down that route, you could totally static-analyze regular JS. Same safety guarantees, plus now the devs get to use regular JS and/or anything that interfaces with it—including the JS-subset textual form of WASM.)