Arbitrary code execution through unsanitized browser UI

If that helps killing ads and analytics, I don't care 1 second.

My point with site isolation was more their continued effort to push interesting, compelling security improvements. Currently, from a corp perspective, enabling site isolation for internal high security websites (SSO pages etc) is possible with GPO and a big win imo.

Please don't take it the wrong way, I think Firefox is awesome too :)

That gives actively misleading information in two cases: if two vendors have different standards for vulnerabilities (e.g., is a tab crash a DoS or just a thing that happens sometimes) and if one vendor is more active at actually looking to find vulnerabilities (or incentivizing others to do so) than another. Both of those problems, inverted, make the metric easily gameable in awful ways: you're encouraging vendors to have a high bar for what counts as a security bug and you're encouraging them not to look.

A little more fundamentally, vulnerability counts don't provide a great measure of security architecture: whether defense-in-depth and least privilege are good at mitigating the impact of bugs. If, say, you have a JS PNG decoder and once a year someone finds a way for a malicious PNG to run arbitrary JS within the usual web JS sandbox, that's probably way better than having an unsandboxed native-code PNG decoder and once every three years someone finds a way for a malicious PNG to run arbitrary code on the host. (Maybe you can do something involving weighting vulnerabilities by CVSS score or something.)

Vulnerability counting is never a metric for security when comparing counts across products.

It's very helpful for counting within a product.

One simple example - A and B are browsers. A has a bounty program that they invest millions into, B does not.

A gets 100 vulnerability reports a month, B gets 5.

Is B safer?

No.

However, let's say we just look at A. It gets 100 a month, and then a new feature is added - suddenly it's 200 a month, and the vulns tend to be in the new codebase. That's interesting information for A - it has nothing to do with B.

Yep, it's disabled by default. It is a great indicator of the forward thinking work they do, though. And from a corp perspective we can push out policies to enable site isolation for high risk websites (SSO).

"The only interesting thing" is a bit disparaging haha that's kind of a big deal. It means that third party iframes, as one example, run in a separate process. It breaks the case where I am evil.com, and you are okta.com, and there is a way for me to leak data within a process (or exploit the process), I can read okta.com's data.

With site isolation is this made considerably more difficult.

It broke add-ons that weren't being maintained, primarily. It's true that for some users, this would be very unpleasant, but I have five extensions working fine here in 59.0b5 (including important security/usability ones like uBlock Origin and Stylus).

> 58 is the fixed version.

FTA: This issue did not affect Firefox for Android or Firefox 52 ESR.

> That's because 57 was a complete dumpster fire.

I disagree.

> It broke all the add ons.

Yes, it did. They probably should've made 56 an ESR.

> Anyone who points this out is granted invisibility powers on HN, so I can see how you would be unaware of this.

They must not be doing a very good job, since I've seen the death of long-loved addons mentioned in every Firefox thread on HN for years.

Clinging to 52 ESR until August 28 is fine. That's what it's there for.

Clinging to 56 is ... well, it's your decision to use what software you want, that's what free software is all about, but since half the point of the changes in 57 was improved security architecture, clinging to 56 and expecting fixes for security bugs seems ill-advised.

ESR is 52. There is absolutely no good reason to use anything but ESR or the properly maintained version. It will only get you into trouble.