<div dir="ltr"><div>Hello everyone,</div><div><br></div><div>Tom Ritter, Freddy Braun and I have been working on increasing visibility into all the things that are going on in Firefox Security Engineering. Starting with Q1 2020, we are crafting a quarterly newsletter summarizing Firefox security work across various teams. While we're still editing the Q1 edition, we figured you might enjoy a "2019 in Recap" we put together in the meantime.<br></div><div><br></div><div>You can find it either in the remainder of this email or on <a href="https://wiki.mozilla.org/Firefox_Security_Newsletter/FSN-2019" target="_blank">https://wiki.mozilla.org/Firefox_Security_Newsletter/FSN-2019</a>, whichever you prefer.<br></div><div><br></div><div>If you notice that anything is missing or we didn't properly represent a team, please let us know so that we can improve on that in the future.<br></div><div><br></div><div>Thank you,</div><div><br></div><div>Johann<br></div><div><br></div><div>*Firefox Security Newsletter - 2019 in Recap*</div>
<br>
Maintaining and building a secure modern browser is one of the most<br>
challenging tasks in software engineering. You’re up against sharp<br>
competition from other browsers and an incredibly large ecosystem of<br>
malicious actors and white-hat security researchers. To keep up you need<br>
a great team. Working on Firefox, I pride myself with being surrounded<br>
by some of the best browser security engineers in the world. In this newsletter<br>
we wanted to share what we all have been up to in 2019.<br>
<br>
In the future we’ll be publishing this update quarterly, using a few<br>
categories, with explanations for what they mean right below their<br>
headlines. An archive of all newsletters will be permanently available<br>
at <a href="https://wiki.mozilla.org/Firefox_Security_Newsletter" rel="noreferrer" target="_blank">https://wiki.mozilla.org/Firefox_Security_Newsletter</a>.<br>
<<a href="https://wiki.mozilla.org/Firefox_Security_Newsletter" rel="noreferrer" target="_blank">https://wiki.mozilla.org/Firefox_Security_Newsletter</a>><br>
<br>
It is of course impossible to present the vast amount of work that went<br>
into each of the highlighted projects in a single blog post, so I highly<br>
recommend following the links to read more about the individual efforts.<br>
<br>
<br>
  Privacy<br>
<br>
/This is our work to deliver a more private experience on the web to all<br>
Firefox users./<br>
<br>
A big focus of 2019 was the *Anti-Tracking* project. With the 69 release<br>
we shipped ETP (_Enhanced Tracking Protection_<br>
<<a href="https://support.mozilla.org/en-US/kb/enhanced-tracking-protection-firefox-desktop" rel="noreferrer" target="_blank">https://support.mozilla.org/en-US/kb/enhanced-tracking-protection-firefox-desktop</a>>)<br>
to all Firefox users by default. This was a huge milestone for the team<br>
and for privacy on the web overall.<br>
<br>
In addition to our anti-tracking efforts, we also shipped *protections<br>
from cryptomining, fingerprinting and social networks* that were<br>
tracking users through the web.<br>
<br>
To highlight these new features, the team built _an entirely new _<br>
<<a href="https://blog.mozilla.org/firefox/firefox-privacy-protections/" rel="noreferrer" target="_blank">https://blog.mozilla.org/firefox/firefox-privacy-protections/</a>>_*Protections<br>
UI*_ <<a href="https://blog.mozilla.org/firefox/firefox-privacy-protections/" rel="noreferrer" target="_blank">https://blog.mozilla.org/firefox/firefox-privacy-protections/</a>>,<br>
that consists of a new panel in the address bar as well as the new<br>
about:protections page that allows users to get an overview of their<br>
active protections.<br>
<br>
In addition to our default-on tracking protections, the privacy<br>
engineering team also works with the _Tor Browser_<br>
<<a href="https://www.torproject.org/" rel="noreferrer" target="_blank">https://www.torproject.org/</a>> team to develop and integrate more<br>
advanced origin isolation and _anti-fingerprinting techniques_<br>
<<a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1329996" rel="noreferrer" target="_blank">https://bugzilla.mozilla.org/show_bug.cgi?id=1329996</a>> intended for<br>
usage in the Tor Browser. Sometimes those techniques start in Tor<br>
Browser and move to Firefox; other times they start in Firefox and move<br>
to Tor Browser. The most prominent example of this work in 2019 was<br>
_Letterboxing_ <<a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1407366" rel="noreferrer" target="_blank">https://bugzilla.mozilla.org/show_bug.cgi?id=1407366</a>>, a<br>
way for the browser to shrink the content viewport to make it less unique.<br>
<br>
In an effort to improve our coverage of Origin Attributes across the<br>
code base, Paul Zühlcke added _support for handling OAs in the Firefox<br>
permission manager_<br>
<<a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1422056" rel="noreferrer" target="_blank">https://bugzilla.mozilla.org/show_bug.cgi?id=1422056</a>>. This means that<br>
web permissions can now be scoped by private browsing window, per<br>
container or using first party isolation.<br>
<br>
Steven Englehardt _wrote a summary_<br>
<<a href="https://blog.mozilla.org/security/2019/06/06/next-steps-in-privacy-preserving-telemetry-with-prio/" rel="noreferrer" target="_blank">https://blog.mozilla.org/security/2019/06/06/next-steps-in-privacy-preserving-telemetry-with-prio/</a>><br>
of our progress on privacy-preserving telemetry with *Prio*. We landed<br>
the necessary pieces to perform the privacy-preserving origin telemetry<br>
in Nightly and will be testing it before deploying further to Release.<br>
<br>
The Facebook Container team shipped _Facebook Container 2.0_<br>
<<a href="https://blog.mozilla.org/firefox/facebook-container-for-firefox/" rel="noreferrer" target="_blank">https://blog.mozilla.org/firefox/facebook-container-for-firefox/</a>>, with<br>
significant improvements to our extension that keeps Facebook from<br>
tracking you around the web for good.<br>
<br>
<br>
  Core Security<br>
<br>
/Core security, for us, means efforts to protect Firefox from<br>
vulnerabilities and exploits. This work is usually not exposed to users,<br>
but everyone benefits from having a rock-solid secure browser./<br>
<br>
<br>
In 2019 we shipped *4 security-related “chemspill” releases*, meaning<br>
urgent dot-versions of Firefox (e.g. 72.0.1) that contained especially<br>
urgent security fixes. Each of these chemspills went out within a day!<br>
<br>
Several teams concentrated their efforts on *Hardening the Firefox<br>
Security Architecture, *with a particular focus on sandbox escapes.<br>
Listed below are the main projects that were part of this effort.<br>
<br>
We improved our protection against JavaScript code injection in browser<br>
UI or other privileged areas of code (e.g. about: pages). To this end<br>
Gijs _prevented untrusted pages from being loaded in the parent process_<br>
<<a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1560178" rel="noreferrer" target="_blank">https://bugzilla.mozilla.org/show_bug.cgi?id=1560178</a>>. Christoph<br>
Kerschbaumer _applied CSPs to all of our about: pages_<br>
<<a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1492063" rel="noreferrer" target="_blank">https://bugzilla.mozilla.org/show_bug.cgi?id=1492063</a>>. Jonas Allman and<br>
Tom Ritter removed and disallowed _usage of eval() in the parent process<br>
and system privileged code_<br>
<<a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1473549" rel="noreferrer" target="_blank">https://bugzilla.mozilla.org/show_bug.cgi?id=1473549</a>>. Freddy Braun<br>
_disallowed non-internal resources_<br>
<<a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1513445" rel="noreferrer" target="_blank">https://bugzilla.mozilla.org/show_bug.cgi?id=1513445</a>> do be loaded as<br>
documents in privileged contexts. More efforts of this type are underway<br>
in 2020.<br>
<br>
Zombie reduced the possibility of sandbox escapes through malicious IPC<br>
messages by _ensuring_<br>
<<a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1604058" rel="noreferrer" target="_blank">https://bugzilla.mozilla.org/show_bug.cgi?id=1604058</a>> that IPC messages<br>
claiming to come from the extension process do, in fact, come from an<br>
actual web extension.<br>
<br>
The Hardening team, in conjunction with the Low Level Tools team,<br>
deployed _memory partitioning_<br>
<<a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1052575" rel="noreferrer" target="_blank">https://bugzilla.mozilla.org/show_bug.cgi?id=1052575</a>>, isolating<br>
particularly powerful attacker-controlled objects like Strings and<br>
ArrayBuffers from other DOM objects, as well as additional guard pages<br>
around certain types of memory structures.<br>
<br>
Jed Davis gave us the ability to share memory with a content process,<br>
but _freezing_ <<a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1479960" rel="noreferrer" target="_blank">https://bugzilla.mozilla.org/show_bug.cgi?id=1479960</a>> it<br>
so the content process cannot write to it.<br>
<br>
A big effort in 2019 and also in 2020 is the _*Fission*_<br>
<<a href="https://wiki.mozilla.org/Project_Fission" rel="noreferrer" target="_blank">https://wiki.mozilla.org/Project_Fission</a>>_project_<br>
<<a href="https://wiki.mozilla.org/Project_Fission" rel="noreferrer" target="_blank">https://wiki.mozilla.org/Project_Fission</a>>, that aims to achieve true<br>
process isolation per site. This is a very extensive project that<br>
involves rewriting large parts of the browser and engine code. In 2019<br>
we achieved a number of milestones for Fission progress, such as<br>
implementing DocumentChannel (a refactoring of how navigation occurs),<br>
building a _multiprocess browser toolbox_<br>
<<a href="https://groups.google.com/forum/#!topic/mozilla.dev.platform/daAfrjkYs0c" rel="noreferrer" target="_blank">https://groups.google.com/forum/#!topic/mozilla.dev.platform/daAfrjkYs0c</a>>,<br>
burning down _a lot of test failures_ <<a href="https://arewefissionyet.com/" rel="noreferrer" target="_blank">https://arewefissionyet.com/</a>>.<br>
Fission will continue in 2020 where we expect to have something everyone<br>
can turn on and report any issues with.<br>
<br>
The Browser Architecture team was able to remove the last traces of<br>
_XBL_ <<a href="https://developer.mozilla.org/en-US/docs/Archive/Mozilla/XBL" rel="noreferrer" target="_blank">https://developer.mozilla.org/en-US/docs/Archive/Mozilla/XBL</a>><br>
from Firefox code, eliminating a lot of old code and some obvious attack<br>
surfaces for sandbox escapes along the way.<br>
<br>
Jonas _integrated_<br>
<<a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1508659" rel="noreferrer" target="_blank">https://bugzilla.mozilla.org/show_bug.cgi?id=1508659</a>> _Project<br>
Wycheproof_ <<a href="https://github.com/google/wycheproof" rel="noreferrer" target="_blank">https://github.com/google/wycheproof</a>> for testing our NSS<br>
cryptography library.<br>
<br>
The Fuzzing team added new targets this year, such as _Necko_<br>
<<a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1526258" rel="noreferrer" target="_blank">https://bugzilla.mozilla.org/show_bug.cgi?id=1526258</a>> (the Gecko<br>
networking stack) and _IndexedDB_<br>
<<a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1499097" rel="noreferrer" target="_blank">https://bugzilla.mozilla.org/show_bug.cgi?id=1499097</a>> and published the<br>
_Grizzly Browser Fuzzing Framework_<br>
<<a href="https://blog.mozilla.org/security/2019/07/10/grizzly/" rel="noreferrer" target="_blank">https://blog.mozilla.org/security/2019/07/10/grizzly/</a>>.<br>
<br>
The Platform Security team deployed our most restrictive sandbox yet in<br>
the Media Decoder process on _Windows and OSX_<br>
<<a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1498624" rel="noreferrer" target="_blank">https://bugzilla.mozilla.org/show_bug.cgi?id=1498624</a>>, and made<br>
considerable progress on our multi-year effort to remove win32k from the<br>
content process on Windows.<br>
<br>
With considerable help from :dmajor, the Platform Security team<br>
_deployed a limited form of Control Flow Guard_<br>
<<a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1485016" rel="noreferrer" target="_blank">https://bugzilla.mozilla.org/show_bug.cgi?id=1485016</a>> support for<br>
Windows, with hopes of expanding it in 2020.<br>
<br>
Haik _spent a considerable amount of time_<br>
<<a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1471004" rel="noreferrer" target="_blank">https://bugzilla.mozilla.org/show_bug.cgi?id=1471004</a>> to support<br>
Catalina’s new required software notarization scheme and hardened<br>
runtime support.<br>
<br>
Aaron Klotz and Toshihito Kikuchi _worked to improve our telemetry_<br>
<<a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1435773" rel="noreferrer" target="_blank">https://bugzilla.mozilla.org/show_bug.cgi?id=1435773</a>> and insight into<br>
third party modules that inject in our process on Windows.<br>
<br>
With the help of a UCSD research team, _we compiled the graphite font<br>
rendering_ <<a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1562797" rel="noreferrer" target="_blank">https://bugzilla.mozilla.org/show_bug.cgi?id=1562797</a>><br>
library as wasm, enclosing it in a sandbox with data validation.<br>
Currently in Beta on Linux x64, this allows us to turn a C library into<br>
a memory safe language and firewalling it from the rest of the process.<br>
Future expansion to new libraries and OSX and Windows are underway.<br>
<br>
<br>
  Firefox Security<br>
<br>
/Firefox Security means user-exposed security features that allow you to<br>
have a safe experience on the web./<br>
<br>
The *Firefox Lockwise* team significantly revamped the desktop password<br>
manager experience, bringing Lockwise to desktop. New features include a<br>
new password management UI (about:logins), _secure password generation,<br>
integration with Firefox Monitor_<br>
<<a href="https://blog.mozilla.org/firefox/password-security-features/" rel="noreferrer" target="_blank">https://blog.mozilla.org/firefox/password-security-features/</a>> and _more<br>
improvements and bugfixes_<br>
<<a href="https://matthew.noorenberghe.com/blog/2019/05/password-manager-improvements-firefox-67" rel="noreferrer" target="_blank">https://matthew.noorenberghe.com/blog/2019/05/password-manager-improvements-firefox-67</a>>.<br>
<br>
We released the Beta version of an entirely new product in the Firefox<br>
family: _*Firefox Private Network*_ <<a href="https://fpn.firefox.com/" rel="noreferrer" target="_blank">https://fpn.firefox.com/</a>>, a VPN<br>
and Proxy solution by Mozilla.<br>
<br>
Our interns Carolina and Danielle built an entirely new *Certificate<br>
Viewer *(about:certificate) for Firefox, modeled after the popular<br>
_Certainly Something_<br>
<<a href="https://addons.mozilla.org/en-US/firefox/addon/certainly-something/" rel="noreferrer" target="_blank">https://addons.mozilla.org/en-US/firefox/addon/certainly-something/</a>><br>
browser extension which itself was developed by April King, another<br>
Mozilla engineer.<br>
<br>
The *DNS-over-HTTPS* project aims to improve the problematic privacy and<br>
security properties of DNS for our users. In 2019, the DoH team _ran<br>
experiments and added a way for parental controls providers to disable<br>
DoH_<br>
<<a href="https://blog.mozilla.org/futurereleases/2019/09/06/whats-next-in-making-dns-over-https-the-default/" rel="noreferrer" target="_blank">https://blog.mozilla.org/futurereleases/2019/09/06/whats-next-in-making-dns-over-https-the-default/</a>>,<br>
in preparation for the upcoming launch.<br>
<br>
The Firefox 70 release brought us _new improved security UI indicators_<br>
<<a href="https://blog.mozilla.org/security/2019/10/15/improved-security-and-privacy-indicators-in-firefox-70/" rel="noreferrer" target="_blank">https://blog.mozilla.org/security/2019/10/15/improved-security-and-privacy-indicators-in-firefox-70/</a>>,<br>
with a new indicator for insecure HTTP connections, as well as a reduced<br>
level of presentation for Extended Validation certificates.<br>
<br>
<br>
We shipped an updated design for our_certificate error pages_<br>
<<a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1530327" rel="noreferrer" target="_blank">https://bugzilla.mozilla.org/show_bug.cgi?id=1530327</a>> (built by our<br>
Outreachy intern Trisha Gupta) including a brand new error page<br>
highlighting when the local system time being off is likely at fault for<br>
the error.<br>
<br>
<br>
<br>
In an effort to reduce breakage from Anti-Virus and other software that<br>
tries to intercept connections without installing their root certificate<br>
in the Firefox cert store, the team built a mode where Firefox can<br>
*automatically detect MitM-related certificate errors* that would be<br>
fixed by importing certificates from the OS root store. In addition to<br>
that, _there’s now a message shown in the identity popup when the site<br>
is verified by an imported root certificate_<br>
<<a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1549605" rel="noreferrer" target="_blank">https://bugzilla.mozilla.org/show_bug.cgi?id=1549605</a>>.<br>
<br>
The Firefox Add-on Manager now includes an _integrated abuse report<br>
mechanism_ <<a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1544928" rel="noreferrer" target="_blank">https://bugzilla.mozilla.org/show_bug.cgi?id=1544928</a>>, to<br>
help users quickly report malicious add-ons.<br>
<br>
We _improved our indicators for geolocation usage_<br>
<<a href="https://bugzilla.mozilla.org/show_bug.cgi?id=630614" rel="noreferrer" target="_blank">https://bugzilla.mozilla.org/show_bug.cgi?id=630614</a>> to include an<br>
in-use indicator and show when geolocation was last accessed by the site.<br>
<br>
<br>
<br>
  Web Security<br>
<br>
/This encompasses efforts to build features that allow web developers to<br>
build more secure sites. It sometimes also means restrictions made on<br>
web developers to *force* them to build more secure sites./<br>
<br>
The Crypto Engineering team released _Web Authentication in Firefox for<br>
Android_<br>
<<a href="https://blog.mozilla.org/security/2019/08/05/web-authentication-in-firefox-for-android/" rel="noreferrer" target="_blank">https://blog.mozilla.org/security/2019/08/05/web-authentication-in-firefox-for-android/</a>>.<br>
<br>
We announced our plan to _remove support for TLS 1.0 and 1.1 in March<br>
2020_<br>
<<a href="https://hacks.mozilla.org/2019/05/tls-1-0-and-1-1-removal-update/" rel="noreferrer" target="_blank">https://hacks.mozilla.org/2019/05/tls-1-0-and-1-1-removal-update/</a>>. In<br>
2019, we started rolling this change out to Nightly users and<br>
implemented a temporary override to allow early testers to avoid breakage.<br>
<br>
After a _series of experiments_<br>
<<a href="https://blog.nightly.mozilla.org/2019/04/01/reducing-notification-permission-prompt-spam-in-firefox/" rel="noreferrer" target="_blank">https://blog.nightly.mozilla.org/2019/04/01/reducing-notification-permission-prompt-spam-in-firefox/</a>>,<br>
we launched _strong restrictions_<br>
<<a href="https://blog.mozilla.org/futurereleases/2019/11/04/restricting-notification-permission-prompts-in-firefox/" rel="noreferrer" target="_blank">https://blog.mozilla.org/futurereleases/2019/11/04/restricting-notification-permission-prompts-in-firefox/</a>><br>
on notification permission prompts that will reduce the massive<br>
annoyance they presented to users of the web.<br>
<br>
Johann Hofmann _put web push notifications behind secure context_<br>
<<a href="https://groups.google.com/forum/#!topic/mozilla.dev.platform/FMPrIMGBNtg" rel="noreferrer" target="_blank">https://groups.google.com/forum/#!topic/mozilla.dev.platform/FMPrIMGBNtg</a>>.<br>
Ehsan Akhgari _removed the ability_<br>
<<a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1560741" rel="noreferrer" target="_blank">https://bugzilla.mozilla.org/show_bug.cgi?id=1560741</a>> for third party<br>
iframes to use web notifications.<br>
<br>
In a cooperation with Cloudflare, the Crypto Engineering team started to<br>
experiment with _Delegated Credentials for TLS_<br>
<<a href="https://blog.mozilla.org/security/2019/11/01/validating-delegated-credentials-for-tls-in-firefox/" rel="noreferrer" target="_blank">https://blog.mozilla.org/security/2019/11/01/validating-delegated-credentials-for-tls-in-firefox/</a>>,<br>
a mechanism which can alleviate trust concerns around distributing<br>
private keys to CDNs, without any of the performance overhead from<br>
alternative solutions.<br>
<br>
Jonathan Kingston sent out an intent to _remove AppCache_<br>
<<a href="https://www.fxsitecompat.dev/en-CA/docs/2019/application-cache-storage-has-been-removed-in-nightly-and-early-beta/" rel="noreferrer" target="_blank">https://www.fxsitecompat.dev/en-CA/docs/2019/application-cache-storage-has-been-removed-in-nightly-and-early-beta/</a>>,<br>
starting with Nightly and Beta in version 71 and to be unshipped in<br>
Release in 2020.<br>
<br>
In several cases, Paul Zühlcke limited the ability for websites to spam<br>
_window-modal dialogs_<br>
<<a href="https://bugzilla.mozilla.org/show_bug.cgi?id=616843" rel="noreferrer" target="_blank">https://bugzilla.mozilla.org/show_bug.cgi?id=616843</a>>, which were abused<br>
for DOS-style attacks to extort or confuse users.<br>
<br>
<br>
  Security Ecosystem<br>
<br>
Our *Bug Bounty program* is getting a lot of love in 2020, and we kicked<br>
it off with two improvements in 2019: we significantly increased<br>
_payments in the Mozilla Web Security Bounty Program_<br>
<<a href="https://blog.mozilla.org/security/2019/11/19/updates-to-the-mozilla-web-security-bounty-program/" rel="noreferrer" target="_blank">https://blog.mozilla.org/security/2019/11/19/updates-to-the-mozilla-web-security-bounty-program/</a>><br>
and we created a static analysis bounty, _adding CodeQL and clang to our<br>
Bug Bounty Program_<br>
<<a href="https://blog.mozilla.org/security/2019/11/14/adding-codeql-and-clang-to-our-bug-bounty-program/" rel="noreferrer" target="_blank">https://blog.mozilla.org/security/2019/11/14/adding-codeql-and-clang-to-our-bug-bounty-program/</a>>.<br>
<br>
As part of encouraging more participation in the Bug Bounty program,<br>
we’re also working to provide walkthroughs that help people get<br>
involved. We published _two_<br>
<<a href="https://frederik-braun.com/firefox-ui-xss-leading-to-rce.html" rel="noreferrer" target="_blank">https://frederik-braun.com/firefox-ui-xss-leading-to-rce.html</a>> _blog<br>
articles_<br>
<<a href="https://blog.mozilla.org/security/2019/12/02/help-test-firefoxs-built-in-html-sanitizer-to-protect-against-uxss-bugs/" rel="noreferrer" target="_blank">https://blog.mozilla.org/security/2019/12/02/help-test-firefoxs-built-in-html-sanitizer-to-protect-against-uxss-bugs/</a>><br>
specifically about the built-in HTML Sanitizer, where and how we rely on<br>
it, and how to get set up for testing it for bypasses in an iterative<br>
fashion in less than 30 seconds.<br>
<br>
The _MOSS Program_ <<a href="https://www.mozilla.org/en-US/moss/" rel="noreferrer" target="_blank">https://www.mozilla.org/en-US/moss/</a>> funds<br>
development of open source software through grants; and also provides<br>
funding for security audits. Typically these happen in the background<br>
but every once in a while we discover something particularly impactful,<br>
like _this Critical Security Issue identified in iTerm2._<br>
<<a href="https://blog.mozilla.org/security/2019/10/09/iterm2-critical-issue-moss-audit/" rel="noreferrer" target="_blank">https://blog.mozilla.org/security/2019/10/09/iterm2-critical-issue-moss-audit/</a>><br>
<br>
The *Mozilla Security Engineering University Relationship Framework*<br>
(_SURF_ <<a href="https://surf.mozilla.org/" rel="noreferrer" target="_blank">https://surf.mozilla.org/</a>>) initiative hosted two conferences<br>
in 2019, in _San Franscisco in May_<br>
<<a href="https://surf.mozilla.org/events/2019/sf/" rel="noreferrer" target="_blank">https://surf.mozilla.org/events/2019/sf/</a>> and in _Vienna in November_<br>
<<a href="https://surf.mozilla.org/events/2019/vienna/" rel="noreferrer" target="_blank">https://surf.mozilla.org/events/2019/vienna/</a>>.<br>
<br>
Steven Englehardt and Marshall Erwin _published the first release_<br>
<<a href="https://blog.mozilla.org/security/2019/01/28/defining-the-tracking-practices-that-will-be-blocked-in-firefox/" rel="noreferrer" target="_blank">https://blog.mozilla.org/security/2019/01/28/defining-the-tracking-practices-that-will-be-blocked-in-firefox/</a>><br>
of our _anti-tracking policy_<br>
<<a href="https://wiki.mozilla.org/Security/Anti_tracking_policy" rel="noreferrer" target="_blank">https://wiki.mozilla.org/Security/Anti_tracking_policy</a>>.<br>
<br>
Wayne Thayer announced _version 2.7 of the Mozilla Root Store Policy_<br>
<<a href="https://blog.mozilla.org/security/2019/12/11/announcing-version-2-7-of-the-mozilla-root-store-policy/" rel="noreferrer" target="_blank">https://blog.mozilla.org/security/2019/12/11/announcing-version-2-7-of-the-mozilla-root-store-policy/</a>>.<br>
<br>
As a reaction to the _MitM attacks by the Kazakhstan Government_<br>
<<a href="https://censoredplanet.org/kazakhstan" rel="noreferrer" target="_blank">https://censoredplanet.org/kazakhstan</a>> using a custom root certificate,<br>
Firefox, in joint action with Google Chrome, _blocked the use of the<br>
Kazakhstan root certificate_<br>
<<a href="https://blog.mozilla.org/security/2019/08/21/protecting-our-users-in-kazakhstan/" rel="noreferrer" target="_blank">https://blog.mozilla.org/security/2019/08/21/protecting-our-users-in-kazakhstan/</a>>.</div>