Apple will soon treat online web tracking the same as a security vulnerability

It is yet to be seen whether that's feasible. Apple and Mozilla are certainly making a lot of progress, but Javascript is very old, and was designed in an era where the attacks were much less sophisticated.

The most promising progress (I think) is in building tracking protection that is undetectable. For example, you can put a permission prompt in front of someone's location and block off the API if the user clicked "no", but you could also just lie about their location, which means you'd still be compatible with most existing pages, and publishers wouldn't be able to strong-arm users into turning off the setting. This is how Firefox currently handles high-resolution timers. You can request them, they'll just lie to you sometimes.

Again, it's yet to be seen whether that kind of stuff will work.

The other hope is that WASM may be good enough on its own to encourage wide adoption -- being able to use (almost) any language to compile to the web is very, very attractive, so WASM might overcome Javascript's network effects (no pun intended) and replace it as the dominant language on the web.

If that happens, WASM might be an opportunity to rethink web permissions. Might.

If neither of those approaches work, then anything is fair game. At that point, we might as well try to make a document-only web, or migrate everyone to a new platform. I think that will be very difficult though.

On the browser side, by serving a unique set of resources to each user, I can identify them in future visits. Roughly speaking, the attack works by inserting a combination of unique asset URLs and repeated asset URLs, and then logging on the server which of those URLS the browser tries to fetch. By responding to fetch requests with 404s or bad assets, the server can avoid having your browser overwrite the unique combination of URLS it has cached, which allows for more persistent tracking.

These caches also work across domains -- that means that if "foo" requests asset "googlepixel/my_id", and "bar" also requests asset "googlepixel/my_id", both will get served from the same cache. This means that caches can be used to track browsers across multiple websites.

On the content-delivery side, the cached images are likely unique to the website you're visiting, and by downloading them, you're letting the 3rd-party know that your IP address visited the page that they're associated with. In a centralized web this is a small concern, to the extent that it allows Cloudflare/Google to know a lot more about what pages your IP is visiting.

In a distributed web like IPFS this is a bigger problem, because now you're connecting to completely random people online to get your assets downloaded. Even worse, you're asking for those images/documents not by going to one specific server and saying, "hey, server X said you had asset Y", but by announcing to the entire network, "hey, I want asset Y, does anyone have it?"

Someone might as well ask what's so great about general purpose computers, or Open Source. The web is a way to share documents, but even from its origin it was also a way to distribute software packages. There are a couple of things that also make it a reasonably decent software runtime, but more on that later.

My goal is that I want to make it easier for ordinary people to share software and to share software modifications -- that means fewer gatekeepers (ie, app stores), less complicated publishing (software should be as portable as possible), and less complicated installation. The removal of those barriers means that software is inherently less trustworthy -- I want ordinary people to be able to share code, but I also don't trust ordinary people that much.

On Linux, our thought process around software has been that distro packagers will read source code and hand-pick which packages are safe. Users can bypass their package managers, but for the most part shouldn't, unless they feel OK reading the source code and evaluating whether the author is trustworthy. This doesn't really scale (see Android), it requires a ton of volunteer work, it makes developing and distributing software much harder, and it puts burdens on end users that are unrealistic.

If we want a world where anyone can write software and anyone can run it, we have to make arbitrary code safer. It's never going to be 100% safe, but a user should feel comfortable downloading and installing an arbitrary app. When I say that currently the web is the best VM, this is what I'm referring to.

Across almost every axis, it is currently safer to visit a random website than it is to download a random app to your phone or desktop computer. And when I talk to people about hardening phone security, they're all caught up on moderation and approval processes, which are actively the wrong direction to go if you think of computers as general-purpose, democratizing devices.

From this point of view, it's less that the web should be a software runtime, and more that making software accessible requires us to have a good software runtime, and currently the web is better than the alternatives. It's pragmatic -- all of the other software runtimes are either less secure (Android/Windows), or less accessible (Qubes OS, actual VMs).

----

> My guess is that you dream of using the internet to create compelling experiences... and you consider documents consisting of text, images and links to other documents woefully inadequate for that purpose

I do want to be able to create compelling experiences and weird stuff, and I think there's an inherent value to having even flawed platforms that enable that. But, let's ignore weird canvas experiments and games, since not everyone cares about them. When we talk about traditional, normal software, my position is the opposite -- that document layout tools are adequate for most software.

Let's ignore the web and just talk about what a good general application framework would look like. Maybe about 60-70% of the software I run today could be using a terminal interface. Pure text is good enough for a large portion of application interfaces, and terminals are usually nicer to use than GUIs.

Most other applications I run natively are just documents, and they'd be better if their interfaces were HTML/CSS. Chat apps, text/database editors, git clients, file navigators, calendars, music players: these are not fundamentally complicated interfaces. The only applications I have installed natively that aren't just interactive documents are fringe-cases: games, image editors, Blender. There's a subset of programmers that get wrapped up in having pixel-level control over how their applications look, and I couldn't care less about how they want their applications to look -- all of their interfaces are just text arranged into tables with maybe a few SVGs on the side. They're documents that I can click on.

HTML and CSS have real problems, and we might want to fix a few of them. But they're already pretty good at laying out documents -- arguably better than most other interface tools that we have. And once you start thinking of applications as interactive documents, a lot of design decisions in HTML/CSS make a lot more sense. For example, if HTML is a language that you use to build a display layer, than it's dumb that there aren't more significant 2-way data-binding tools. But if HTML is a display layer, then it's obvious why we wouldn't want to have a lot of 2-way data-bindings -- they're hard for users to consume.

Where scripting is concerned, we have two options for this theoretical platform: we can run logic locally, or we can run it on a server. A lot of FOSS developers advocate for serverside logic, and I don't understand that, because I think that SaaS is (often) just another form of DRM that takes control away from users. I'd like to move more logic off of servers -- some of the biggest weaknesses of the web come from the fact that everything is so impermanent; you can't pin libraries, you can't run an older version of a website, you can't easily move data around. SaaS makes the majority of those problems worse. If a calculation can be done locally it is often better for the user to avoid the server entirely and bundle everything clientside.

None of this touches on the network layer or user extensions, which could also be long conversations in and of themselves. And again, I want to stress this theoretical application runtime could be anywhere; we could have a document-only web and do applications someplace else. But I don't (usually) see people proposing anything like that when they talk about getting rid of Javascript -- usually their vision ends up being either, "fewer people should write software, and we'll just use the existing native model" or "everything should be SaaS."

I don't like either of those visions. I think most native platforms are just as bad as the web today (worse if you're thinking about security), and I think widespread SaaS is bad for users. Again, this is pragmatic -- it's not that the web is great, or that it doesn't have fundamental problems, it's that the web currently exists and is available to most people, and I don't think any of the native alternatives are comparable. If someone showed me something better, I'd abandon the web in a heartbeat.

The author was describing "gets all users" as in, gets all users that Apple can get. What's next, would you point out how people in the 3rd world wouldn't be buying Apple/Google phones either?

The point was, when Apple has all of the market share they can expect to get, will they turn around and flip tracking on and etc.

Please don't deviate topics for solely pedantic reasons. I generally love pedantic distinctions, but this i think added little to no value.

They still couldn't /legally/ trade on things like "companyX asked us for a loan, so let's buy/short/etc companyX before they announce it", as that would be servicing companyX directly, and they learned the information (about the loan) from that servicing.

[1]: https://news.ycombinator.com/item?id=20729529

AMP, for what it’s worth, is based on existing web standards. It’s a restrictive way of using those standards, but it sits on top of existing standard tech. And Google is using their position as a search engine to push that, not their position as a browser vendor (as evidenced by the fact that AMP has the same effect in Firefox/Safari as it does in Chrome).