HN user
The cute thing about asm.js is that it was fully backwards compatible with the web: it was just a lot slower without dedicated support. So Epic or whomever could put out a demo that would run just fine in Chrome, but the performance was a lot worse than Firefox which had a dedicated compilation pipeline, so it made Chrome look bad.
One of the big issues with NaCl is that the API it used wasn't standardized at all and there was only a single implementation. You could pick a random function and ask "hey, what happens if you pass in some slightly weird arguments?" and there was no answer beyond "whatever Chrome does". With enough work, maybe that could have been overcome while preserving backwards compatibility, but there were lots of random functions in there because somebody or other had found it useful. WASM was built from the ground up with a standards process and multiple implementations.
The incentive is that Mozilla will pay you thousands of dollars if you find a security bug: https://www.mozilla.org/en-US/security/client-bug-bounty/
We have many outside contributors who have successfully submitted security bugs and received payments.
Fuzzing isn't good at things like dealing with code behind a CRC check, whereas the audit based approach using an LLMs can see the sketchy code, then calculate the CRC itself to come up with a test case. I think you end up having to write custom fuzzing harnesses to get at the vulnerable parts of the code. (This is an example from a talk by somebody at Anthropic.)
That being said, I think there's a lot of potential for synergy here: if LLMs make writing code easier, that includes fuzzers, so maybe fuzzers will also end up finding a lot more bugs. I saw somebody on Twitter say they used an LLM to write a fuzzer for Chrome and found a number of security bugs that they reported.
Mostly I think this just means that having a test case makes it easier to fix and verify. You can't actually take for granted having a test case when fixing a security bug. Sometimes you only have a crash stack or maybe a vague and hypothetical static analysis result.
eventually land the test case
This is just a reference to the fact that we don't land test cases for security bugs immediately in the public repository, to make it harder for attackers. You are right that the LLM only helps with creating the initial test case. Things like running the test case in automation is part of the standard development process.
A general limitation of this approach is that it is only as good as your validator, and there's nothing easier to validate than a test case that creates, say, an AddressSanitizer use-after-free. For subtler issues will we have to more specific validators or will the LLM become better at coming up with other dangerous conditions it will verify? We'll see.
Firefox developers do fix issues found by Coverity. I haven't looked at the results in over a decade, but the last time I did there were a few code patterns we used in a lot of places which Coverity didn't like (but were actually okay the way we were doing them) which resulted in a colossal number of false positives.
Possibly! One of the many areas that might need rethinking in the age of AI (that started in February of this year) is how long security bugs should be hidden. We live in interesting times.
I'd say it leans towards memory corruption kinds of issues, as those are easiest to pass the validator, thanks to AddressSanitizer. I think there's a lot of potential for making the validator more sophisticated. Like maybe you add a JS function that will only crash when run in the parent process and have a validator that checks for that specific crash, as a way for the LLM to "prove" that it managed to run arbitrary JS in the parent. Would that turn up subtler issues? Maybe.
Quantifying the abilities of an LLM is a hard research problem, so I'm not sure if I can describe it in any great way, but Mythos did seem to be fairly clever about putting together things from different domains to find problems.
For instance, in one of the included bugs (2022034) it figured out that a floating point value being sent over IPC could be modified by an attacker in such a way that it would be interpreted by the JS engine as an arbitrary pointer, due to the way the JS engine uses a clever representation of values called NaN-boxing. This is not beyond the realm of a human researcher to find, but it did nicely combine different domains of security.
As the person responsible for accidentally introducing that security problem (and then fixing it after the Mythos report), while I am aware of NaN-boxing (despite not being a JS engine expert), I was focused more on the other more complex parts of this IPC deserialization code so I hadn't really thought about the potential problems in this context. It is just a floating point value, what could go wrong?
The usual sorts of fuzzing and static analyses, using AddressSanitizer and ThreadSanitizer. Also, with a bug bounty program to try to encourage external researchers to report issues. (I work on Firefox security; also I fixed 2 of the bugs linked in the blog post.)
If you go to about:memory and click on "measure" you can see a bit of where the memory is going. The per-tab overhead isn't that high, but unfortunately there's quite a bit of overhead to have the browser open at all, so it looks rather silly when you have a single tab open.
You can't just use a linter to fix buffer overflows, or people would have done it already.
The basic technique (as has been publicly described by Anthropic) is you ask one agent to come up with a test case that triggers, say, an ASan use-after-free. Then you have a second agent that validates the test case. This eliminates a lot of false positives. It gets a little tricky when you allow the first agent to modify the code, which is necessary for things like sandbox escapes where you want to demonstrate that sending bad IPC causes problems.
Not really. The models were pointed specifically at the location of the vulnerability and given some extra guidance. That's an easier problem than simply being pointed at the entire code base.
The flood of reports that open source projects like curl, Linux and Chromium are getting are presumably due to public models like Open 4.6 that released earlier this year, and not models with limited availability.
No, they stopped paying bounties.
You should generally assume that in a web browser any memory corruption bug can, when combined with enough other bugs and a lot of clever engineering, be turned into arbitrary code execution on your computer.
Google already has an AI-powered security vulnerability project, called Big Sleep. It has reported a number of issues to open source projects: https://issuetracker.google.com/savedsearches/7155917?pli=1
The bugs that were issued CVEs (the Anthropic blog post says there were 22) were all real security bugs.
The level of AI spam for Firefox security submissions is a lot lower than the curl people have described. I'm not sure why that is. Maybe the size of the code base and the higher bar to submitting issues plays a role.
I think the trick to making the "shorts" feature stop showing scantily clad women is to use it actively a bit, and only watch the videos that are decidedly something else. I did that for awhile and now my videos are like "let's see what happens when you pour lava on some soda bottles" which I'm not sure I care that much about but at least it isn't embarrassing.
Rust did exist in some form in 2011. Source: I ate lunch with part of the Rust team in 2011.
Each tab can be a dozen or more processes nowadays, thanks to site isolation.
One longstanding issue with gradients was fixed recently.
In my personal opinion, while the flexibility of the old XUL addons was amazing, the two big issues are compatibility and performance.
Compatibility: these addons could be broken very easily because they could depend on almost anything, and with the monthly release cycle, it is very difficult for mod authors to keep up. For instance, some addons would work by taking a core browser function written in JS, convert it to a string, run a regular expression to edit the string, then use eval to create a new function to replace the old one. In some release, the syntax of the "convert a function to a string" output changed slightly and it broke these addons, because it broke the regexp they were using.
Performance: XUL addons could do all sorts of things that are horrible for performance, and there was no real way for a user to tell what was causing it, because the addon wasn't isolated in any way. I ran into somebody who was having severe performance issues because the browser was generating colossal amounts of garbage for no reason. It eventually turned out that on a whim they'd installed a "LaTeX the World" addon, which would look for LaTeX typesetting instructions on pages and replace it with the nice looking output. The problem was, the way it worked was that every 10 seconds or so it would convert the entire contents of every single tab you had open into a zillion strings, search those strings, then throw them out.
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.