Ronaldo Lemos joined the Mozilla Foundation board almost six years ago. Today he is stepping down in order to turn his attention to the growing Agora! social movement in Brazil.
Over the past six years, Ronaldo has helped Mozilla and our allies advance the cause of a healthy internet in countless ways. Ronaldo played a particularly important role on policy issues including the approval of the Marco Civil in Brazil and shaping debates around net neutrality and data protection. More broadly, he brought his experience as an academic, lawyer and active commentator in the fields of intellectual property, technology and culture to Mozilla at a time when we needed to step up on these topics in an opinionated way.
As a board member, Ronaldo also played a critical role in the development of Mozilla Foundation’s movement building strategy. As the Foundation evolved it’s programs over the past few years, he brought to bear extensive experience with social movements in general — and with the open internet movement in particular. This was an invaluable contribution.
Ronaldo is the Director of the Institute for Technology & Society of Rio de Janeiro (ITSrio.org), Professor at the Rio de Janeiro State University’s Law School and Partner with the law firm Pereira Neto Macedo.
He recently co-founded a political and social movement in Brazil called Agora!. Agora! is a platform for leaders engaged in the discussion, formulation and implementation of public policies in Brazil. It is an independent, plural and non-profit movement that believes in a more humane, simple and sustainable Brazil — in an efficient and connected state, which reduces inequalities and guarantees the well-being of all citizens.
Ronaldo remains a close friend of Mozilla, and we’ll no doubt find ample opportunity to work together with him, ITS and Algora! in the future. Please join me in thanking Ronaldo for his tenure as a board member, and wishing him tremendous success in his new endeavors.
Mozilla is now seeking talented new board members to fill Ronaldo’s seat. More information can be found here: https://mzl.la/MoFoBoardJD
The post Thank You, Ronaldo Lemos appeared first on The Mozilla Blog.
https://blog.mozilla.org/blog/2020/02/18/thank-you-ronaldo-lemos/
I’m exactly one microphone and one ridiculous haircut away from turning into Management Shingy when I get rolling on stuff like this, because it’s just so clear to me how much this stuff matters and how little sense I might be making at the same time. Is your issue tracker automatically flagging your structural blind spots? Do your QA and UX team run your next reorg? Why not?
This all started life as a rant on Mastodon, so bear with me here. There are two empirically-established facts that organizations making software need to internalize.
The first is that by wide margin the most significant predictive indicator that there will be a future bug in a piece of software is the relative orgchart distance of the people working on it. People who are working on a shared codebase in the same room but report to different VPs are wildly more likely to introduce errors into a codebase than two people who are on opposite sides of the planet and speak different first languages but report to the same manager.
The second is that the number one predictor that a bug will be resolved is if it is triaged correctly – filed in the right issue tracker, against the right component, assigned to the right people – on the first try.
It’s fascinating that neither of the strongest predictive indicators of the most important parts of a bug’s lifecycle – birth and death – actually take place on the developers’ desk, but it’s true. In terms of predictive power, nothing else in the software lifecycle comes close.
Taken together, these facts give you a tools to roughly predict the effectiveness of collaborating teams, and by analyzing trends among bugs that are frequently re-assigned or re-triaged, can give you a lot of foresight into how, where and why a company need to retrain or reorganize those teams. You might have read Agile As Trauma recently, in which Dorian Taylor describes agile development as an allergic reaction to previously bad management:
The Agile Manifesto is an immune response on the part of programmers to bad management. The document is an expression of trauma, and its intellectual descendants continue to carry this baggage. While the Agile era has brought about remarkable advancements in project management techniques and development tools, it remains a tactical, technical, and ultimately reactionary movement.
This description is strikingly similar to – and in obvious tension with – Clay Shirky’s description of bureaucracy as the extractive mechanism of complexity and an allergic reaction to previous institutional screwups.
Bureaucracies temporarily suspend the Second Law of Thermodynamics. In a bureaucracy, it’s easier to make a process more complex than to make it simpler, and easier to create a new burden than kill an old one.
… which sounds an awful lot like the orgchart version of “It’s harder to read code than to write it”, doesn’t it?
I believe both positions are correct. But that tension scribes the way forward, I think, for an institutional philosophy that is responsive, flexible and empirically grounded, in which being deliberate about the scale, time, and importance of different feedback cycles gives an organization the freedom to treat scaling like a tool, that the signals of different contexts can inform change as a continuum between the macro and micro levels of organizational structure and practice. Wow, that’s a lot of words in a strange order, but hear me out.
It’s not about agile, or even agility. Agility is just the innermost loops, the smallest manifestation of a wide possible set of tightly-coupled feedback mechanisms. And outside the agile team, adjacent to the team, those feedback loops may or may not exist however much they need to, up and down the orgchart (though there’s not often much “down” left in the orgchart, I’ve noticed, where most agile teams live…) but more importantly with the adjacent and complementary functions that agile teams rely on.
It is self-evident that how teams are managed profoundly affects how they deliver software. But agile development (and every other modern developer-cult I’m aware of) doesn’t close that loop, and in failing to do so agile teams are reduced to justifying their continued
For the past little while, we have been tracking some interesting WebRender bugs that people are reporting in release. Despite best efforts, we have been unable to determine clear steps to reproduce these issues and have been unable to find a fix for them. Today we are announcing a special challenge to the community – help us track down steps to reproduce (a.k.a STR) for this bug and you will win some special, limited edition Firefox Graphics team swag! Read on for more details if you are interested in participating.
Late last year we started seeing reports of random UI glitching bugs that people were seeing in release. You can check out some of the reports on Bugzilla. Here is what we know so far about this bug:


Without having a way to reliably reproduce this bug, we are at a loss on how to solve it. So we decided to hold a challenge to engage the community further to help us understand this bug better. If you are interested in helping us get to the root of this tricky bug, please do the following:
Even if you can’t easily find STR, we are still interested in hearing about whether you see this bug!
The winners of this challenge will be chosen based on the following criteria:
There has been a surprising development after my previous article on the topic, Avast having announced that they will terminate Jumpshot and stop selling users’ data. That’s not the end of the story however, with the Czech Office for Personal Data Protection starting an investigation into Avast’s practices. I’m very curious to see whether this investigation will confirm Avast’s claims that they were always fully compliant with the GDPR requirements. For my part, I now got a glimpse of what the Jumpshot data actually looks like. And I learned that I massively overestimated Avast’s success when anonymizing this data.

In reality, the data sold by Jumpshot contained plenty of user identifiers, names, email addresses, even home addresses. That’s partly due to Avast being incapable or unwilling to remove user-specific data as they planned to. Many issues are generic however and almost impossible to avoid. This once again underlines the central takeaway: anonymizing browser history data is very hard. That’s especially the case if you plan to sell it to advertisers. You can make data completely anonymous, but you will have to dumb it down so much in the process that advertisers won’t have any use for it any more.
Why did I decide to document Avast’s failure in so much detail? My goal is to spread appreciation for the task of data anonymization: it’s very hard to ensure that no conclusions about users’ identity are possible. So maybe whoever is toying with the idea of collecting anonymized data will better think twice whether they really want do go there. And maybe next time we see a vendor collecting data we’ll ask the right questions about how they ensure it’s a “completely anonymous” process.
The data I saw was an example that Jumpshot provided to potential customers: an excerpt of real data for one week of 2019. Each record included an exact timestamp (milliseconds precision), a persistent user identifier, the platform used (desktop or mobile, which browser), the approximate geographic location (country, city and ZIP code derived from the user’s IP address), a guess for user’s gender and age group.
What it didn’t contain was “every click, on every site.” This data sample didn’t belong to the “All Clicks Feed” which has received much media attention. Instead, it was the “Limited Insights Pro Feed” which is supposed to merely cover user’s shopping behavior: which products they looked at, what they added to the cart and whether they completed the order. All of that limited to shopping sites and grouped by country (Germany, UK and USA) as well as product category such as Shoes or Men’s Clothing.
This doesn’t sound like there would be all too much personal data? But there is, thanks to a “referrer” field being there. This one is supposed to indicate how the user came to the shopping site, e.g. from a Google search page or by clicking an ad on another website. Given the detailed information collected by Avast, determining this
14 Reps were invited to participate in this year’s All Hands in Berlin.
At the All-Hands Reps learned some easy German words (Innovationsprozess-swischenstands-schreihungsskizze), did some art (see here X artistic endeavor during a group activity), and learned about cultural differences in communication.
Of course, it was not all going around, spray painting walls, and trying to understand the German sense of humor. The reps went down to serious Reps business.
To be sure that issues that were relevant to the Reps would be discussed in Berlin, all the invited Reps were asked to fill out a survey. The answers from the survey revealed a series of community issues that limit participation, as well as issues with the infrastructures of the Reps program. Putting together these answers with the themes that the Reps council worked on their OKRs last year, these issues were prioritized for discussion:
So, to discuss how to tackle these issues and how to bring forward the program in 2020 the reps had meetings (lots and lots of meetings).
On Tuesday Reps were divided into small groups to discuss the above-mentioned issues. In every group, they were asked to discuss the current state and to imagine the ideal state for each issue by the end of 2020.
On Wednesday Reps were asked, “are we community coordinators yet?”. We agreed to prioritize the themes we discussed on Tuesday based on the above question and thinking around which one of them can strengthen their role as a community coordinator and, therefore, help to grow healthy communities.
Based on that prioritization two themes emerged as the leading themes for 2020: communication between Mozilla and the reps program and campaign and activities. That, of course, doesn’t mean that the rest of the themes are not equally important. The Reps Council decided to put the focus on the first two while at the same time open the participation for the other themes amongst the Reps.
On Wednesday the Reps Council met to discuss how to turn the 2 major topics into objectives and key results of the program in 2020. This conversation is still going and the Reps Council will publish this year’s OKRs soon.
On Thursday all reps discussed the campaigns pipeline and how volunteers can contribute more actively to it.
So, what was the conclusion from this tour-de-force?
Communications:
Regarding communication, the reps established that there was a need for more consistent communication and transparency. So that they set this goal to be reached by the end of 2020:
More in detail this would mean, between other things, that there will be a clear channel of communication for Mozilla to reach reps, consistent communication around Mozilla’s top goals, and the capability to update communities in their own languages. This will require establishing resources dedicated to improving communication.
Activities:
Reps established that there is a need to have more activities and campaigns in which communities can participate and that these campaigns need to be all in one place (the community portal). The objective is that:
Reps will also become more active in all the stages of a campaign pipeline, from the ideation to the implementation phase. To this end, communication and information between reps and projects/staff should become simpler.
Let us know what you think in the
(older options of the week)
--mail-from has no short version. This option was added to curl 7.20.0 in February 2010.
I know this surprises many curl users: yes curl can both send and receive emails.
curl can do “uploads” to an SMTP server, which usually has the effect that an email is delivered to somewhere onward from that server. Ie, curl can send an email.
When communicating with an SMTP server to send an email, curl needs to provide a certain data set and one of the mandatory fields of data that is necessary to provide is the email of the sender.
It should be noted that this is not necessary the same email as the one that is displayed in the From: field that the recipient’s email client will show. But it can be the same.
curl --mail-from from@example.com --mail-rcpt to@example.com smtp://mail.example.com -T body.txt
You can use curl to receive emails over POP3 or IMAP. SMTP is only for delivering email.
--mail-rcpt for the recipient(s), and --mail-auth for the authentication address.
Corporate data breaches are an all too common reality of modern life. At best, you get an email from a company alerting you that they have been hacked, and then … Read more
The post Resolve data breaches with Firefox Monitor appeared first on The Firefox Frontier.
About 4 years and 2 months ago, Dave Townsend and I landed a couple of patches on the Mozilla codebase that kick-started rolling out ESLint across our source code. Today, I’ve just landed the last bug in making it so that ESLint runs across our whole tree (where possible).
ESLint is a static analyser for JavaScript that helps find issues before you even run the code. It also helps to promote best practices and styling, reducing the need for comments in reviews.
Several Mozilla projects had started using ESLint in early 2015 – Firefox’s Developer Tools, Firefox for Android and Firefox Hello. It was clear to the Firefox desktop team that ESLint was useful and so we put together an initial set of rules covering the main desktop files.
Soon after, we were enabling ESLint over more of desktop’s files, and adding to the rules that we had enabled. Once we had the main directories covered, we slowly started enabling more directories and started running ESLint checks in CI allowing us to detect and back out any failures that were introduced. Finally, we made it to where we are today – covering the whole of the Firefox source tree, mozilla-central.
Along the way we’ve filed over 600 bugs for handling ESLint roll-out and related issues, many of these were promoted as mentored bugs and fixed by new and existing contributors – a big thank you to you all for your help.
We’ve also found and fixed many bugs as we’ve gone along. From small bugs in rarely used code, to finding issues in test suites where entire sections weren’t being run. With ESLint now enabled, it helps protect us against mistakes that can easily be detected but may be hard for humans to spot, and reduces the work required by both developer and reviewer during the code-review-fix cycle.
Although ESLint is now running on all the files we can, there’s still more to do. In a few places, we skipped enabling rules because it was easier to get ESLint just running and we also wanted to do some formatting on them. Our next steps will be to get more of those enabled, so expect some more mentored bugs coming soon.
Thank you again to all those involved with helping to roll out ESLint across the Firefox code-base, this has helped tremendously to make Firefox’s and Gecko’s source code to be more consistently formatted and contain less dead code and bugs. ESLint has also been extremely helpful in helping switch away from older coding patterns and reduce the use of risky behaviour during tests.
From the abacus to the iPad, computers have been a part of the human experience for longer than we think. So much so that we forget the vast amounts of … Read more
The post Data detox: Four things you can do today to protect your computer appeared first on The Firefox Frontier.
Another pointless number that happens to be round and look nice so I feel a need to highlight it.
When curl was born WiFi didn’t exist yet. Smartphones and tablets weren’t invented. Other things that didn’t exist include YouTube, Facebook, Twitter, Instagram, Firefox, Chrome, Spotify, Google search, Wikipedia, Windows 98 or emojis.
curl was born in a different time, but also in the beginning of the explosion of the web and Internet Protocols. Just before the big growth wave.
In 1996 when I started working on the precursor to curl, there were around 250,000 web sites (sources vary slightly)..
In 1998 when curl shipped, the number of sites were already around 2,400,000. Ten times larger amount in just those two years.
In early 2020, the amount of web sites are around 1,700,000,000 to 2,000,000,000 (depending on who provides the stats). The number of web sites has thus grown at least 70,000% over curl’s 8000 days of life and perhaps as much as 8000 times the amount as when I first working with HTTP clients.
One of the oldest still available snapshots of the curl web site is from the end of 1998, when curl was just a little over 6 months old. On that page we can read the following:

That “massive popularity” looks charming and possibly a bit naive today. The number of monthly curl downloads have also possibly grown by 8,000 times or so – by estimates only, as most users download curl from other places than our web site these days. Even more users get it installed as part of their OS or bundled with something else.
Thank you for flying curl.
(This day occurs only a little over a month before curl turns 22, there will be much more navel-gazing then, I promise.)
Image by Annie Spratt from Pixabay
https://daniel.haxx.se/blog/2020/02/13/curl-is-8000-days-old/
We’re not sure if we can consider “You” a guilty pleasure considering how many people have binged every episode (over 43 million), but it certainly ranks up there right next … Read more
The post What watching “You” on Netflix taught us about privacy appeared first on The Firefox Frontier.
I came back yesterday at home from Berlin All Hands at noon. Today will be probably tough on jetlag. Almost all Japanese from Narita Airport to home were wearing a mask (as I did). The coronavirus is in the mind: "deaths at 361 and confirmed infections in China at 17,238".
Cleaning up emails. And let's restart coding for issue #3140 (PR #3167). Last week, I discussed with mike, if I should rebase the messy commits so we have a cleaner version. On one hand, the rebase would create a clean history with commits by specific sections, but the history of my commits also document the thought process. For now I think I will keep the "messy informative" commits.
When unit tests are not failing locally but failing on CircleCI, it smells a dependency on the environment. Indeed, here the list of labels returned behaved differently on CircleCI because locally, in my dev environment, I had a populated data/topsites.db. This issue would not have been detected if my local topsites.db was empty like on circleCI. A unittest which depends on an external variability is bad. For now I decided to mock the priority in the test and I opened an issue to create a more controlled environment.
Finishing the big pull request for the new workflow. I don't like usually to create huge pull request. I prefer a series of smaller ones, tied to specific issues. The circumstances pushed me to do that. But I think it's an interesting lesson. How much do we bend our guidelines and process rules in an emergency situation.
23:00 to midnight, we had a webcompat team video-meeting.
Code review today for kate's code on fetching the labels for the repos. She used GraphQL, which is cool. Small piece of codes creates opportunities to explore new ways of doing things.
I wonder if there is a client with a pythonic api for GraphQL, the same way that SQLAlchemy does for SQL.
I need to
Big pull request… big bug. Big enough that it would create an error 500 on a certain path of the workflow. So more tests, and fixing the issue in a new pull request.
Restarting diagnosis too because the curve is going up. We are +50 above our minimum on January 2020. You can definitely help.
Such a big pull request created obviously more bugs. Anonymous reporting is activated with a flag and our flag didn't work as expected. So that was strange.
After investigating a bit, we were using an environment variable for the activation with the value True or False in
The new Firefox for Android experience is currently available for early testing on the Firefox Preview Nightly and Firefox Preview production channels.
In February 2020, we will change which Firefox applications remain available in the Play store. Once we’ve completed this transition, Firefox Preview Nightly will no longer be available. New feature development will take place on what is currently Firefox Preview.
We encourage users who are eager to make use of extensions to stay on Firefox Preview. This will ensure you continue to receive updates while still being among the first to see new developments.
Support for one extension, uBlock Origin, has been enabled for Firefox Preview Nightly. Every two weeks, the code for Firefox Preview Nightly gets migrated to the production release of Firefox Preview. Users of Firefox Preview should be able to install uBlock Origin by mid-February 2020.
We expect to start transferring the code from the production release of Firefox Preview to the Firefox for Android Beta channel during the week of February 17.
We are rolling out the new Firefox for Android experience to our users in small increments to test for bugs and other unexpected surprises. Don’t worry — you should receive an update that will enable extension support soon!
No, in the near term you will need to install extensions from the Add-ons Manager on the new Firefox for Android. For the time being, you will not be able to install extensions directly from addons.mozilla.org.
Currently, uBlock Origin is the only supported extension for the new Firefox for Android. We are working on building support for other extensions in our Recommended Extensions program.
We want to ensure that the first add-ons supported in the new Firefox for Android provide an exceptional, secure mobile experience to our users. To this end, we are prioritizing Recommended Extensions that cover common mobile use cases and that are optimized for different screen sizes. For these reasons, it’s possible that not all the add-ons you have previously installed in Firefox for Android will be supported in the near future.
We would like to expand our support to other add-ons. At this time, we don’t have details on enabling support for extensions not part of the Recommended Extensions program in the new Firefox for Android. Please follow the Add-ons Blog for future updates.
GeckoView is Mozilla’s mobile browser engine. It takes Gecko, the engine that powers the desktop version of Firefox, and packages it as a reusable Android library. Rebuilding our Firefox for Android browser with GeckoView means we can leverage our Firefox expertise in creating safe and robust online experiences for mobile.
Support for uBlock Origin will be migrated for users currently on Firefox Nightly, Firefox Beta, and Firefox Production. All other add-ons will be disabled for now.
The post FAQ for extension support in new Firefox for Android appeared first on Mozilla Add-ons Blog.
Another month, another new browser release! Today we’ve released Firefox 73, with useful additions that include CSS and JavaScript updates, and numerous DevTools improvements.
Read on for the highlights. To find the full list of additions, check out the following links:
Note: Until recently, this post mentioned the new form method requestSubmit() being enabled in Firefox 73. It has come to light that requestSubmit() is in fact currently behind a flag, and targetted for a release in Firefox 75. Apologies for the error. (Updated Friday, 14 February.)
Our latest Firefox offers a fair share of new web platform additions; let’s review the highlights now.
We’ve added to CSS logical properties, with overscroll-behavior-block and overscroll-behavior-inline.
These new properties provide a logical alternative to overscroll-behavior-x and overscroll-behavior-y, which allow you to control the browser’s behavior when the boundary of a scrolling area is reached.
The yearName and relatedYear fields are now available in the DateTimeFormat.prototype.formatToParts() method. This enables useful formatting options for CJK (Chinese, Japanese, Korean) calendars.
There are several interesting DevTools updates in this release. Upcoming features can be previewed now in Firefox DevEdition.
We continually survey DevTools users for input, often from our @FirefoxDevTools Twitter account. Many useful updates come about as a result. For example, thanks to your feedback on one of those surveys, it is now possible to copy cleaner CSS snippets out of the Inspector’s Changes panel. The + and - signs in the output are no longer part of the copied text.
The DevTools engineering work for this release focused on pushing performace forward. We made the process of collecting fast-firing requests in the Network panel a lot more lightweight, which made the UI snappier. In the same vein, large source-mapped scripts now load much, much faster in the Debugger and cause less strain on the Console as well.
Loading the right sources in the Debugger is not straightforward when the DevTools are opened on a loaded page. In fact, modern browsers are too good at purging original files when they are parsed, rendered, or executed, and no longer needed. Firefox 73 makes script loading a lot more reliable and ensures you get the right file to debug.
Console script authoring and logging gained some quality of life improvements. To date,