brave-browser VS chromium

At this time I do not posses information about if Brave will support Ubuntu touch or Postmarket, I can only suggest you install one of the APK's available on our repository, if you would like to use the mobile version of Brave.

I keep seeing posts and github entries about the ARM64 support. but when i go to https://brave.com/linux/ it's not clear which of these releases are ARM64 supported. https://github.com/brave/brave-browser/issues/11836 Can someone from the dev community edit the page in a way that we can recognize which is which? Would the ARM64 release work on Postmarket OS? Ubuntu Touch? We want brave on the pinephone.

Brave isn't just based off of open source though. It is open source. Here's the entire source code - https://github.com/brave/brave-browser

1.47.171

Brave Github repository

That's literally untrue. Micrsoft had made >1600 commits as of 2020. They are actively involved in Chromium development. Additionally, they don't have to "own" it. It's completely possible to support a fork just like Brave will be doing. I'm not going to assume your occupation/areas of interest, but I do work in software and this is just how Open Source Software works.

which will be in 2024 for full rollout, and also major forks will hardcode adblockers, not using the manifest API to get around it. also Brave will allegedly always support v2

https://github.com/brave/brave-browser/issues/15645 https://github.com/brave/browser-laptop/issues/13880

I am more paranoid and cautious than, say, 95% of the programmers I've known. Maybe more. I still don't trust myself to write safe C.

Specifically, I do not think I'm smart enough to violate the Chrome team's Rule of 2: https://chromium.googlesource.com/chromium/src/+/master/docs...

> The Rule Of 2 is: Pick no more than 2 of untrustworthy inputs; unsafe implementation language; and high privilege.

I do know of a few C programmers I'd trust: DJB, many of the OpenBSD team, the Dovecot maintainers, and a few others with long track records of security.

But I don't trust myself because I've used fuzzers on my Rust code, trying billions of inputs. And I've found DDOS bugs that would have been crashing bugs in C.

What's more damning, the most careful C code I ever wrote has an enormous, sneaky test suite. It was tested with every sanitizer I could find. It used carefully designed error handling conventions. Still, in the last 20 years, it has been the subject of several CVEs. You see, I relied on a high-quality 3rd party XML parser, and that parser had a handful of bugs.

Out of 7 billion people on this planet, the number that I'd personally trust to reliaby write CVE-free C code is in the low triple digits. I'm not one of them.

Understanding Rust is a cakewalk compared to understanding "undefined behavior" in the C standard, or to making sure a large C program never overflows an addition, or accesses memory out of bounds. But Rust is not the only option.

As an industry, we need to stop making the same endless security mistakes. It's not OK.

Time to dig out my Wyse 50 again! https://chromium.googlesource.com/chromium/src/+/HEAD/docs/o...

Thanks. Yes, rendering and shaping are distinct but some of the linked libraries did one, the other, or both and the parent commenter singled out rastering which is how I ended up putting FreeType and HarfBuzz in the same sentence. Even then both are commonly used in tandem (see [1]-[9]) and have a few overlapping functionalities.

> it does support BiDi, complex script shaping

Hey, that is indeed quite good. Would you mind if I ask you how well is the support for popular Asian languages?

> linking C and Rust in WASM is unfortunately not really possible

Damn. I am not very experienced in Rust but I would not have guessed that. I apologize if I misrepresented difficulties related to targeting WASM.

[1] https://github.com/apple-oss-distributions/WebKit/tree/WebKi...

[2] https://github.com/apple-oss-distributions/WebKit/tree/WebKi...

[3] https://github.com/chromium/chromium/tree/main/third_party/f...

[4] https://github.com/chromium/chromium/tree/main/third_party/h...

[5] https://searchfox.org/mozilla-central/source/modules/freetyp...

[6] https://searchfox.org/mozilla-central/source/gfx/harfbuzz

[7] https://cs.android.com/android/platform/superproject/+/maste...

[8] https://cs.android.com/android/platform/superproject/+/maste...

[9] https://www.amazon.com/gp/help/customer/display.html?nodeId=...

The word "Zygote" will actually be really clear to anyone who's been exposed to Chrome's multiprocess architecture.

https://chromium.googlesource.com/chromium/src/+/HEAD/docs/l...

> A zygote process is one that listens for spawn requests from a main process and forks itself in response. Generally they are used because forking a process after some expensive setup has been performed can save time and share extra memory pages.

With that background, --zygote isn't actually a flag at all. If you click on it it takes you to a string constant, but that string is actually a value for the --type flag. e.g. an unsandboxed zygote process would have `--type=zygote`.

`--type` is itself an internal flag, explaining it's lax description of "Flags spied upon from other layers.". However it is briefly described in the documentation I linked above.

Chromium license is permissive: https://github.com/chromium/chromium/blob/main/LICENSE