Chromium bug bounty money tree browser
lyra.horse
lyra.horse
The tricky part would be tracking the same part of the code as it moves up and down because of insertions/deletions above it which would cause problems for a naive algorithm based on line numbers.
Just doing it at the file level, like this does, might be good enough to be useful though.
An economic hero. A man of the people. Creating job security for QA departments!
Since that day I always wanted to get into FAANG-type companies, writing buggy code is basically philantropy.
I would add it to my review tools fwiw.
We do it on a symbol level after statically analyzing each change, and everything in the monorepo daily. Our remedy to high risk changes is to run more tests, client tests not unit tests. Sometimes there are 100k client tests to pick, so we rank them and run a small subset.
It is a hard problem. One interesting observation is that there is a culprit symbol or two in the culprit change, but its connectivity is very similar to non culprits in the same change.
Another observation is that the transitively modified callgraph after a change is pretty big, a depth of 50 is not unusual. It is hard to get many useful signals out of it beyond amount of overlap in transitively affected symbols between change and test.
We found file level and build target level to be too coarse, but AST symbols are working.
Some are UI tests, but we don't recommend those, because we found they don't catch breakages as often so we don't support the language they're written in. The tests we recommend are often integration type tests in that they call very higher order functions and often many of them.
It feels like in the big picture sense it would be better to just always using some sort of smarter/slower pointers in this kind of code just for extra defense. I saw in [2] there is some sort of `raw_ptr<T>` type [3] that seems to intend to help, so maybe the crash in [2] was actually successfully defended against?
It's too bad that there's not a good way to have a broader way to switch between dialects within a project where in one place it's "this portion of the code is perf-critical and carefully reviewed" and in another "this portion of the code is perf-oblivious and has lots of async state that's easy to get wrong". I've wondered if it's almost worth mixing two separate languages (like a GCed one for the latter) just to make the distinction clear.
[Disclaimer: worked on this code many years ago, wouldn't be surprised if I caused >0 of these bugs...]
[1] https://bugs.chromium.org/p/chromium/issues/detail?id=120103... [2] https://bugs.chromium.org/p/chromium/issues/detail?id=132323... [3] https://source.chromium.org/chromium/chromium/src/+/main:bas...
Python, with perf critical sections written in C or Rust is pretty much that. From what I hear the Rust-Python bindings are especially good, and make the correctness part easier even in the performance critical parts.
Or you can go the opposite way and call out to a scripting language from your fast language. Today everyone is hyped about wasm for that, but we also have about two decades of computer games using lua for that (and games are probably the single biggest category of performance sensitive software)
You are describing Rust's "unsafe" keyword.
And this kind of code is very literally the original impetus of it. The language was sort of originally designed to implement a browser, after all.
Most of the Chrome UI code is written with Web UI at least. These days I think they should consider typescript for more orchestration things within the browser too. It's a proven strategy by Electron.
I think the momentum is actually around MiraclePtr now though (as you found).
As a views maintainer, I'm familiar with some of the security bugs on the UI side. Clickjacking-type issues are more common there than uafs. Uafs are an issue, but the problems are not so much due to problematic use of unsafe c++ types and idioms as problematic API designs -- resulting in, for example, cases where it's not clear whether an object is expected to be able to respond safely to calls at all, whether or not it's technically alive. Oilpan, MiraclePtr, proper use of smart pointers would all help bandaid the uafs, but are in many cases difficult to apply correctly without understanding (and often fixing) the underlying systemic design problems. Which is happening, but slowly.
There are also more dimensions of tradeoffs involved, but this is long winded enough as it is. The tldr is that at this point I would consider a couple other options better uses of effort for tackling this specific problem compared to converting browser types to oilpan.
For the LayoutObject heirarchy - the team doing that conversion added a NOT_DESTROYED() macro for this reason. It's gross, but was the least worst option.
As an aside - the performance of oilpan is broadly net positive now if you avoid some of the pitfalls. (The largest being a write into a Member<> requires a write-barrier). E.g. Things become trivially destructible, and no ref incrementing/decrementing, etc.
The "we are not going with Rust" blog post, in 2021,
https://security.googleblog.com/2021/09/an-update-on-memory-...
The "we are going with Rust after all" blog post, in 2023,
https://security.googleblog.com/2023/01/supporting-use-of-ru...
Now I am looking forward to when Rust Addon becomes an official way to extend nodejs, instead of community effort via the C bindings.
The treemap library was authored by evmar, chrome OG who's also in this thread.
Edit: Is the raw data somewhere? A sunburst or tree map would be worth trying out
Or perhaps a LOC changed / file LOC based distribution. That would be how buggy each file is, with a $$$ tag.
I was thinking of ROI for reading code. Regularly having a one line issue in a 100 LOC file is very different from a two line issue in a 10'000 LOC file.
And yes, tests need to be excluded, of course. But looks like that's done?
Developers that are high on this metric might want to allow down and think twice next time they commit.
Or not. Metrics are likely not very useful in general.
Narrator: There were functional changes
details {
margin: 5px 5px 5px 12px;
border: 1px solid #aaa;
border-radius: 4px;
padding: 4px;
}
(the border-radius CSS property was first proposed in 2002 [!] as far as I can tell: https://www.w3.org/TR/2002/WD-css3-border-20021107/)
I would argue that you probably shouldn't be making a web browser unless you have plans to change the status quo for web browsers.
In theory, sure.
In practice, there are lany chrome forks and they all chrome with a few features on top.
In theory you can beat usain bolt by just running faster than him.
In practice nobody does.
it's irrelevant what flag your fork (nation state) flies when its marching orders come from above.
I know, it's kind of hilarious considering Apple, but it's chrome 70%, Safari 20% and the rest is various Chrome-based browsers (e.g. Edge) and Firefox with 3.35%.
So Apple has a choice of losing control of the most important app or improving their product, so there is no reason to switch. I am pretty sure they love control more than anything.
Apple and Microsoft would both consider $10m a rounding error