Couple of things I like so far:

- It's pretty narrowly scoped to a single-origin, it doesn't try to provide a bunch of hooks around closing the browser, navigating off page, directly entering URLs. Single-origin scoping (with occasionally opt-in permissions to do more) should probably be the default for features like this, so it's encouraging to see proposals with that philosophy.

- That very narrow scoping also allows you to do some kind of cool things like easily inspect the navigation history, without exposing a bunch of cross-origin risks.

- It's asynchronous and you can interrupt/hook around requests. This gets rid of the need to mark up every link with click handlers, which is both a win for developers and a win for users, because it means people will be more likely to just use normal in-app links rather than building their own (clumsy) navigation systems that break semantic HTML, right-clicking, and opening in-app links in new tabs.

- Extending on the above, having singular intercepts for in-app navigation opens up the doors for browsers/extensions to have more control over stuff like this. I can imagine a theoretical browser preference that allowed you to mess with this list, or change how intercepts worked. In theory, it makes it easier for users to mess with things, while also making it easier for developers to build things. But that's something I'd need to think more about.

I would need to read through the entire proposal in more detail to have a more concrete opinion, it's a lot longer of a proposal than you'd expect from the title/summary, but as both a developer and a user I like what I've seen so far. Seems like a low-risk feature with a number of large potential upsides.

Maybe it's good that you can't try to trap users on your site --- JS is abusive enough as it is. Then again, perhaps increasing opportunities for abuse will also greatly popularise JS whitelisting.

I default-block JS on sites I visit, but I still want JS to be safer, and I want the new feature proposals to avoid making security worse. I am skeptical that accelerationism is a good strategy that we should be encouraging for web security.

Let me expand on that instead of being dismissive. Part of the reason why I don't think it's a good strategy to purposefully make JS dangerous so people are more careful about it is that I'm not sure what the end goal of that plan is. Say you succeed, and everyone becomes scared to run JS code on a website. Okay, great, but now what? Popularizing JS-blockers is one thing, but for all of the criticism about the web, online apps satisfy a need that no other application platform does. There is no other general application platform where it's mostly safe to run random untrusted code, and users really want a platform where they can do that.

I default-block JS because I don't currently trust the browser mechanisms that exist today to protect my privacy/security in all cases. But I want to eventually trust them. I want JS to get more secure over time, not less -- I'd like to eventually live in a world where I'm not default-blocking JS at all. Blocking JS is a cudgel; if the language is too insecure, then it just becomes unsafe to ever enable it in any context.

And sure, I understand that at least a few people on HN would love a JS-free web, and I do get where they're coming from, but I've never heard a good (and feasible) proposal from those people about what can replace the web as an app environment. Some theories, occasionally, but nothing with momentum that I think is likely to succeed. And what we have -- both native environments and phones -- none of them are safe enough where you'd feel comfortable executing random unvetted code dozens or hundreds of times every day. Virtually all of them are easier to fingerprint, native Linux security right now is a disaster, iOS is getting better, but it's still not great. You'd be foolish to install a dozen iOS apps every day. And we have the extra problem that a nontrivial portion of iOS's security comes at the cost of Apple waging (imo) a low-key war against general purpose computing and user control over their own devices.

I occasionally hear people say that we shouldn't try to create a safe web-like application runtime at all, they say people should just vet all the code the run. But I don't think that's a realistic position to take. Users don't want to think about a link to an application before they click on it, and to be honest, it is genuinely kind of crappy that they need to. There's a very clear reason why all of us would want to be able to see a cool app and just immediately run it without worrying that it'll install malware. And users want both that security and the freedom to publish any content or code that they create without going through gatekeepers. For better or worse, there's nothing else that gets as close to that as the web right now, and I am loathe to get rid of that just so I can encourage users to be a little bit more cautious about the existing privacy/security risks in JS today.

So before we purposefully make JS less safe so that more people will block it, I'd like to hear what the actual end game is, and I'd like to hear what the alternative platform is going to be and how people plan to secure it. Absent some kind of concrete, realistic proposal with momentum behind it, I want to make JS more secure/private, not less.

Yes, of course you can store that data in application memory, and that's what we currently do (we send it with runtime exception errors so we can try to reproduce the problem). But, it would be nice if that function was inherent to the browser instead of everyone downloading that code in all of our applications. Then it could persist through page refreshes too.