Not really. That’s a typical workday for many Gecko developers.
Some useful guidelines made it pretty straightforward:
4,280 karma · joined December 1, 2011
Some useful guidelines made it pretty straightforward:
You wrote:
> The fact that both Brave and Vivaldi were able to disable Google's FlOC within a very short period of time
Okay, they disabled some stuff. That isn’t a fundamental divergence from the upstream project.
The original argument was that Google wouldn’t control the web in a Chromium monoculture because anybody can just fork it.
I disagree. My argument has two prongs:
1. A Chromium fork can only sever itself from Google’s control if it is not taking patches from upstream (ie, Google). I’m particularly thinking about the most consequential pieces: web APIs, not Google ad tech. That’s going to require an army of developers who now are immediately thrust onto the web API treadmill.
2. If a Chromium fork’s market share is tiny, how is it going to displace Google’s influence on the direction of the web? It isn’t. Everybody will still be coding against Google’s Chromium.
Call me when a Chromium fork displaces Chromium.
I don’t think they are. That fork then immediately finds itself in the same position as other engines, where now the fork is going to need to keep up with whatever Google is adding to Chromium.
You might then think, “Then the fork can just pull from upstream.”
Okay, so then:
a) Your fork probably isn’t differentiated enough to matter; and more importantly
b) Google is still effectively calling all the shots!
That’s exactly how I rigged up building our MSIs at Tailscale.
I disagree on that front. Mutex kernel objects have existed just as long as critical sections. Critical section objects are cheaper because they don’t switch into the kernel when not contended.
Rust is encouraged to be used by all developers who are writing native code (it's not supposed to be just the domain of a select few). As I recall, the message was, "Not knowing Rust must not be an excuse for why you're not using Rust." Of course developers must still contend with the practicalities of integrating Rust into an existing C++ codebase, so some guidelines were developed:
Now get off my lawn.
I'm completely speculating, but it's probably a matter of not wanting to complicate iterating on the translation engine by introducing a bunch of cruft from the Firefox build system (which, though it uses GNU make under the hood, is very much bespoke and complicated).
Since the translation engine is intended to run on a product that hosts WASM, they might as well just build to that.
Am I reading this right, you're using ARM now? We were using a Pentium PC (and that was already old for 2004, but good enough for for the course, obviously).
Keep in mind that, in May of 2017, desktop Firefox did not even yet have full support for multiprocess under particular configurations. Obviously you cannot sandbox content processes that don't exist, so there were some prerequisites that needed to be dealt with first. That was pretty much wrapped up by the Firefox Quantum 57 release.
The other thing to note is that the Chromium Sandbox is more like a "sandbox construction kit." It features all kinds of knobs and dials that allow the developer to configure how strict it is. We used to compare adding multiprocess and sandboxing to Gecko to swapping out the warp drive on the Enterprise, while it was still at warp. You can't just flip a switch one day and be sandboxed; too much code existed under the assumption that it could access whatever OS resources it wanted, without restriction. It took time to modify that code to be aware of that restriction and act accordingly. Each time an iteration of modifications were completed, we were able to tighten the screws on the sandbox a little bit more.
Not only has that been very useful as Gecko has been migrated to running in a fully sandboxed environment, it is also a necessity even at the final stage. For example, modern browsers constrain their interactions with the GPU (and its driver) to a dedicated process. That process is sandboxed, but because that process needs access to graphics devices, it obviously needs a weaker sandbox than the other processes hosting web content.
IMHO the win32k lockdown is not "mission accomplished," but is a HUGE indicator of how much code has been migrated to support sandboxing. On desktop, Firefox processes are now site isolated and are disconnected from their platform GUI systems. That's huge -- I'm sure there are still deviations between the Chrome and Firefox sandbox configurations, but they're a lot closer now.
Firefox for Android still has a long way to go (I was working on that when I left Mozilla), but unfortunately it hasn't been treated with the same urgency as desktop. I know that they're still working on that and have been able to make a lot of progress now that site isolation for desktop has been released.
Finally, I should point out that sandboxing is a defense-in-depth measure, but a lot of armchair quarterbacks seem to only ever want to focus on comparing the sandbox between Chrome and Firefox, while completely ignoring how much more of Firefox is written using memory-safe languages. That's important too.
That sandbox (and others, for that matter) more or less follow steps as outlined below:
https://blogs.msdn.microsoft.com/david_leblanc/2007/07/27/pr...
https://blogs.msdn.microsoft.com/david_leblanc/2007/07/30/pr...
https://docs.microsoft.com/en-ca/archive/blogs/david_leblanc...
You’re right, uxtheme can’t be called directly from content because of win32k dependencies. One option could be for content to request the parent to draw those controls, but as you can imagine there are drawbacks to doing that. As usual, there are a lot of trade offs involved.
All that other crap does the exact same stuff to other programs that malware does, except they do so in the name of "security."
mozilla-central only contains GeckoView (the embedding API for Android) which uses Java for the API itself and Kotlin for all the unit tests.