At 00:42 in the early morning of November 16, I received an email saying that “someone” logged into my twitter account @bagder from a new device. The email said it was done from Stockholm, Sweden and it was “Chrome on Windows”. (I live Stockholm)

I didn’t do it. I don’t normally use Windows and I typically don’t run Chrome. I didn’t react immediately on the email however, as I was debugging curl code at the moment it arrived. Just a few moments later I was forcibly logged out from my twitter sessions (using tweetdeck in my Firefox on Linux and on my phone).

Whoa! What was that? I tried to login again in the browser tab, but Twitter claimed my password was invalid. Huh? Did I perhaps have the wrong password? I selected “restore my password” and then learned that Twitter doesn’t even know about my email anymore (in spite of having emailed me on it just minutes ago).

We have enabled Warp, a significant update to SpiderMonkey, by default in Firefox 83. SpiderMonkey is the JavaScript engine used in the Firefox web browser.

With Warp (also called WarpBuilder) we’re making big changes to our JIT (just-in-time) compilers, resulting in improved responsiveness, faster page loads and better memory usage. The new architecture is also more maintainable and unlocks additional SpiderMonkey improvements.

This post explains how Warp works and how it made SpiderMonkey faster.

Also: SpiderMonkey's Warp Upgrade Is Ready For Firefox 83 - Phoronix

• SpiderMonkey Newsletter 7 (Firefox 82-83) | spidermonkey.dev [Ed: Mozilla blogging on Microsoft servers]

  SpiderMonkey is the JavaScript engine used in Mozilla Firefox. This newsletter gives an overview of the JavaScript and WebAssembly work we’ve done as part of the Firefox 82 and 83 Nightly release cycles.

• iodide retrospective [Ed: Mozilla blogging on Microsoft servers and talking about spying on Firefox users]

  A bit belatedly, I thought I’d write a bit about Iodide: an effort to create a compelling, client-centred scientific notebook environment.

  Despite not writing a ton about it (the sole exception being this brief essay about my conservative choice for the server backend) Iodide took up a very large chunk of my mental energy from late 2018 through 2019. It was also essentially my only attempt at working on something that was on its way to being an actual product while at Mozilla: while I’ve led other projects that have been interesting and/or impactful in my 9 odd-years here (mozregression and perfherder being the biggest successes), they fall firmly into the “internal tools supporting another product” category.

  At this point it’s probably safe to say that most of the project has wound down: no one is being paid to work on Iodide and it’s essentially in extreme maintenance mode. Before it’s put to bed altogether, I’d like to write a few notes about its approach, where I think it had big advantanges, and where it seems to fall short. I’ll conclude with some areas I’d like to explore (or would like to see others explore!). I’d like to emphasize that this is my opinion only: the rest of the Iodide core team no doubt have their own thoughts. That said, let’s jump in.

  [...]

  It describes how people typically perform computational inquiry: typically you would poke around with some raw data, run some transformations on it. Only after that process was complete would you start trying to build up a “presentation” of your results to your audience.

  Looking back, it’s clear that Iodide’s strong suit was the explanation part of this workflow, rather than collaboration and exploration. My strong suspicion is that we actually want to use different tools for each one of these tasks. Coincidentally, this also maps to the bulk of my experience working with data at Mozilla, using iodide or not: my most successful front-end data visualization projects were typically the distilled result of a very large number of adhoc explorations (python scripts, SQL queries, Jupyter notebooks, …). The actual visualization itself contains very little computational meat: basically “just enough” to let the user engage with the data fruitfully.

  Unfortunately much of my work in this area uses semi-sensitive internal Mozilla data so can’t be publicly shared, but here’s one example

• New Release: Tor Browser 10.0.4 [Ed: Firefox inside]

  Tor Browser 10.0.4 is now available from the Tor Browser download page and also from our distribution directory.

  This release updates NoScript to 11.1.5 and includes an important security update to Firefox.

• You’re Invited: State of the Onion 2020

  Every year people from the Tor Project communities present the State of the Onion, a compilation of updates from our different projects, at conferences around the world. We use this opportunity to talk about highlights of the work we’ve accomplished during the year and what we are excited about in the upcoming year.

  With COVID-19 pandemic this year, we didn’t have the chance to ‘tour’ our State of the Onion during any face-to-face conferences. So we decided to bring the State of the Onion to you in a special livestream on November 16 from 16:00 - 18:00 UTC.*

• Mozilla's DeepSpeech 0.9 Released For Open-Source Speech To Text Engine - Phoronix

  Following this summer's big round of layoffs at Mozilla, the organization's deep learning open-source speech-to-text engine has been among the projects considered at risk. Fortunately, at least for now, DeepSpeech is still moving forward and is up to version 0.9.

  After the summer's layoffs at Mozilla, the future of DeepSpeech has been in question even as the project has been nearing its 1.0 stable release. While back in August they said DeepSpeech 1.0 would be released "soon", that hasn't happened yet but today marks version 0.9.

• This week in Glean: Glean.js

  In a previous TWiG blog post, I talked about my experiment on trying to compile glean-core to Wasm. The motivation for that experiment was the then upcoming Glean.js workweek, where some of us were going to take a pass at building a proof-of-concept implementation of Glean in Javascript.

  [...]

  The reason for our initial focus on webextensions is that the Ion project has volunteered to be Glean.js’ first consumer. Support for static websites and Qt/QML apps will follow. Other consumers such as Node.js servers and CLIs are not part of the initial roadmap.

  Although we learned a lot by building the POC, we were probably left with more open questions than answered ones. The Javascript environment is a very special one and when we set out to build something that can work virtually anywhere that runs Javascript, we were embarking on an adventure.

  Each Javascript environment has different resources the developer can interact with. Let’s think, for example, about persistence solutions: on web browsers we can use localStorage or IndexedDB, but on Node.js servers / CLIs we would need to go another way completely and use Level DB or some other external library. What is the best way to deal with this and what exactly are the differences between environments?

• New Release: Tor Browser 10.0.3 (Android Only)

  After many months of design and development we are very happy to announce the release of Tor Browser 10.0.3 for Android. This is the first Android Tor Browser version in the stable 10.0 series. The Desktop version was released at the end of September. We began working on this project in April 2020 with the goal of rebuilding the Android Tor Browser on top of Mozilla's new Android Firefox Browser, Fenix. Over the last six months, we successfully achieved this goal and we reached feature parity with the previous Android Tor Browser version.