mccr8

The article says: "OpenAI's browser is built atop Chromium, Google's own open-source browser code, two of the sources said."

rlbox is used for more than one library: "Now, we’re bringing that technology to all supported Firefox platforms (desktop and mobile), and isolating five different modules: Graphite, Hunspell, Ogg, Expat and Woff2"

https://blog.mozilla.org/attack-and-defense/2021/12/06/webas...

Their concern is not with theoretical vulnerabilities, but actual ones that are being exploited. If an attacker never tries to find a vulnerability in some code, then it might as well not have it.

Firefox uses unified builds, where a bunch of .cpp files are globbed together and compiled at once. That helps a lot, but a build still takes a bit of time unless you are on an absurdly fast machine. Chrome used to also support this, called "jumbo builds", but they didn't want to deal with the maintenance overhead. Presumably all of the Chrome developers employed by Google are using some kind of massive distributed build infrastructure so there's little impact of slower builds on individual developer productivity, so the use case of building on a single computer is not as prioritized.

That's the CTO, not the CEO.

According to news stories, Apple received $20 billion dollars in 2022 from Google to make Google the default search in Safari.

https://www.theverge.com/2024/5/2/24147007/google-paid-apple...

Firefox also uses reference counting plus a trial deletion based cycle collector to manage C++ DOM objects (and cycles through JS). In fact, Graydon was responsible for the initial implementation.

I got 35.7 ± 2.3 on a MacBook Pro M3, Chrome 122.

That commit says it is for 1515930. The Chrome releases page says that CVE-2024-0519 is associated with 1517354, which is what I linked to. There may be a connection between CVE-2024-0519 and CVE-2024-0517, but none is mentioned on the Chrome releases page which is what I'm going by.

If you are running untrusted code in Node, subtle JIT bugs are probably the least of your problems.

There's not a lot of context in this submission, but presumably it is being linked because the release notes for this CVE says "Google is aware of reports that an exploit for CVE-2024-0519 exists in the wild."

https://chromereleases.googleblog.com/2024/01/stable-channel...

Here's the diff: https://chromium.googlesource.com/v8/v8/+/389ea9be7d68bb189e...

There's no need to speculate, as the article literally says that: "Industry groups agree: Sounds Profitable, a podcast monetization trade group, lobbied Apple to make the change, and said that it would lead to more accurate audience info and more effective advertising."

Battery status was disabled in Firefox in 2016.

https://www.theguardian.com/technology/2016/nov/01/firefox-d...

There have long been working Spectre attacks. From skimming the paper a bit, I think the contribution of this work is that they have come up with an attack that works on Apple's processors, as well as bypasses for a number of mitigations WebKit has (that fall short of site isolation).

The paper does imply that, but I would disagree that it is more hardened. I would guess that this strict process per tab model is Safari's attempt to get some degree of isolation despite not having true site isolation.

> Given that both the calling window and the newly opened window share mutual references to each other, isn't the next side channel attack lurking around the corner, even if these windows are rendered by separate processes?

Non-same-origin opener references only allow very restricted operations. It is possible that there are undiscovered issues, but it is a lot less powerful than running in the same process. It isn't like having a raw pointer from one window to another.

Chromium and Firefox have implemented site isolation on their desktop browsers, so pages that are not same site should never be loaded in the same process. On mobile browsers, Chromium's site isolation is limited, and Firefox has not finished implementing it.

https://www.chromium.org/Home/chromium-security/site-isolati...

FWIW, I filed a bug a few days ago for the issue I was seeing. A profile showed that Firefox was spending all of its time evaluating a regex. Which is weird because Chrome uses the same regex engine. https://bugzilla.mozilla.org/show_bug.cgi?id=1845775

The linked graph is for Firefox Nightly (currently 117) running on Windows.

Are the versions of WebKit that ship on those consoles patched regularly and kept up to date? Probably not, so I don't think it is too relevant to how secure Safari is. There have been plenty of zero days for Chrome, but that doesn't mean it is somehow the least secure browser.

Comparing CVE counts is a bit nonsensical. For instance, Chrome and Firefox don't individually assign CVEs for internally reported vulnerabilities.

For instance, in these patch notes Chrome lists "Various fixes from internal audits, fuzzing and other initiatives" and doesn't even look to have a CVE:

https://chromereleases.googleblog.com/2022/05/stable-channel...

Or for Firefox, there's a dozen or so bundled together in a single CVE under "Memory safety bugs fixed in Firefox 101":

https://www.mozilla.org/en-US/security/advisories/mfsa2022-2...

It was broken for a couple of hours, and late at night in the Americas. You might have been asleep for the entire duration of the outage.

The ocean's real big.

The quote the article is based around is discussing a new web API in the context of deciding what Mozilla thinks about it. If Mozilla isn't going to have any opinions on new web APIs, then what is even the point of Firefox? (Disclaimer, I work on Firefox but I know anything about specs.)

https://github.com/mozilla/standards-positions/issues/453

This is probably referring to some work to use Stencil for self-hosted code. That reduced process overhead by 6%, which is quite a bit: https://bugzilla.mozilla.org/show_bug.cgi?id=1688794

There might have been some other Stencil work that landed in 92 to reduce memory.

There's a description of what Stencil is, and some work related to it that landed in Firefox 90 and 91, here: https://spidermonkey.dev/blog/2021/07/19/newsletter-firefox-...

I think the overhead is something more like 15MB per process, on Windows. It is higher on other OSes, due in part to the way they load executables. In practice, the total overhead is less bad than you might expect, because people usually don't have that many unique sites open. Telemetry shows that unique sites per tab decreases as the number of tabs increases.

It really depends on what web sites you have open. If you have a single tab with an ad-laden news site, the overhead will be high, but if you have a bunch of Google Docs tabs open, there's no overhead.

Being rude isn't going to discourage malicious actors, who are motivated by fame or wealth.

If you ran a bank and had a bunch of rude bank tellers, you are only going to dissuade customers, not bank robbers.

Iterator invalidation was the cause of a Firefox zero day in 2016. https://bugzilla.mozilla.org/show_bug.cgi?id=1321066

If you go to about:memory and click on "Measure" you can get some information about what is in memory. In addition to web pages, Firefox uses child processes for things like the new tab page, extensions, talking to the GPU, and some other things. It also uses a preallocated process like another commenter suggested, to speed up opening a new page.

This happens if another instance of Firefox or an external package manager updates Firefox while you are running Firefox. This can happen if you have installed Firefox via a Linux package manager, or if you are running Firefox with multiple profiles.

While I understand that it is very annoying if you hit this issue, it is not done as some kind of trick to try to get you to update. The issue is that Firefox is trying to start a new content process to load your page, but the old executable no longer exists so it is impossible.