De Nederlandse
Mozilla-gemeenschap

Software-update: Brave 1.34.81 - Computer - Downloads  Tweakers

Goedemorgen Bitcoin: Wikipedia stopt toch niet met accepteren cryptodonaties  Bitcoin Magazine NL

Software-update: Mozilla Firefox 96.0.2 - Computer - Downloads  Tweakers

Software-update: Mozilla Firefox 96.0.1 - Computer - Downloads  Tweakers

Firefox-gebruikers melden problemen met openen websites - update  Tweakers

Why we need to revisit the origin of blue hyperlink

While musing over my recently published article, Why are hyperlinks blue, I was left feeling a bit blue myself. Yes, it could have been the fact that I was evacuated and Hurricane Ida was destroying my home, I’ll admit. Besides that, I was also bothered by the fact that even though I was able to determine that Mosaic was indeed the first browser to use blue hyperlinks, I was not much closer to determining why the hyperlinks themselves were blue. 

Black hyperlinks had been the standard for many years, but why the sudden shift to blue? One can assume that it is because RGB phosphorescent monitors were becoming more readily available in comparison to monotone phosphorescent monitors that could only produce one color. Okay then, with a palette of colors to choose from, why blue? Why not green? Microsoft 3.1 had used green for hyperlinks. Surely there must have been something to support or inspire Marc Andreessen and Eric Bina on April 12, 1993 to make the hyperlinks blue, but what was it?

I simply didn’t know, so I published the article anyway and hoped the internet would do as it always does: thrill in pointing out when someone is wrong, in the hope that someone would know the true answer. 

I published the first article, a hurricane destroyed my home, and now two months later I’m once again sitting in my now gutted home with the miracle of the internet once again restored, and I’m back on the case.

Sifting for the golden nugget

I found myself enjoying my morning coffee, reading through hate mail from my first article, as one does. I sifted through this dung heap as a prospector pans for gold, scanning for the faintest hint of gold to help me continue my journey to the true origin of the blue hyperlink.

Don Hopkins, or a commenter who goes by the same name, knew the answer, and pointed me towards Ben Shneiderman. In short, it is Prof. Ben Shneiderman whom we can thank for the modern blue hyperlink. At the time, however, I didn’t yet know this. I found the professor online, and contacted him, and went about my day. He so kindly reached out to me, and as he spoke, it was an epiphany – all of these disassociated pieces of applications, history and anecdotes suddenly fit together like a marvelous great puzzle. 

Below is the timeline based on our conversation, the documentation Prof. Shneiderman provided to me, and the information I had already gathered in my previous research. I hope that this all together can help prove a direct link between the work Ben Shneiderman and his graduate students were doing at the University of Maryland in the mid to late 1980s and the blue hyperlink found in Mosaic in 1993.

I’m a cyan fan

1985 – University of Maryland: Human-Computer Interaction Lab

Ben Shneiderman developed the highlighted selectable light blue link, which was implemented by graduate student Dan Ostroff. In doing so, they, as well as other students, tested many versions in controlled experiments. 

“Red highlighting made the links more visible, but reduced the user’s capacity to read and retain the content of the text… blue was visible, on both white and black backgrounds and didn’t interfere with retention,” Shneiderman shared with me.

1982 – HyperTIES

Created in 1982, HyperTIES was an early hypertext authoring system, made commercial available by Cognetics Corporation. After research concluded at the University of Maryland, blue links were then built into HyperTIES. This is the first instance of a blue hyperlink. 

April 1986 – Communications of the ACM

Koved and Shneiderman published their research in Communications of the ACM, an industry magazine. 

Koved, L., & Shneiderman, B. (1986). Embedded menus: Selecting items in context. Communications of the ACM, 29(4), 312-318.

November 13-15, 1987 – The Hypertext Conference, Chapel Hill, North Carolina

At the first Hypertext conference, Ben Shniderman presented in a panel session, “User interface design for the Hyperties electronic encyclopedia.” Of the conference, Professor Shniderman wrote:

“We conducted approximately 20 empirical studies of many design variables which         were reported at the Hypertext 1987 conference and in array of journals and books. Issues such as the use of light blue highlighting as the default color for links, the inclusion of a history stack, easy access to a BACK button, article length, and global string search were all studied empirically.” 

July 1988 – Communications of the ACM

Ben Shneiderman’s team took on the project of producting a HyperTIES disk for the ACM called “Hypertext on Hypertext”, which contained the full text of eight papers. These papers were published in the July 1988 issue of Communications of the ACM.

The leap to Lee

In 1989, Tim Berners-Lee wrote Information Management: A Proposal, in which he discussed many topics. Of interest to the blue hyperlink, he does discuss the work being done at universities centered around human interface design, and a nod to commercial success of a product using hypertext: 

“An increasing amount of work is being done into hypermedia research at universities and commercial research labs, and some commercial systems have resulted. There have been two conferences, Hypertext ’87 and ’88, and in Washington DC, the National Institute of Standards and Technology (NST) hosted a workshop on standardisation in hypertext, a followup of which will occur during 1990.

The Communications of the ACM special issue on Hypertext contains many references to hypertext papers. A bibliography on hypertext is given in [NIST90], and a uucp newsgroup alt.hypertext exists. I do not, therefore, give a list here.

Much of the academic research is into the human interface side of browsing through a complex information space. Problems addressed are those of making navigation easy, and avoiding a feeling of being “lost in hyperspace”. Whilst the results of the research are interesting, many users at CERN will be accessing the system using primitive terminals, and so advanced window styles are not so important for us now.”

While still an assumption, it is a fair assumption that Tim Berners-Lee was aware of the blue highlight hyperlink color because he was aware of “research at universities”, “Hypertext ‘87”, and the “ACM special issue on Hypertext,” all instances where the blue highlight color research was presented. Berners-Lee did mention that the “results of the research are interesting.” It is also interesting to note that WWW, the browser he was creating at the time, did not use blue hyperlinks. 

January 16-18, 1990 – Hypertext Standardization Workshop 

Tim Berners-Lee, as well as many others, participated in the hypertext standardization workshop, yet there was no mention of the use of color to denote hypertext in the report. However, readability of hypertext was identified as a research objective in the workshop report (PDF).

“​​Measuring hypertext “readability.” … Hypertext extensions to readability metrics might include measures of the “goodness” of links based on similarity between linked units. Readability measures for alternative hypertext designs for the same text will go far toward making hypertext design an engineering discipline.” (Page 35)

August 1990 – Dynamic Characteristics of Hypertext

Following up on the workshop, I assume this is the resulting paper (PDF) to come out of the hypertext standardization workshop. Published by Richard Furuta & P. David Stotts, this paper argues that dynamic characteristics of hypertext are required to achieve hypertext’s true purpose. In the excerpt below we can see the authors discuss color’s role in hypertex, and the foundations of active, visited and focused states:

“Dynamic representation of context may also be useful. For example, consider the representation of an anchor that changes over time. The anchor may be represented by a highlighted region whose color, size, or location changes over time to draw more attention to itself. Alternatively, the anchor might be represented by a small animation.” – Page 2

Blue’s clues

In the late 1980s, industry workshops and conferences brought people together to share ideas, discuss trends and standardize ways of making the web work. What are the results of this sharing of knowledge? Well, hypertext starts to turn blue. At the time, hypertext was more than what we now know as hyperlinks, but also included user interface elements such as the close icon, navigating back and forth between sections, and printing. As we see above, there were arguments from industry leaders to make hypertext dynamic, so active states must be included as well. 

October 21, 1991 – Macintosh System 7

Apple began adding hints of blue to icons and text background when selected. 

April 6, 1992 – Windows 3.1

Microsoft began using blue for interactions to “highlight” text when selected.

1992 – HyperTIES

Created for the HP LaserJet4 User Manual, even using HyperTies creators began using the darker blue hyperlink on a button as well as the light blue (cyan) for hyperlinks.

December 1992 – Framaker 3.0 (Windows Version)

Framemaker was created for making and maintaining large documents, and is also the first instance I uncovered of the dark blue hyperlink. In 1992, not all versions were in color, but Framemaker v3.0 for Windows did support color monitors. Huge shoutout to Dan Connolly for letting me know about this application, and to a colleague of mine for opening it in an emulator to get this screenshot.

On Wednesdays we wear blue

So what inspired the blue links in Mosaic; whose blue hyperlinks went on to set the industry standard we are following even today? Well, we do know that Marc Andreessen and Eric Bina were inspired by ViolaWWW and decided to create Mosaic after seeing it. Perhaps they were aware of the same inspirations and research as Tim Berners-Lee, or they simply saw the blue trend happening in their industry.

In truth, it doesn’t matter what specific application or article inspired them. The decision to make hyperlinks blue in Mosaic, and the reason why we see it happening in Cello at the same time, is that by 1993, blue was becoming the industry standard for interaction for hypertext. It had been eight years since the initial research on blue as a hyperlink color. This data had been shared, presented at conferences, and printed in industry magazines. Hypertext went on to be discussed in multiple forums. Diverse teams’ research came to the same conclusion – color mattered. If it didn’t inspire Marc Andreessen and Eric Bina directly, it inspired those around them and those in their industry. We can see evidence of this inspiration by looking at the work of Macintosh, Microsoft, HyperTIES, LaserJet, Framemaker and Cello. These companies and products created work before or during Mosaic, and all use blue hyperlinks, selection colors or blue typography. Though this was still a time of experimentation, the visual language of blue for interaction was beginning to be defined years before Mosaic was created. 

I love knowing that the original blue was chosen with care and through testing, that this research and knowledge was shared through a community, and that the spirit of open source sharing still lives on here at Mozilla. I am very thankful to the developer community for their comments which led me to the right people so that I could find the answer to this question which has long plagued my mind and the minds of countless others. I hope that we continue to choose to use the internet as a place for good and communication, and that we use blue hyperlinks to connect with and help one another. 

After Publication

Updated January 12, 2022

After publishing the article, Ben Shneiderman and I continued to connect, in which he informed me that Lee and himself were colleagues who connected several times.

Shneiderman informed me that Lee had cited his work from the ACM for the Macintosh or PC, and that Lee had used the idea of light blue links from Shneiderman’s work. From this we can infer that the blue hyperlink was indeed inspired by the research done at the University of Maryland.

Also, from the comments on my first article, Why Hyperlinks are Blue, the user SeanLuke found bug fixes for WorldWildWeb on the NeXT that hinted at color support as early as 1991.

Get Firefox Get the browser that protects what’s important

The post Revisiting why hyperlinks are blue appeared first on The Mozilla Blog.

Mozilla voorziet Firefox Focus van Total Cookie Protection  Security.nl

Have you ever signed up for a contest to win a big screen TV or a vacation to an exotic location? Or have you joined a big retailer loyalty program so you can save money? If you answered yes to either of these questions you may be exchanging your name, home address, email address, phone number and sometimes even your birthdate to companies who are building your profile with the information you freely provide. Companies use those profiles to help them make ads that are targeted at convincing you to purchase, like resurfacing an item you were shopping for. When you go online, there are similar tactics that work behind the scenes to gather information about you and your browsing behavior, and track you when you go from site to site.

Mozilla has been leading the industry in privacy protections by putting our users first. Last year, we introduced one of our strongest privacy protections to date, Total Cookie Protection, to combat cross-site tracking, and we’re bringing it to Firefox Focus on Android, our simple, privacy by default companion app. Firefox Focus on Android will be the first Firefox mobile browser to have Total Cookie Protection. This will help mitigate the cross-site tracking where companies collect information about you like the sites you visit every day or the products you are searching for. 

Total Cookie Protection works by maintaining a separate “cookie jar” for each website you visit

What is Total Cookie Protection 

Total Cookie Protection stops cookies from tracking you around the web. Total Cookie Protection joins our suite of privacy protections called ETP (Enhanced Tracking Protection). In combining Total Cookie Protection with supercookie protections, you can ease your worries about companies tracking you from site to site by using Firefox Focus on Android. Total Cookie Protection works by maintaining a separate “cookie jar” for each website you visit. Any time a website, or third-party content embedded in a website, deposits a cookie in your browser, Firefox Focus confines that cookie to the cookie jar assigned to that website. This way, no other websites can reach into the cookie jars that don’t belong to them and find out what the other websites’ cookies know about you. Now, you can say good-bye to those annoying ads following you and reduce the amount of information that companies gather about you whenever you go online.

Plus, we added SmartBlock to keep websites working 

In December, we also added SmartBlock and other fixes which help keep websites running smoothly. These features work around breakage with websites, while those sites investigate proper fixes. SmartBlock helps fix issues related to Total Cookie Protection and other pro-privacy measures.

For instance, some websites contain maps hosted on other servers. If the expected cookies are not being sent to those servers, because Total Cookie Protection is active, then the maps will fail to appear. With a simple work-around we can allow these maps to appear, without disabling any pro-privacy measures, while still giving sites time to come up with a proper fix.

And for users who opt into stricter tracking protection, SmartBlock also provides replacements for commonly-blocked trackers, keeping web sites working. These replacements are bundled with Firefox, minimizing the risk of any tracking taking place. 

Get the fast, private browser, Firefox Focus today.

For more on Firefox:

Introducing Firefox Relay Premium, allowing more aliases to protect your identity from spammers

Firefox’s Private Browsing mode upleveled for you

Do you need a VPN at home? Here are 5 reasons you might.

The post New Year, New Privacy Protection for Firefox Focus on Android appeared first on The Mozilla Blog.

Mozilla gebruikt Firefox-extensie voor onderzoek naar volggedrag Meta  Tweakers

Software-update: Mozilla Thunderbird 91.5.0 - Computer - Downloads  tweakers.net

Linux Mint biedt enkel nog Firefox aan na deal met Mozilla  ITdaily

Lindsey Shepard, CMO, Mozilla For most, the New Year marks a time to reflect, reset and re-prioritize. While learning a new language, creating a budget or starting up a new hobby have become staples of our New Years’ Resolutions, as our lives increasingly shift online, it’s important we also use this opportunity to reassess our digital habits. Whether you received a new device this holiday season or just want to make sure you’re protecting yourself online, there’s no better time to partake in some New Year's cyber cleaning.  To get 2022 off to a strong start, here's a helpful and easy checklist to help you tidy up your browsing, tighten your security and ensure your online health isn’t left at the wayside. Tidy your browser 

With most of us browsing the web daily, it’s inevitable that our searches begin to add up and clutter our browsing experience. To start the New Year off right, give your browser a deep clean to ensure it’s running smoothly for the months ahead so you have an organized space to access, consume and save all of the web’s great content. 

Start off by clearing your browser history, which will not only help your devices run faster but will prevent websites from tracking your information (more on that later). Consider also enabling Private Browsing, which temporarily halts data from being stored, or changing your browser to automatically delete your history when you quit the application. 

It’s also a good idea to take a look at your bookmarks and extensions. Use this opportunity to go through your bookmarks and delete pages you no longer need and consider using Firefox’s tagging feature, which allows you to categorize bookmarks with keywords to make them easily searchable. And while extensions like adblockers and translators can be enormously useful, a quick review of these tools to ensure everything is up-to-date and still helpful will go a long way in keeping your browser moving fast and uncluttered. 

Unsubscribe from junk mail

It’s easy for junk mail to pile up throughout the year — especially as more and more sites require us to share our contact details to gain access. Just as you’ve resolved to clean out your closet every January, use this opportunity to actually scrub your inbox so it is organized and manageable in the year to come. 

Many of us fall prey to handing over our personal information to e-commerce sites in return for discounts, but in the process, open our inbox to a flood of unsolicited emails. To keep scoring these deals while maintaining a clean inbox, use Firefox Relay, which provides email aliases to use in these situations while protecting your real address. 

While it may seem like a herculean task to unsubscribe from each individual sender, there are tools that can automate the process for you, like Clean Email, which provides a list of all your subscription emails and allows you to unsubscribe easily. Spam comes in many different forms, so if it’s telemarketers’ calls that are ringing your phone off the hook, try removing your information from major data brokers’ databases — such as this one — to reduce the likelihood of your number ending up in spammers’ hands.

For emails you do actually want to read, but just can’t keep up with — like content-dense newsletters or Substacks — consider using Pocket to save your must-read articles for later while giving your inbox a break. 

Get serious about privacy

The longer you’ve lived online, the bigger your digital footprint, and with that comes greater privacy concerns. Ever been served an ad that was eerily similar to something you just searched? It was likely from a company that tracks your every move online. While the world of cookies can be confusing, and sometimes it feels easier to opt-in than figure out how to opt-out, consider incorporating a few new habits into your browsing routine to protect your data in 2022. 

To increase your privacy, you can:

Use alternatives to big tech platforms like Google, Facebook and Amazon, which are known to store large amounts of user data. Instead of using Google Chrome as your browser, try a more privacy-focused option like Firefox. 

Clear your cookies, which erases all information saved in your browser and makes it harder for sites from tracking you long after you’ve visited them. 

Consider exploring a Virtual Private Network (VPN). VPNs, such as Mozilla VPN, hide your IP address, protecting your identity and location. They also encrypt the traffic between you and your VPN provider for an additional layer of privacy.

Limit how much social platforms can track your activity by unlinking your social profiles from accounts on other sites, and adding extensions like Facebook Container to your browser, which prevent platforms from tracking you across the web.

PRO TIP: Sick of having to always click, “Accept cookies”? Try choosing a browser that has strong privacy protections like Enhanced Tracking Protection and Total Cookie Protection in Firefox.

Update and strengthen your passwords

This one is so important, it deserved its own heading. Much of what we can do to protect ourselves online boils down to our passwords, which hold the key to our personal information online. While good password practices do require some discipline, it’s worth the inconvenience to keep your online life infinitely safer. Take these straightforward steps to protect yours in 2022. 

For starters, make sure you use a different password for every account, so if one site is breached, the attacker cannot access other accounts. While doing so, update your passwords to be as strong as possible — the longer and harder the phrase is to guess, the more difficult it is to steal. Try combining two or more unrelated words, adding numbers and symbols and making it longer than 8 characters. 

Beyond passwords, try to avoid using security questions whenever possible. Since they’re often based on personal information like where you grew up or what your first car was, they’re essentially additional, less secure passwords. If you don’t have that option, avoid answering them accurately and instead opt for answers that are long and random, just like your passwords. 

PRO TIP: Not sure what a good password is? Many browsers, including Firefox, have integrated Password Managers that can generate strong password options, as well as store usernames and passwords and automatically fill them in when you visit sites. 

Protect your health and new devices 

As we spend more time on our devices, especially during the pandemic and work-from-home, it can be easy to forget the toll that too much screen time takes on our physical health. 

In 2022, fight eye strain by switching your phones and computers to dark or yellow mode, which both cut screen glare to reduce visual fatigue. The blue light emitted from screens can wreak havoc on your sleep cycle, as it’s been found to suppress the body’s release of melatonin. Combat this by investing in a pair of blue light glasses, or installing a blue light extension on your browser.

More and more research has also found that too much time on social media can negatively impact your mental health. As you reset for the New Year, consider using tools to limit your time on these sites, such as Impulse Blocker, an extension that allows you to limit access to distracting sites. 

2022, here we come!

As the internet expands and becomes more ingrained in our lives, it’s crucial we take this moment to assess our digital habits and ensure we are protected online in the year to come. However, it’s important we remember why we do this — not just to defend ourselves from potential online threats to our privacy and security, but so that we can keep enjoying all the infinite goodies the web has to offer. The internet is an amazing place with so much to explore in 2022, so let’s make sure we are prepared to make the most of it!

The post Digital Checklist: How to Start 2022 Right appeared first on The Mozilla Blog.

Browser maker Mozilla today announced a partnership with The Markup, the non-profit newsroom that investigates how technology is reshaping society, on a research project to provide insights into and data about a space that’s opaque to policymakers, researchers and users themselves. By joining Mozilla and The Markup’s “Facebook Pixel Hunt” in Firefox, people can help Rally and The Markup unravel how Facebook’s tracking infrastructure massively collects data about people online – data that is used to target ads, tailor content recommendations and spread misinformation – all by simply browsing the web.

The Markup is the newest partner for Rally, the privacy-first data-sharing platform that was created by Mozilla in 2021 to take back control from platforms that are not transparent about how they use people’s data and make it very difficult for independent outside research to take place. Rally is a novel way for people to help answer systemic questions by contributing their own browsing behavior data, putting it to work as part of a collective effort to solve societal problems that start online and that we have not been able to investigate this way before. 

Using tools provided by Rally, the two organizations will research how Facebook tracks people across the web through its Facebook pixel-powered ad network and shine a light on what Facebook knows about their online life. By opting into “The Facebook Pixel Hunt” study, Rally gives Firefox users the power to help answer questions like: What kind of data does the Facebook pixel collect? Which sites share this data? What can this data reveal about people? What other ways does Facebook track people? How widespread is Facebook’s tracking network?

Mozilla is excited to partner with The Markup. Cited by legislators to combat discriminatory tenant screening and mortgage lending, The Markup’s journalism has distinguished itself with its direct impact on people’s lives. The partnership of the two organizations brings together Rally’s technical skill and The Markup’s data-driven investigative journalism, exposing the problems of informational asymmetry on the internet and shedding light on systems of online surveillance used by companies like Facebook.

“A tool like Rally can bring the full force of communities of people joining together to provide insights into one of the most opaque parts of the internet that have such a dramatic impact on our individual lives and on society. This is a rare opportunity to lift the veil over Facebook’s tracking and data collection practices outside of the Facebook platforms.”

Ted Han, Rally Product Lead at Mozilla

Facebook has repeatedly slowed down efforts to bring transparency and to help independent third parties research and understand the mechanisms at play on its platforms: it shut down CrowdTangle, blocked ProPublica’s Ad Transparency tools, modified code to prevent The Markup’s Citizen Browser from collecting user-volunteered data and canceled NYU’s AdObserver researchers’ accounts. 

“The Internet and the world cannot wait on platforms to do the right thing, especially when so much depends on it. This partnership seeks to lead the way in providing new and critical ways of illuminating the reality of the internet, led by the people who make it. This partnership comes at a time when the consequences of fragmented awareness have never been more stark.”

Ted Han, Rally Product Lead at Mozilla

“We’re thrilled to partner with Mozilla, which shares our commitment to a more transparent and trusted internet. Rally is an open invitation for the public to contribute to important research into some of today’s most pressing issues, and we’re excited to investigate wherever it leads.”

Julia Angwin, editor-in-chief and founder of The Markup

The Markup will be Rally’s first non-academic partner. Rally launched as a Firefox extension in 2021. It has supported a study in collaboration with Princeton University’s Center for Information Technology Policy about news and misinformation about politics and COVID-19 across online services, and another ongoing study with the Stanford University Graduate School of Business on news consumption and the impact of ads.

Participate in “The Facebook Pixel Hunt” Install Rally

The post Mozilla partners with The Markup to launch Rally study into Facebook’s tracking and data collection practices appeared first on The Mozilla Blog.

If you’re a fan of Firefox Relay, you may have been waiting for the day when you can add more aliases. After a long wait, you can now celebrate because we’re launching Firefox Relay Premium today.

As a refresher, Firefox Relay is a free service available at relay.firefox.com where you’ll get five email aliases to use whenever you sign-up for an online account. Today, Firefox Relay is launching as a premium subscription where you can unlock unlimited aliases and additional features.

What will users get when they subscribe to Firefox Relay Premium?

Users who subscribe to Firefox Relay Premium will be able to create an unlimited number of aliases, add a custom subdomain, reply to forwarded emails, and get Premium support. To learn more about Firefox Relay Premium, please read this blog post.

What does this mean for the SUMO community? 

As of today, we have added Firefox Relay to the list of products in SUMO. Users will be able to browse through the Knowledge Base article and submit their questions directly to our support agent. There’s no traditional AAQ for Firefox Relay Premium. You’re welcome to reply to Firefox Relay question in social media/Firefox forum if you’re confident with your answer. Otherwise, please escalate the question to the admins (see here for forum, or here for social support). As contributors, we invite you to help improve our Knowledge Base articles and localize them.

This is a monumental moment for Mozilla in our journey to add more Premium product offerings, and we’re super excited about this release. If you have any questions, please reach out to any of the admins.

 

Keep rocking the helpful web,

Kiki

As the Perf-Tools team, we are responsible for the Firefox Profiler. This newsletter gives an overview of the new features and improvements we’ve done in Q3 2021.

This is our second newsletter and you can find the first one here which was about the H1 2021. With this newsletter, we wanted to focus on only Q3, so it would be less crowded and you can see the new features and improvements easily. I hope you enjoy the work that we’ve done this quarter.

Let’s get started with the highlights.

Network marker Improvements

We had network markers for a while and we had both a network track in the timeline and a network chart in the bottom panel. It was working fine for a while but it was lacking some functionalities. Also, we had some correctness issues around the markers, like sometimes we were missing some network markers. We’ve worked on this task to improve both the Firefox Profiler analysis page and also the correctness of the values in the back-end.
Here are some of the things that we’ve done:

Highlight network markers in both the timeline and the network chart

Previously, network markers in the timeline and network chart were independent. When you interacted with one, it wasn’t changing the other one. After this work, when you hover over a network marker, the same marker in the other part will be highlighted. Here’s an example:

https://blog.mozilla.org/performance/files/2021/11/profiler-network-marker-hover.mov

 

Clicking a request in the network track selects the right line in the network chart

Previously, clicking on a network track wasn’t doing anything. With this work, if you click on a network request in the network track in the timeline, it will automatically select the network marker in the network chart. It is helpful for quickly finding the network request you are looking for.

New context menu in the network track

We have a context menu for the network chart in the bottom panel, but we didn’t have one in the timeline network tracks. We’ve added the context menu to the network tracks now and they can be used as the same. We are hoping that with this and other network track works, network track will be a lot more useful.

Display network markers in the marker chart

We’ve started to show the network markers in the marker chart as well. It could be helpful when you are also looking for other markers and want to align the network markers with them.

Support for network requests cancellations

This is one of the improvements that we made in the back-end to make the data more consistent and accurate. Firefox profiler didn’t support the network request cancellations on service workers before. Now, you can see if a network request is being canceled and when.

Profiling overhead reductions Reducing the overhead of profiling Firefox sleeping threads

Previously, we were doing some costly operations for sampling even when a thread is idle. With this work, we’ve reduced the overhead of profiling the sleeping thread dramatically. I’m not going to get into the details of this improvement since our colleague Gerald Squelart wrote a great blog post about it already. You can take a look at it here if you are curious about the optimization he came up with and the implementation details.

Reducing the overhead of Firefox Profiler recording by reducing mutex lockings

Firefox Profiler has an internal mutex inside of it. It is being used so other threads can modify the same data without any data loss or data race. But this mutex brings some overhead because when two threads need to add a marker at the same time, they both need to acquire the mutex lock. In that case, one of them had to wait for the other one. And this was bringing some overhead because of this mutex lock waiting time.
With this work, we’ve removed the need for mutexes from lots of places, including most importantly from marker recording sites.

Rust API for Firefox Profiler

Firefox Profiler has some APIs for various languages like C++, JavaScript, and Java/Kotlin inside the mozilla-central codebase. We also had some hacks around the Rust codebases, but they were added for each Rust project when they were needed and we had lots of code duplication because of it. Also, they weren’t maintained by the Firefox Profiler team and they were prone to misuse. With this work, we’ve created a canonical Rust API for the Firefox Profiler and removed all the code duplications/hacks around the codebase.

We have three main functionalities with this API:

1. Registering Rust threads:
   1. With this functionality, you can register a Rust thread, so Firefox Profiler can find it and possibly profile it. It’s good to keep in mind that only registering a thread will not make it appear in the profile data. In addition, you need to add it to the “Threads” filter in about:profiling.
      We had some hacks around the thread registration for Servo and WebRender threads, so we could profile them. But they were duplicated and were using the raw FFI bindings.
2. Adding stack frame labels:
   1. Stack frame labels are useful for annotating a part of the call stack with a category. The category will appear in the various places on the Firefox Profiler analysis page like timeline, call tree tab, flame graph tab, etc.
3. Adding profiler markers:
   1. Markers are packets of arbitrary data that are added to a profile by the Firefox code, usually to indicate something important happening at a point in time, or during an interval of time.

We also have documentation about this API in the Firefox source docs. Please take a look at it for more details and examples if you are interested. Also, we are going to be writing a blog post about this API soon. Stay tuned!

Show the eTLD+1 of Isolated Web Content Processes as their track name

The timeline of the Firefox Profiler analysis page is very crucial to finding the data we are looking for. Inside the timeline, we have various registered processes and threads that Firefox had during the profiling session. When we have lots of tracks in the timeline, it might be hard to figure out which track we are interested in.

Previously, all the web content processes had a single name called “Web Content” or “Isolated Web Content” (when Fission is enabled). This is not explicit when it comes to figuring out a specific tab. This was implemented this way before because there wasn’t a way to determine the tab URL for a specific “Web Content” process. But with Fission, we precisely know which process belongs to which eTLD+1. After this work, we’ve started to show their eTLD+1 as their track name. This way, it will be a lot easier to determine which track you are looking for.

Here’s an example of before and after:

Before

After

Linux perf importer improvements

Firefox Profiler had Linux perf support for quite some time. We have this documentation about how to profile with it and how to import it.
Our contributor, Mark Hansen, made some great improvements on the Linux perf support to make it even better. Here are the things Mark Hansen improved:

• Add support for Linux perf profiles with a header.
  • Firefox Profiler can import the profiles directly when the user records a profile with `perf script –header`. Previously it was giving an error and the header had to be removed.
• Add categories and colors to our Linux perf importer.
  • In the Firefox Profiler, we have various profiling categories for annotating different parts of the code. For example, we have JavaScript, DOM, Network, etc. For the Linux perf profiles, we didn’t have any specific categories, so all the samples were marked as “Other”. With this work, we now have two categories for kernel and non-kernel native code. Here’s a before and after:
    Also, he wrote an awesome blog post about this work. You can find it here.

Support for dhat imports

Firefox Profiler now supports imports of dhat memory profiles. “dhat” is a dynamic heap analysis tool that is a part of the valgrind tools. It’s useful for examining how programs use their heap allocations. After this work, all you need to do is to drag and drop the dhat memory profile file into the Firefox Profiler and it will automatically import everything and load it for you.

Other updates

• Localization of the Firefox Profiler
  • We’ve finished the internationalization work of the Firefox Profiler analysis page in the H1 with the help of our Outreachy intern. And we were working with the l10n team to localize the Firefox Profiler.
    In Q3, we’ve enabled 12 locales in total, and we hope to add more once the locales under development reach a certain limit! Here are the locales that we enabled so far:
    de, el, en-GB, es-CL, ia, it, nl, pt-BR, sv-SE, uk, zh-CN, zh-TW.
    If you want to help translate the Firefox Profiler to your language, you can do that by visiting our project on Pontoon.
• Compare view shows the profile names as the track names
  • Previously the compare view was only showing Profile 1 and Profile 2 as the profile names. Now, it will display the name if it’s provided in the profile link.
• Create more compact URLs for profiles with lots of tracks
  • Firefox Profiler keeps most of the data persistent in the URL, so when you share the link with someone else, they will see the same thing as you see. But that brings some challenges. Because there is a lot of data to keep track of, the URL sometimes ends up being really long. We are using bitly to shorten the URLs, so you don’t have to worry about long URLs. But when the URL is too long, bitly fails to shorten it and you are stuck with the long URL. With this work, we’ve made the URLs more compact, to ensure that we will never fail to shorten them.
• Updated “Expand all” menu item to include its shortcut key
  • We have an “Expand all” menu item in the call tree context menu. It has a shortcut key as “*” but that wasn’t really visible before. Now, we are showing the shortcut on the right side of the menu item, so you can learn it by just looking at the context menu.
    This is implemented by our contributor Duncan Bain. Thanks, Duncan!

• When a window is closed, its screenshot will stop showing up in the timeline at the point of window destruction.
  • • Our screenshots were always showing like a window is always open even though it’s being destroyed already. Now, we know when a window is being destroyed and stop showing the screenshots of that window.

Contributors in Q3 2021

Lots of awesome people contributed to our codebases both on GitHub and mozilla-central in. We are thankful to all of them! Here’s a list of people who contributed to Firefox Profiler code:

• Duncan Bain
• Florian Quèze
• Gerald Squelart
• Greg Tatum
• Julien Wajsberg
• Mark Hansen
• Markus Stange
• Michael Comell
• Nadinda Rachmat
• Nazım Can Altınova

And here’s a list of contributors who helped on the localization of Firefox Profiler:

• Brazilian Portuguese: Marcelo Ghelman
• British English: Ian Neal
• Chilean Spanish: ravmn
• Chinese: Gardenia Liu, hyperlwk, 你我皆凡人
• Dutch: Mark Heijl
• German: Michael Köhler
• Greek: Jim Spentzos
• Interlingua: Martijn Dekker, Melo46
• Italian: Francesco Lodolo
• Kabyle: Selyan Slimane Amiri, ZiriSut
• Swedish: Andreas Pettersson, Luna Jernberg, Peter Kihlstedt
• Taiwanese Chinese: Pin-guang Chen
• Ukrainian: Artem Polivanchuk, Lobodzets, Іhor Hordiichuk

Thanks a lot!

Conclusion

Thanks for reading! If you have any questions or feedback, please feel free to reach out to me on Matrix (@canova:mozilla.org). You can also reach out to our team on Firefox Profiler channel on Matrix (#profiler:mozilla.org).

If you profiled something and are puzzled with the profile you captured, we also have the Joy of Profiling (#joy-of-profiling:mozilla.org) channel where people share their profiles and get help from the people who are more familiar with the Firefox Profiler. In addition to that, we have the Joy of Profiling Open Sessions where some Firefox Profiler and Performance engineers gather together on a Zoom call to answer questions or analyze the profiles you captured. It’s usually happening every Monday, and you can follow the “Performance Office Hours” calendar to learn more about it.

During July I’ll be visiting family in Mongolia but I’ve also a few things that are very geeky that I want to do.

The first thing I want to do is plug the Ripe Atlas probes I have. It’s litle devices that look like that :

They enable anybody with a ripe atlas or ripe account to make measurements for dns queries and others. This helps making a global better internet. I have three of these probes I’d like to install. It’s good because last time I checked Mongolia didn’t have any active probe. These probes will also help Internet become better in Mongolia. I’ll need to buy some network cables before leaving because finding these in mongolia is going to be challenging. More on atlas at https://atlas.ripe.net/.

The second thing I intend to do is map Mongolia a bit better on two projects the first is related to Mozilla and maps gps coordinateswith wifi access point. Only a little part of The capital Ulaanbaatar is covered as per https://location.services.mozilla.com/map#11/47.8740/106.9485 I want this to be way more because having an open data source for this is important in the future. As mapping is my new thing I’ll probably edit Openstreetmap in order to make the urban parts of mongolia that I’ll visit way more usable on all the services that use OSM as a source of truth. There is already a project to map the capital city at http://hotosm.org/projects/mongolia_mapping_ulaanbaatar but I believe osm can server more than just 50% of mongolia’s population.

I got inspired to write this post by mu son this morning, look what he is doing at 17 months :

Last week I gave a talk at the Philly Tech Week 2015 Dev Day organized by the delightful people at technical.ly on some of the tricks/strategies we use in the Firefox OS Gaia Email app.  Note that the credit for implementing most of these techniques goes to the owner of the Email app’s front-end, James Burke.  Also, a special shout-out to Vivien for the initial DOM Worker patches for the email app.

I tried to avoid having slides that both I would be reading aloud as the audience read silently, so instead of slides to share, I have the talk script.  Well, I also have the slides here, but there’s not much to them.  The headings below are the content of the slides, except for the one time I inline some code.  Note that the live presentation must have differed slightly, because I’m sure I’m much more witty and clever in person than this script would make it seem…

Cover Slide: Who!

Hi, my name is Andrew Sutherland.  I work at Mozilla on the Firefox OS Email Application.  I’m here to share some strategies we used to make our HTML5 app Seem faster and sometimes actually Be faster.

What’s A Firefox OS (Screenshot Slide)

But first: What is a Firefox OS?  It’s a multiprocess Firefox gecko engine on an android linux kernel where all the apps including the system UI are implemented using HTML5, CSS, and JavaScript.  All the apps use some combination of standard web APIs and APIs that we hope to standardize in some form.

Here are some screenshots.  We’ve got the default home screen app, the clock app, and of course, the email app.

It’s an entirely client-side offline email application, supporting IMAP4, POP3, and ActiveSync.  The goal, like all Firefox OS apps shipped with the phone, is to give native apps on other platforms a run for their money.

And that begins with starting up fast.

Fast Startup: The Problems

But that’s frequently easier said than done.  Slow-loading websites are still very much a thing.

The good news for the email application is that a slow network isn’t one of its problems.  It’s pre-loaded on the phone.  And even if it wasn’t, because of the security implications of the TCP Web API and the difficulty of explaining this risk to users in a way they won’t just click through, any TCP-using app needs to be a cryptographically signed zip file approved by a marketplace.  So we do load directly from flash.

However, it’s not like flash on cellphones is equivalent to an infinitely fast, zero-latency network connection.  And even if it was, in a naive app you’d still try and load all of your HTML, CSS, and JavaScript at the same time because the HTML file would reference them all.  And that adds up.

It adds up in the form of event loop activity and competition with other threads and processes.  With the exception of Promises which get their own micro-task queue fast-lane, the web execution model is the same as all other UI event loops; events get scheduled and then executed in the same order they are scheduled.  Loading data from an asynchronous API like IndexedDB means that your read result gets in line behind everything else that’s scheduled.  And in the case of the bulk of shipped Firefox OS devices, we only have a single processor core so the thread and process contention do come into play.

So we try not to be a naive.

Seeming Fast at Startup: The HTML Cache

If we’re going to optimize startup, it’s good to start with what the user sees.  Once an account exists for the email app, at startup we display the default account’s inbox folder.

What is the least amount of work that we can do to show that?  Cache a screenshot of the Inbox.  The problem with that, of course, is that a static screenshot is indistinguishable from an unresponsive application.

So we did the next best thing, (which is) we cache the actual HTML we display.  At startup we load a minimal HTML file, our concatenated CSS, and just enough Javascript to figure out if we should use the HTML cache and then actually use it if appropriate.  It’s not always appropriate, like if our application is being triggered to display a compose UI or from a new mail notification that wants to show a specific message or a different folder.  But this is a decision we can make synchronously so it doesn’t slow us down.

Local Storage: Okay in small doses

We implement this by storing the HTML in localStorage.

Important Disclaimer!  LocalStorage is a bad API.  It’s a bad API because it’s synchronous.  You can read any value stored in it at any time, without waiting for a callback.  Which means if the data is not in memory the browser needs to block its event loop or spin a nested event loop until the data has been read from disk.  Browsers avoid this now by trying to preload the Entire contents of local storage for your origin into memory as soon as they know your page is being loaded.  And then they keep that information, ALL of it, in memory until your page is gone.

So if you store a megabyte of data in local storage, that’s a megabyte of data that needs to be loaded in its entirety before you can use any of it, and that hangs around in scarce phone memory.

To really make the point: do not use local storage, at least not directly.  Use a library like localForage that will use IndexedDB when available, and then fails over to WebSQLDatabase and local storage in that order.

Now, having sufficiently warned you of the terrible evils of local storage, I can say with a sorta-clear conscience… there are upsides in this very specific case.

The synchronous nature of the API means that once we get our turn in the event loop we can act immediately.  There’s no waiting around for an IndexedDB read result to gets its turn on the event loop.

This matters because although the concept of loading is simple from a User Experience perspective, there’s no standard to back it up right now.  Firefox OS’s UX desires are very straightforward.  When you tap on an app, we zoom it in.  Until the app is loaded we display the app’s icon in the center of the screen.  Unfortunately the standards are still assuming that the content is right there in the HTML.  This works well for document-based web pages or server-powered web apps where the contents of the page are baked in.  They work less well for client-only web apps where the content lives in a database and has to be dynamically retrieved.

The two events that exist are:

“DOMContentLoaded” fires when the document has been fully parsed and all scripts not tagged as “async” have run.  If there were stylesheets referenced prior to the script tags, the script tags will wait for the stylesheet loads.

“load” fires when the document has been fully loaded; stylesheets, images, everything.

But none of these have anything to do with the content in the page saying it’s actually done.  This matters because these standards also say nothing about IndexedDB reads or the like.  We tried to create a standards consensus around this, but it’s not there yet.  So Firefox OS just uses the “load” event to decide an app or page has finished loading and it can stop showing your app icon.  This largely avoids the dreaded “flash of unstyled content” problem, but it also means that your webpage or app needs to deal with this period of time by displaying a loading UI or just accepting a potentially awkward transient UI state.

(Trivial HTML slide)

<link rel=”stylesheet” ...> <script ...></script> DOMContentLoaded!

This is the important summary of our index.html.

We reference our stylesheet first.  It includes all of our styles.  We never dynamically load stylesheets because that compels a style recalculation for all nodes and potentially a reflow.  We would have to have an awful lot of style declarations before considering that.

Then we have our single script file.  Because the stylesheet precedes the script, our script will not execute until the stylesheet has been loaded.  Then our script runs and we synchronously insert our HTML from local storage.  Then DOMContentLoaded can fire.  At this point the layout engine has enough information to perform a style recalculation and determine what CSS-referenced image resources need to be loaded for buttons and icons, then those load, and then we’re good to be displayed as the “load” event can fire.

After that, we’re displaying an interactive-ish HTML document.  You can scroll, you can press on buttons and the :active state will apply.  So things seem real.

Being Fast: Lazy Loading and Optimized Layers

But now we need to try and get some logic in place as quickly as possible that will actually cash the checks that real-looking HTML UI is writing.  And the key to that is only loading what you need when you need it, and trying to get it to load as quickly as possible.

There are many module loading and build optimizing tools out there, and most frameworks have a preferred or required way of handling this.  We used the RequireJS family of Asynchronous Module Definition loaders, specifically the alameda loader and the r-dot-js optimizer.

One of the niceties of the loader plugin model is that we are able to express resource dependencies as well as code dependencies.

RequireJS Loader Plugins

var fooModule = require('./foo'); var htmlString = require('text!./foo.html'); var localizedDomNode = require('tmpl!./foo.html');

The standard Common JS loader semantics used by node.js and io.js are the first one you see here.  Load the module, return its exports.

But RequireJS loader plugins also allow us to do things like the second line where the exclamation point indicates that the load should occur using a loader plugin, which is itself a module that conforms to the loader plugin contract.  In this case it’s saying load the file foo.html as raw text and return it as a string.

But, wait, there’s more!  loader plugins can do more than that.  The third example uses a loader that loads the HTML file using the ‘text’ plugin under the hood, creates an HTML document fragment, and pre-localizes it using our localization library.  And this works un-optimized in a browser, no compilation step needed, but it can also be optimized.

So when our optimizer runs, it bundles up the core modules we use, plus, the modules for our “message list” card that displays the inbox.  And the message list card loads its HTML snippets using the template loader plugin.  The r-dot-js optimizer then locates these dependencies and the loader plugins also have optimizer logic that results in the HTML strings being inlined in the resulting optimized file.  So there’s just one single javascript file to load with no extra HTML file dependencies or other loads.

We then also run the optimizer against our other important cards like the “compose” card and the “message reader” card.  We don’t do this for all cards because it can be hard to carve up the module dependency graph for optimization without starting to run into cases of overlap where many optimized files redundantly include files loaded by other optimized files.

Plus, we have another trick up our sleeve:

Seeming Fast: Preloading

Preloading.  Our cards optionally know the other cards they can load.  So once we display a card, we can kick off a preload of the cards that might potentially be displayed.  For example, the message list card can trigger the compose card and the message reader card, so we can trigger a preload of both of those.

But we don’t go overboard with preloading in the frontend because we still haven’t actually loaded the back-end that actually does all the emaily email stuff.  The back-end is also chopped up into optimized layers along account type lines and online/offline needs, but the main optimized JS file still weighs in at something like 17 thousand lines of code with newlines retained.

So once our UI logic is loaded, it’s time to kick-off loading the back-end.  And in order to avoid impacting the responsiveness of the UI both while it loads and when we’re doing steady-state processing, we run it in a DOM Worker.

Being Responsive: Workers and SharedWorkers

DOM Workers are background JS threads that lack access to the page’s DOM, communicating with their owning page via message passing with postMessage.  Normal workers are owned by a single page.  SharedWorkers can be accessed via multiple pages from the same document origin.

By doing this, we stay out of the way of the main thread.  This is getting less important as browser engines support Asynchronous Panning & Zooming or “APZ” with hardware-accelerated composition, tile-based rendering, and all that good stuff.  (Some might even call it magic.)

When Firefox OS started, we didn’t have APZ, so any main-thread logic had the serious potential to result in janky scrolling and the impossibility of rendering at 60 frames per second.  It’s a lot easier to get 60 frames-per-second now, but even asynchronous pan and zoom potentially has to wait on dispatching an event to the main thread to figure out if the user’s tap is going to be consumed by app logic and preventDefault called on it.  APZ does this because it needs to know whether it should start scrolling or not.

And speaking of 60 frames-per-second…

Being Fast: Virtual List Widgets

…the heart of a mail application is the message list.  The expected UX is to be able to fling your way through the entire list of what the email app knows about and see the messages there, just like you would on a native app.

This is admittedly one of the areas where native apps have it easier.  There are usually list widgets that explicitly have a contract that says they request data on an as-needed basis.  They potentially even include data bindings so you can just point them at a data-store.

But HTML doesn’t yet have a concept of instantiate-on-demand for the DOM, although it’s being discussed by Firefox layout engine developers.  For app purposes, the DOM is a scene graph.  An extremely capable scene graph that can handle huge documents, but there are footguns and it’s arguably better to err on the side of fewer DOM nodes.

So what the email app does is we create a scroll-region div and explicitly size it based on the number of messages in the mail folder we’re displaying.  We create and render enough message summary nodes to cover the current screen, 3 screens worth of messages in the direction we’re scrolling, and then we also retain up to 3 screens worth in the direction we scrolled from.  We also pre-fetch 2 more screens worth of messages from the database.  These constants were arrived at experimentally on prototype devices.

We listen to “scroll” events and issue database requests and move DOM nodes around and update them as the user scrolls.  For any potentially jarring or expensive transitions such as coordinate space changes from new messages being added above the current scroll position, we wait for scrolling to stop.

Nodes are absolutely positioned within the scroll area using their ‘top’ style but translation transforms also work.  We remove nodes from the DOM, then update their position and their state before re-appending them.  We do this because the browser APZ logic tries to be clever and figure out how to create an efficient series of layers so that it can pre-paint as much of the DOM as possible in graphic buffers, AKA layers, that can be efficiently composited by the GPU.  Its goal is that when the user is scrolling, or something is being animated, that it can just move the layers around the screen or adjust their opacity or other transforms without having to ask the layout engine to re-render portions of the DOM.

When our message elements are added to the DOM with an already-initialized absolute position, the APZ logic lumps them together as something it can paint in a single layer along with the other elements in the scrolling region.  But if we start moving them around while they’re still in the DOM, the layerization logic decides that they might want to independently move around more in the future and so each message item ends up in its own layer.  This slows things down.  But by removing them and re-adding them it sees them as new with static positions and decides that it can lump them all together in a single layer.  Really, we could just create new DOM nodes, but we produce slightly less garbage this way and in the event there’s a bug, it’s nicer to mess up with 30 DOM nodes displayed incorrectly rather than 3 million.

But as neat as the layerization stuff is to know about on its own, I really mention it to underscore 2 suggestions:

1, Use a library when possible.  Getting on and staying on APZ fast-paths is not trivial, especially across browser engines.  So it’s a very good idea to use a library rather than rolling your own.

2, Use developer tools.  APZ is tricky to reason about and even the developers who write the Async pan & zoom logic can be surprised by what happens in complex real-world situations.  And there ARE developer tools available that help you avoid needing to reason about this.  Firefox OS has easy on-device developer tools that can help diagnose what’s going on or at least help tell you whether you’re making things faster or slower:

– it’s got a frames-per-second overlay; you do need to scroll like mad to get the system to want to render 60 frames-per-second, but it makes it clear what the net result is

– it has paint flashing that overlays random colors every time it paints the DOM into a layer.  If the screen is flashing like a discotheque or has a lot of smeared rainbows, you know something’s wrong because the APZ logic is not able to to just reuse its layers.

– devtools can enable drawing cool colored borders around the layers APZ has created so you can see if layerization is doing something crazy

There’s also fancier and more complicated tools in Firefox and other browsers like Google Chrome to let you see what got painted, what the layer tree looks like, et cetera.

And that’s my spiel.

Links

The source code to Gaia can be found at https://github.com/mozilla-b2g/gaia

The email app in particular can be found at https://github.com/mozilla-b2g/gaia/tree/master/apps/email

(I also asked for questions here.)

It was brought to my attention recently by reputable sources that the recent announcement of increased usage in recent years produced an internal firestorm within Mozilla. Key figures raised alarm that some of the tech press had interpreted the blog post as a sign that Thunderbird was not, in fact, dead. As a result, they asked Thunderbird community members to make corrections to emphasize that Mozilla was trying to kill Thunderbird.

The primary fear, it seems, is that knowledge that the largest open-source email client was still receiving regular updates would impel its userbase to agitate for increased funding and maintenance of the client to help forestall potential threats to the open nature of email as well as to innovate in the space of providing usable and private communication channels. Such funding, however, would be an unaffordable luxury and would only distract Mozilla from its central goal of building developer productivity tooling. Persistent rumors that Mozilla would be willing to fund Thunderbird were it renamed Firefox Email were finally addressed with the comment, "such a renaming would violate our current policy that all projects be named Persona."

This post is part 8 of an intermittent series exploring the difficulties of writing an email client. Part 1 describes a brief history of the infrastructure. Part 2 discusses internationalization. Part 3 discusses MIME. Part 4 discusses email addresses. Part 5 discusses the more general problem of email headers. Part 6 discusses how email security works in practice. Part 7 discusses the problem of trust. This part discusses why email security has largely failed.

At the end of the last part in this series, I posed the question, "Which email security protocol is most popular?" The answer to the question is actually neither S/MIME nor PGP, but a third protocol, DKIM. I haven't brought up DKIM until now because DKIM doesn't try to secure email in the same vein as S/MIME or PGP, but I still consider it relevant to discussing email security.

Unquestionably, DKIM is the only security protocol for email that can be considered successful. There are perhaps 4 billion active email addresses [1]. Of these, about 1-2 billion use DKIM. In contrast, S/MIME can count a few million users, and PGP at best a few hundred thousand. No other security protocols have really caught on past these three. Why did DKIM succeed where the others fail?

DKIM's success stems from its relatively narrow focus. It is nothing more than a cryptographic signature of the message body and a smattering of headers, and is itself stuck in the DKIM-Signature header. It is meant to be applied to messages only on outgoing servers and read and processed at the recipient mail server—it completely bypasses clients. That it bypasses clients allows it to solve the problem of key discovery and key management very easily (public keys are stored in DNS, which is already a key part of mail delivery), and its role in spam filtering is strong motivation to get it implemented quickly (it is 7 years old as of this writing). It's also simple: this one paragraph description is basically all you need to know [2].

The failure of S/MIME and PGP to see large deployment is certainly a large topic of discussion on myriads of cryptography enthusiast mailing lists, which often like to partake in propositions of new end-to-end encryption of email paradigms, such as the recent DIME proposal. Quite frankly, all of these solutions suffer broadly from at least the same 5 fundamental weaknesses, and I see it unlikely that a protocol will come about that can fix these weaknesses well enough to become successful.

The first weakness, and one I've harped about many times already, is UI. Most email security UI is abysmal and generally at best usable only by enthusiasts. At least some of this is endemic to security: while it mean seem obvious how to convey what an email signature or an encrypted email signifies, how do you convey the distinctions between sign-and-encrypt, encrypt-and-sign, or an S/MIME triple wrap? The Web of Trust model used by PGP (and many other proposals) is even worse, in that inherently requires users to do other actions out-of-band of email to work properly.

Trust is the second weakness. Consider that, for all intents and purposes, the email address is the unique identifier on the Internet. By extension, that implies that a lot of services are ultimately predicated on the notion that the ability to receive and respond to an email is a sufficient means to identify an individual. However, the entire purpose of secure email, or at least of end-to-end encryption, is subtly based on the fact that other people in fact have access to your mailbox, thus destroying the most natural ways to build trust models on the Internet. The quest for anonymity or privacy also renders untenable many other plausible ways to establish trust (e.g., phone verification or government-issued ID cards).

Key discovery is another weakness, although it's arguably the easiest one to solve. If you try to keep discovery independent of trust, the problem of key discovery is merely picking a protocol to publish and another one to find keys. Some of these already exist: PGP key servers, for example, or using DANE to publish S/MIME or PGP keys.

Key management, on the other hand, is a more troubling weakness. S/MIME, for example, basically works without issue if you have a certificate, but managing to get an S/MIME certificate is a daunting task (necessitated, in part, by its trust model—see how these issues all intertwine?). This is also where it's easy to say that webmail is an unsolvable problem, but on further reflection, I'm not sure I agree with that statement anymore. One solution is just storing the private key with the webmail provider (you're trusting them as an email client, after all), but it's also not impossible to imagine using phones or flash drives as keystores. Other key management factors are more difficult to solve: people who lose their private keys or key rollover create thorny issues. There is also the difficulty of managing user expectations: if I forget my password to most sites (even my email provider), I can usually get it reset somehow, but when a private key is lost, the user is totally and completely out of luck.

Of course, there is one glaring and almost completely insurmountable problem. Encrypted email fundamentally precludes certain features that we have come to take for granted. The lesser known is server-side search and filtration. While there exist some mechanisms to do search on encrypted text, those mechanisms rely on the fact that you can manipulate the text to change the message, destroying the integrity feature of secure email. They also tend to be fairly expensive. It's easy to just say "who needs server-side stuff?", but the contingent of people who do email on smartphones would not be happy to have to pay the transfer rates to download all the messages in their folder just to find one little email, nor the energy costs of doing it on the phone. And those who have really large folders—Fastmail has a design point of 1,000,000 in a single folder—would still prefer to not have to transfer all their mail even on desktops.

The more well-known feature that would disappear is spam filtration. Consider that 90% of all email is spam, and if you think your spam folder is too slim for that to be true, it's because your spam folder only contains messages that your email provider wasn't sure were spam. The loss of server-side spam filtering would dramatically increase the cost of spam (a 10% reduction in efficiency would double the amount of server storage, per my calculations), and client-side spam filtering is quite literally too slow [3] and too costly (remember smartphones? Imagine having your email take 10 times as much energy and bandwidth) to be a tenable option. And privacy or anonymity tends to be an invitation to abuse (cf. Tor and Wikipedia). Proposed solutions to the spam problem are so common that there is a checklist containing most of the objections.

When you consider all of those weaknesses, it is easy to be pessimistic about the possibility of wide deployment of powerful email security solutions. The strongest future—all email is encrypted, including metadata—is probably impossible or at least woefully impractical. That said, if you weaken some of the assumptions (say, don't desire all or most traffic to be encrypted), then solutions seem possible if difficult.

This concludes my discussion of email security, at least until things change for the better. I don't have a topic for the next part in this series picked out (this part actually concludes the set I knew I wanted to discuss when I started), although OAuth and DMARC are two topics that have been bugging me enough recently to consider writing about. They also have the unfortunate side effect of being things likely to see changes in the near future, unlike most of the topics I've discussed so far. But rest assured that I will find more difficulties in the email infrastructure to write about before long!

[1] All of these numbers are crude estimates and are accurate to only an order of magnitude. To justify my choices: I assume 1 email address per Internet user (this overestimates the developing world and underestimates the developed world). The largest webmail providers have given numbers that claim to be 1 billion active accounts between them, and all of them use DKIM. S/MIME is guessed by assuming that any smartcard deployment supports S/MIME, and noting that the US Department of Defense and Estonia's digital ID project are both heavy users of such smartcards. PGP is estimated from the size of the strong set and old numbers on the reachable set from the core Web of Trust.
[2] Ever since last April, it's become impossible to mention DKIM without referring to DMARC, as a result of Yahoo's controversial DMARC policy. A proper discussion of DMARC (and why what Yahoo did was controversial) requires explaining the mail transmission architecture and spam, however, so I'll defer that to a later post. It's also possible that changes in this space could happen within the next year.
[3] According to a former GMail spam employee, if it takes you as long as three minutes to calculate reputation, the spammer wins.

Several years back, Ehsan and Jeff Muizelaar attempted to build a unified history of mozilla-central across the Mercurial era and the CVS era. Their result is now used in the gecko-dev repository. While being distracted on yet another side project, I thought that I might want to do the same for comm-central. It turns out that building a unified history for comm-central makes mozilla-central look easy: mozilla-central merely had one import from CVS. In contrast, comm-central imported twice from CVS (the calendar code came later), four times from mozilla-central (once with converted history), and imported twice from Instantbird's repository (once with converted history). Three of those conversions also involved moving paths. But I've worked through all of those issues to provide a nice snapshot of the repository [1]. And since I've been frustrated by failing to find good documentation on how this sort of process went for mozilla-central, I'll provide details on the process for comm-central.

The first step and probably the hardest is getting the CVS history in DVCS form (I use hg because I'm more comfortable it, but there's effectively no difference between hg, git, or bzr here). There is a git version of mozilla's CVS tree available, but I've noticed after doing research that its last revision is about a month before the revision I need for Calendar's import. The documentation for how that repo was built is no longer on the web, although we eventually found a copy after I wrote this post on git.mozilla.org. I tried doing another conversion using hg convert to get CVS tags, but that rudely blew up in my face. For now, I've filed a bug on getting an official, branchy-and-tag-filled version of this repository, while using the current lack of history as a base. Calendar people will have to suffer missing a month of history.

CVS is famously hard to convert to more modern repositories, and, as I've done my research, Mozilla's CVS looks like it uses those features which make it difficult. In particular, both the calendar CVS import and the comm-central initial CVS import used a CVS tag HG_COMM_INITIAL_IMPORT. That tagging was done, on only a small portion of the tree, twice, about two months apart. Fortunately, mailnews code was never touched on CVS trunk after the import (there appears to be one commit on calendar after the tagging), so it is probably possible to salvage a repository-wide consistent tag.

The start of my script for conversion looks like this:

#!/bin/bash set -e WORKDIR=/tmp HGCVS=$WORKDIR/mozilla-cvs-history MC=/src/trunk/mozilla-central CC=/src/trunk/comm-central OUTPUT=$WORKDIR/full-c-c # Bug 445146: m-c/editor/ui -> c-c/editor/ui MC_EDITOR_IMPORT=d8064eff0a17372c50014ee305271af8e577a204 # Bug 669040: m-c/db/mork -> c-c/db/mork MC_MORK_IMPORT=f2a50910befcf29eaa1a29dc088a8a33e64a609a # Bug 1027241, bug 611752 m-c/security/manager/ssl/** -> c-c/mailnews/mime/src/* MC_SMIME_IMPORT=e74c19c18f01a5340e00ecfbc44c774c9a71d11d # Step 0: Grab the mozilla CVS history. if [ ! -e $HGCVS ]; then hg clone git+https://github.com/jrmuizel/mozilla-cvs-history.git $HGCVS fi

Since I don't want to include the changesets useless to comm-central history, I trimmed the history by using hg convert to eliminate changesets that don't change the necessary files. Most of the files are simple directory-wide changes, but S/MIME only moved a few files over, so it requires a more complex way to grab the file list. In addition, I also replaced the % in the usernames with @ that they are used to appearing in hg. The relevant code is here:

# Step 1: Trim mozilla CVS history to include only the files we are ultimately # interested in. cat >$WORKDIR/convert-filemap.txt <<EOF # Revision e4f4569d451a include directory/xpcom include mail include mailnews include other-licenses/branding/thunderbird include suite # Revision 7c0bfdcda673 include calendar include other-licenses/branding/sunbird # Revision ee719a0502491fc663bda942dcfc52c0825938d3 include editor/ui # Revision 52efa9789800829c6f0ee6a005f83ed45a250396 include db/mork/ include db/mdb/ EOF # Add the S/MIME import files hg -R $MC log -r "children($MC_SMIME_IMPORT)" \ --template "{file_dels % 'include {file}\n'}" >>$WORKDIR/convert-filemap.txt if [ ! -e $WORKDIR/convert-authormap.txt ]; then hg -R $HGCVS log --template "{email(author)}={sub('%', '@', email(author))}\n" \ | sort -u > $WORKDIR/convert-authormap.txt fi cd $WORKDIR hg convert $HGCVS $OUTPUT --filemap convert-filemap.txt -A convert-authormap.txt

That last command provides us the subset of the CVS history that we need for unified history. Strictly speaking, I should be pulling a specific revision, but I happen to know that there's no need to (we're cloning the only head) in this case. At this point, we now need to pull in the mozilla-central changes before we pull in comm-central. Order is key; hg convert will only apply the graft points when converting the child changeset (which it does but once), and it needs the parents to exist before it can do that. We also need to ensure that the mozilla-central graft point is included before continuing, so we do that, and then pull mozilla-central:

CC_CVS_BASE=$(hg log -R $HGCVS -r 'tip' --template '{node}') CC_CVS_BASE=$(grep $CC_CVS_BASE $OUTPUT/.hg/shamap | cut -d' ' -f2) MC_CVS_BASE=$(hg log -R $HGCVS -r 'gitnode(215f52d06f4260fdcca797eebd78266524ea3d2c)' --template '{node}') MC_CVS_BASE=$(grep $MC_CVS_BASE $OUTPUT/.hg/shamap | cut -d' ' -f2) # Okay, now we need to build the map of revisions. cat >$WORKDIR/convert-revmap.txt <<EOF e4f4569d451a5e0d12a6aa33ebd916f979dd8faa $CC_CVS_BASE # Thunderbird / Suite 7c0bfdcda6731e77303f3c47b01736aaa93d5534 d4b728dc9da418f8d5601ed6735e9a00ac963c4e, $CC_CVS_BASE # Calendar 9b2a99adc05e53cd4010de512f50118594756650 $MC_CVS_BASE # Mozilla graft point ee719a0502491fc663bda942dcfc52c0825938d3 78b3d6c649f71eff41fe3f486c6cc4f4b899fd35, $MC_EDITOR_IMPORT # Editor 8cdfed92867f885fda98664395236b7829947a1d 4b5da7e5d0680c6617ec743109e6efc88ca413da, e4e612fcae9d0e5181a5543ed17f705a83a3de71 # Chat EOF # Next, import mozilla-central revisions for rev in $MC_MORK_IMPORT $MC_EDITOR_IMPORT $MC_SMIME_IMPORT; do hg convert $MC $OUTPUT -r $rev --splicemap $WORKDIR/convert-revmap.txt \ --filemap $WORKDIR/convert-filemap.txt done

Some notes about all of the revision ids in the script. The splicemap requires the full 40-character SHA ids; anything less and the thing complains. I also need to specify the parents of the revisions that deleted the code for the mozilla-central import, so if you go hunting for those revisions and are surprised that they don't remove the code in question, that's why.

I mentioned complications about the merges earlier. The Mork and S/MIME import codes here moved files, so that what was db/mdb in mozilla-central became db/mork. There's no support for causing the generated splice to record these as a move, so I have to manually construct those renamings:

# We need to execute a few hg move commands due to renamings. pushd $OUTPUT hg update -r $(grep $MC_MORK_IMPORT .hg/shamap | cut -d' ' -f2) (hg -R $MC log -r "children($MC_MORK_IMPORT)" \ --template "{file_dels % 'hg mv {file} {sub(\"db/mdb\", \"db/mork\", file)}\n'}") | bash hg commit -m 'Pseudo-changeset to move Mork files' -d '2011-08-06 17:25:21 +0200' MC_MORK_IMPORT=$(hg log -r tip --template '{node}') hg update -r $(grep $MC_SMIME_IMPORT .hg/shamap | cut -d' ' -f2) (hg -R $MC log -r "children($MC_SMIME_IMPORT)" \ --template "{file_dels % 'hg mv {file} {sub(\"security/manager/ssl\", \"mailnews/mime\", file)}\n'}") | bash hg commit -m 'Pseudo-changeset to move S/MIME files' -d '2014-06-15 20:51:51 -0700' MC_SMIME_IMPORT=$(hg log -r tip --template '{node}') popd # Echo the new move commands to the changeset conversion map. cat >>$WORKDIR/convert-revmap.txt <<EOF 52efa9789800829c6f0ee6a005f83ed45a250396 abfd23d7c5042bc87502506c9f34c965fb9a09d1, $MC_MORK_IMPORT # Mork 50f5b5fc3f53c680dba4f237856e530e2097adfd 97253b3cca68f1c287eb5729647ba6f9a5dab08a, $MC_SMIME_IMPORT # S/MIME EOF

Now that we have all of the graft points defined, and all of the external code ready, we can pull comm-central and do the conversion. That's not quite it, though—when we graft the S/MIME history to the original mozilla-central history, we have a small segment of abandoned converted history. A call to hg strip removes that.

# Now, import comm-central revisions that we need hg convert $CC $OUTPUT --splicemap $WORKDIR/convert-revmap.txt hg strip 2f69e0a3a05a

[1] I left out one of the graft points because I just didn't want to deal with it. I'll leave it as an exercise to the reader to figure out which one it was. Hint: it's the only one I didn't know about before I searched for the archive points [2].
[2] Since I wasn't sure I knew all of the graft points, I decided to try to comb through all of the changesets to figure out who imported code. It turns out that hg log -r 'adds("**")' narrows it down nicely (1667 changesets to look at instead of 17547), and using the {file_adds} template helps winnow it down more easily.