bholley's comments

The system is mediated by the browser, so the source code can be inspected by anyone and verified not to leak information.

The idea is to leverage information from site A (say, a bank) who knows a lot about the user to attest to site B (say, HN) that the user is a real person, without revealing any other information known by site A to site B.

Sorry, I should have been more clear. I believe we use the masking on 32-bit platforms, which is faster than explicit bounds checks. On 64-bit platforms we use guard pages. We don't actually need a signal handler, because we don't need to gracefully recover from a fault like we do on the Web — we can just crash.

I believe the implementation in Firefox masks off the high bits of pointers and adds the result to the base address before performing a load/store. This requires us to reserve a power-of-two-sized region of address space, but we can lazily/incrementally commit the pages as the sandboxed code invokes sbrk.

Deukhoofd is correct — we compile the WASM code back into C in order to reuse and reduce friction with our existing compilation pipeline.

It varies. Here's an example of some performance analysis I did on the expat port: https://bugzilla.mozilla.org/show_bug.cgi?id=1688452#c37

Beyond the reasons others have mentioned, another key issue is that this isn't a transparent transformation. The sandboxed code can only access memory within a restricted subregion, which often requires some small code changes on both sides of the boundary (for example, copying input data into that memory region so that sandboxed code can operate on it).

So implementing this in the compiler would entail some fairly involved handshaking between the code and the compiler beyond the normal scope of C/C++. Doing this in a library instead — and leaning on a well-understood and well-studied execution model — makes everything a bit more natural to work with.

The purpose of RLBox is to add an extra layer of component-level isolation on top of Firefox's process-based site-level isolation. The reduced overhead is relative to the hypothetical scenario in which we performed the component-level isolation with processes (rather than WebAssembly).

We made the decision several years ago to integrate Servo components individually rather than trying to replace the entire engine (for the reasons outpost in the blog post linked above).

We invest a lot in Gecko though, precisely because it's important to have a world-class independent engine.

Respectfully: The Firefox layout team did not have a plan to integrate Layout 2020 (we hadn't yet found a way to ship it incrementally), and doing so was never the basis of our strategy to compete with LayoutNG.

I led the Stylo project to integrate Servo's CSS engine into Firefox as part of project Quantum [1]. I have the utmost respect for the engineers on the Servo team, and am sad to see them go (though I am certain they will have no shortage of opportunities as to what to work on next).

Servo had two major roles within Mozilla - as an incubator for novel browser technology we wanted to ship in Firefox, and more recently, as a lighter-weight vehicle for Mixed Reality products. The latter has been the focus for the last three years, and those products now appear to be winding down. But the former was a huge success - both Servo's parallel CSS engine and its GPU-based graphics layer are now shipping in Firefox.

While it seems unlikely that Mozilla will continue to prototype things in Servo, we're still building lots of innovative technology (and writing lots of Rust code) directly in Firefox. A few of the teams have blogged recently about the work they're doing [2] [3], and I'd encourage anyone interested to check it out.

The Servo team accomplished a ton and left its ongoing mark on the Web. These changes are tough for everyone within Mozilla, but are not indicative of any change in strategy for Firefox. Gecko is alive and well, and there are no plans to switch to Blink.

[1] https://bholley.net/blog/2017/stylo.html [2] https://mozilla-spidermonkey.github.io/blog/ [3] https://mozillagfx.wordpress.com/

See https://bugzilla.mozilla.org/show_bug.cgi?id=1511726

Assuming you're on non-Windows, the message is expected and not indicative of a problem. I've pushed a patch to disable it going forward. Sorry for the noise.

Yeah, we do prioritize Mac disproportionately to its market share for that reason. It does sometimes happen that we have to make hard calls though, and that's what Jeff is referring to.

On that note, one of the key motivators behind WebRender (our new graphics backend) is that it provides hardware acceleration across all platforms, including mac (whereas our current Direct2D acceleration works only on Windows). So Mac graphics performance should generally improve once we get that shipped.

Sounds like ghost windows. Try disabling all your add-ons to see if the problem persists? You can also record a profile via perfht.ml and send it to me, I'm happy to have a look.

Using the rhetoric of the parent, in case that wasn't clear.

Per my comment above, there's a misunderstanding here. The goal was to delight Mr Robot viewers and turn them into Firefox users. This was about marketing, not revenue, and I believe no money changed hands.

Thank you (and pault) for the kind word and understanding!

I'm not privy to the details, nor have I ever seen Mr Robot. That said, I believe there were hints in the show about using Firefox to solve some mystery. The idea was that users would then go open Firefox (which may have been sitting unused on their machine for years), and then discover that Firefox and Mr Robot were in cahoots. The viewers would presumably find this cool and exciting, but everyone else demonstrably found it creepy.

If I understand correctly, at some point when following the breadcrumbs the user is given the opportunity to opt in to the game. I think everyone now agrees that this opt-in step should have triggered the download and installation of the add-on, rather than the activation of a dormant add-on that was deployed to every single Firefox user.

My impression (without any internal knowledge on the subject) is that this was intended as a way to promote Firefox to Mr Robot viewers. A lot of people in this thread seem to have this backwards, IIUC - it's not an ad for Mr Robot, it's the onboarding experience of an ad for Firefox that ran in Mr Robot.

The folks behind this presumably wanted this experience to be seamless, and were also trying to keep it under wraps to preserve the surprise factor. This meant that they bypassed the usual processes by which Firefox engineers would have had the opportunity to (a) raise concerns about the deployment approach, and (b) suggest other mechanisms that would have achieved the desired experience while keeping deployment appropriately scoped.

It's really heartbreaking that it ended up this way. The marketing team was trying to think outside the box to bring new users to Firefox, which is crucial if Quantum is to succeed. Surprises and stealth are the bread and butter of marketing, but they didn't think through the dangers of applying those things to engineering. Moreover, the very nature of surprise and stealth meant that they missed the chance for internal feedback before it went live.

A lot of us inside Mozilla are hurting right now. We poured our lives into Quantum for two years for the long-shot dream of giving Firefox a fresh start and saving the web from monopoly. It's frustrating to feel that all our hard-earned goodwill might be squandered by a few people and a botched marketing stunt. But the people behind that stunt were only trying to help, and I'm sure they feel especially terrible right now too.

Mozilla will learn from this. But the mistakes here are probably less sinister than they may appear, and it would be sad if they caused our most closely-aligned users to switch to Chrome.

Since I gave that talk, it's become more clear to me that servo's layout engine is a lot farther from feature-complete than the CSS engine was. So my hunch is that the granularity of incrementalism we used for stylo may not be workable for layout.

That said, we are absolutely going to explore opportunities for more Rust/Servo in layout, so we just need to find the right strategy. One incremental step I'm interested in exploring is to rewrite Gecko's frame constructor in Rust using the servo model, but have it continue to generate frames in the Gecko C++ format. This would give us rayon-driven parallelism in frame construction (which is a big performance bottleneck), while being a lot more tractable than swapping out all of layout at once. Another thing to explore would be borrowing Servo's tech for certain subtypes of layout (i.e. block reflow) and shipping it incrementally.

Each of these may or may not share code with Servo proper, depending on the tradeoffs. But Servo has a lot of neat innovation in that part of the pipeline (like bottom-up frame construction and parallel reflow) that I'm very interested in integrating into Firefox somehow.

We're going to meet in Austin in a few weeks and discuss this. Stay tuned!