Robert O'Callahan

Yes, this is why people are talking about having "installable" web apps. It sounds like you clearly agree that some sort of explicit user opt-in is needed to get out of the sandbox, which is good; I've seen some people argue that this is too high a bar.

Now it might happen that this will effectively happen as a result of convergence and standardization of browser extension APIs. It'll be interesting to see what happens there.

That said, the manifest of permissions idea is fundamentally broken in at least two related ways:

1) Most users have no rational basis on which to decide whether to grant the permission or not. In fact, I would argue this is all users, due to issue #2:

2) The permissions are either overbroad, such that pretty much any app that wants to do anything interesting asks for them (this is the "all my apps on want to be able to read my contacts and browsing history" syndrome) or there are so many of them that the list becomes way longer than any user would ever read at install time.

You example of a permission for opening arbitrary TCP sockets is an excellent case in point. As a standalone permission, what fraction of users do you think would understand what is actually being granted? Even if you restrict to computer professionals, I suspect that most would not understand the implications without a somewhat lengthy explanation of what the permission actually allows. And even then, in practice it would be rolled into some other more broad permission…

"Logic" suggests Bayesian analysis but you're working with too few bits. When you make an absolute-sounding posterior claim based on thin or non-existent priors, you risk losing sound inference in favor of pushing a preferred conclusion.

I'm disputing your absolute-sounding "Mozilla’s employees are fiercely liberal". Even if you define "liberal" broadly, are they all? Really, no moderates or righties? As I happen to know some, and so do other people, you seem to be using hyperbole at best, if not making things up.

Also your absolute, unhedged "If you have a conservative bone in your body, you are not welcome on the Mozilla campus." Again, counterexamples are known personally to me and others on HN such as @roca. So instead of persuading, you're exaggerating for some reason (to divide and conquer, to get sympathy, it doesn't matter -- the exaggeration is the point and it blows back, assuming you are actually trying to persuade anyone; perhaps you are writing not to persuade?).

Mozilla would have trouble with state law if they actively fired or demoted anyone over past political acts, per California Labor Law 1101 and 1102. Let's agree that is not the case.

That leaves subtler biases. You could be right, especially after I left, that anyone who is known to be "on the right" (conservative is almost useless as a clear political term) would face subtler kinds of hostility, skepticism, pressure. You are probably right about executives, but that's true at a lot of places.…

Huh. I thought PNaCL had cross-platform endian issues from what I'd read at the time.

However: https://www.tomshardware.com/news/chrome-deprecates-pnacl-embraces-webassembly,34583.html

Just mentions API concerns and: https://robert.ocallahan.org/2013/05/blink-pnacl-and-standards.html?gad_source=1 " PNaCl and Pepper are not open standards, and there are not even any proposals on the table to standardize them in any forum. They have documentation, but for the details one must defer to the large bundle of Chrome code that implements them. "

and

"1. NaCl is CPU-specific. That's not suitable for the web.

2. PNaCl is in theory portable, so it is potentially worth considering.

3. However there is no spec for PNaCl, and standardizing it would take an extreme amount of effort: It means standardizing a subset of LLVM IR, which is quite rich and complex, as well as the Pepper plugin API. This is an enormous amount of work that has not even been begun by Google AFAIK."

But you're right, I don't see anyone mentioning any hardware complications.

Oh well. Moot point these days, and I think we're all better off that everyone else stood their ground, in terms of security, integration with JS APIs, and having a variety of WASM implementations.

That’s an excellent idea. Debuggers certainly need better documentation, and guided tours are a good way to teach skills.

Some of the Mozilla folks did livestreams of their development work on Firefox, including debugging sessions. I haven’t watched any lately, but you might search them out. If they kept it up then they might be using RR now, instead of just GDB.

Here’s a demo video for Pernosco: https://robert.ocallahan.org/2019/10/pernosco-demo-video.html

Pernosco is based on RR, but this probably won’t teach you anything about using RR, since the UI is so different. But it was a memorable one because Brendan Gregg produced a really good tutorial for GDB, where he debugged a real problem in a real program (instead of a made–up problem in a program written just to have a made–up problem inserted into it). The Pernosco demo debugs the same problem in the same program, so comparing the two can be quite easy. I would like to see someone the same type of tutorial for RR, and for other debuggers that people like.

I think many commenters here are viewing this only in terms of die cost. But the blog post is not about that: it's about the other costs that this complexity introduces! Each new feature interacts with all the others in complex ways, and each new feature requires significant new engineering efforts by anyone who has to interact directly with x86 assembly (I sketched a few of these use cases below [1]).

The same author has also written [2] about Intel's CET (their attempt to add control flow integrity (CFI) support at the CPU level):

> The tail end of Intel's document is rather terrifying; it tries to enumerate the interactions of their CFI feature with all the various execution modes that Intel currently supports, and leaves me with the impression that they're generally heading over the complexity event horizon.

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

[2] http://robert.ocallahan.org/2016/06/is-control-flow-integrity-worth.html

> The article isn't claiming there is a "one true modern subset" of C++ that they use.

They’re arguing that they’ve found a sufficiently safe subset, which if true would be the first.

It would be a waste of time to relitigate the many programmer-hostile, unsafe decisions the committee has made over the years. I think your programmers who are supposed to “understand and have control over” C++’s arsenal of footguns are more or less fictional and a language designer shouldn’t take them as intended audience.

https://robert.ocallahan.org/2017/07/confession-of-cc-programmer.html (2017)

> Also, I believe the C++ standards committee does care about this, which is why Profiles [1] are being considered.

It was discussed at length why this proposal is insufficient: https://news.ycombinator.com/item?id=45234460