https://blog.mozilla.org/data/2020/07/16/mozilla-telemetry-in-2020-from-just-firefox-to-a-galaxy-of-data/

(This Post is for recording inside of Hubs via a laptop or desktop computer. Recording Hubs experiences from inside Virtual Reality is for another post.)

Minimum Requirements

Hardware

• A computer
• Internet connection
• Storage space to save recordings

Software

• Screen capture software
• Browser that supports Hubs

Hubs by Mozilla; the future of remote collaboration.

Accessible from a web browser and on a range of devices, Hubs allows users to meet in a virtual space and share ideas, images and files. The global pandemic is keeping us distant socially but Hubs is helping us to bridge that gap!

We’re often asked how to record your time inside of Hubs, either for a personal record or to share with others. Here I will share what has worked for me to capture usable footage from inside of a Hubs environment.

Firstly, like traditional videography, you’re going to need the appropriate hardware and software.

Hardware:

I have a need to capture footage at the highest manageable resolution and frames per second so I use a high powered desktop PC with a good graphics card and 32Gb of RAM. When I’m wearing my editor’s hat, I like to have the freedom to make precise cuts and the ability to zoom in on a particular part of the frame and still maintain image quality. However, my needs for quality  are probably higher than most people looking to capture film inside of Hubs and an average laptop is generally going to be perfectly fine to get decent shot quality.

A strong internet connection is going to be essential to ensure the avatar animations and videos in-world function smoothly on your screen. Also, a good amount of bandwidth is required if you plan on live streaming video content out of your Hubs space to platforms such as Zoom or Twitch.

This may be especially relevant during the pandemic lockdown, with increased usage/burden on home internet.

Next up is storage to record your video. I use a 5TB external hard drive as my main storage device to ensure I never run out of space. A ten minute video that is 1280x720 and 30fps is roughly about 1Gb of data so it can add up pretty quickly!

One last piece of hardware I use but is not essential is a good gaming mouse. This offers better tracking and response time, allowing for more accurate cursor control and ultimately smoother camera movement inside of Hubs.

Another benefit I gain is customizability. Adjusting tracking sensitivity and adding macro commands to the additional buttons has greatly improved my experience recording inside of Hubs.

Now that we have the hardware, let’s talk about software.

Software:

OBS (Open Broadcast Software) is open source and also free! This application allows video recording and live streaming and is a popular choice for capturing and sharing your streams. This is a great piece of software and allows you full control over both your incoming and outgoing video streams.

My need for the highest available capture has led me to use Nvidia’s Geforce experience software. This is an application that complements my Geforce GTX graphics card and gives me the ability to optimize my settings.

So now that we’re up to speed with the hardware and software, it’s time to set up for recording.

As I mentioned earlier, I set up my software to get the best results possible from my hardware. The settings you choose will be dependent on your hardware and may take some experimentation to perfect. I tend to run my settings at 1920x1080 and 60fps. It’s good practice to run with commonly used resolution scales and frames per second to make editing, exporting and sharing as painless as possible. 1280x720 @ 30fps is a common and respectable setting.

These frame sizes have a 16:9 aspect ratio which is a widely used scale.

Audio is pretty straightforward: 44.1kHz is a good enough sample rate to get a usable recording. The main things to note are the spatial audio properties from avatars speaking and objects with audio attached inside of Hubs. Finding a position that allows for clean and balanced sound is important. It can also be handy to turn off sound effects from the preferences menu. That way if it’s a chat-heavy environment, the bubble sounds don’t interrupt the speaker in the recording. Another option to isolate the speaker’s audio is to have the camera avatar mute everyone else manually before recording.

Before I hit record there are a few other things I like to set up. One is maximizing my window in the browser settings (Not

Many of us spend multiple hours a day using the internet to do everyday things like watching videos, shopping, gaming and paying bills, all the way to managing complex work … Read more

The post No-judgment digital definitions: VPNs explained appeared first on The Firefox Frontier.

https://blog.mozilla.org/firefox/vpns-explained/

https://blog.mozilla.org/blog/2020/07/15/mozilla-puts-its-trusted-stamp-on-vpn/

If you use Treeherder on repositories that are not Try, you might have used the backfill action. The backfill action takes a selected task and schedules it nine pushes back from the selected task. You can see the original work here and the follow up here.

In the screenshot above you can see that the task mdaturned orange (implying that it failed). In the screenshot we can see that a Mozilla code sheriff has both retriggered the task four more times (you can see four more running tasks on the same push) and has backfilled the task on previous pushes. This is to determine if the regression was introduced on previous pushes or if the failure is due to an intermittent test failure.

The difference with the old backfill action is threefold:

1. The backfilled tasks include -bk in their symbol and group and it includes the revision of the originating task that was backfilled
2. The backfilled tasks schedule the same set of manifests as the starting task
3. The backfill action schedules a support action called backfill-task

Modified symbol for backfilled tasks

The modified symbol and group name for backfilled tasks is to:

1. Show that it is a backfilled task (rather than schedule by normal scheduling) and that it can have a modified set of manifests (see next section)
2. Show from which task it was backfilled from (by including the revision)
3. Group backfilled tasks together to make it clear that they were not scheduled by normal means

I’ve also landed a change on Treeherder to handle this new naming and allow to filter out normal tasks plus backfilled tasks.

Manifest-level backfilling

Point number two from the above list is what changes the most. Soon we will be landing a change on autoland that will schedule some test tasks with a dynamic set of manifests. This means that a task scheduled on push A will have a set of manifests (e.g. set X) and the same task on push B can have a different set of manifests (e.g. set Y).

The new backfill takes this into account by looking at the env variable MOZHARNESS_TEST_PATHS which contains the list of manifests and re-uses that value on backfilled tasks. This ensures that we’re scheduling the same set of manifests in every backfilled task.

Support actions

You can skip reading this section as this is more of an architectural change. This fixes the issue that backfilled tasks could not be re-run.

Backfilled tasks are now scheduled by a support action called backfill-task. If on Treeherder we filter by backfill tasks you can see both the initial backfillaction and the backfill-tasksupport action:

The action backfill has scheduled nine backfill-task and those are in charge of scheduling the mda task on that push.

Thanks for reading. Please file a bug and CC me if you notice anything going wrong with it.

http://feedproxy.google.com/~r/armenzg_mozilla/~3/ubpJL9Ftid0/new-backfill-action-26788d0db81a

Rapha"el gets a second gold star for noticing that the gcc runtime we include with every copy of TenFourFox (because we build with a later compiler) is not itself optimized for the underlying platform, because MacPorts simply builds it for ppc rather than one of the specific subtypes. So he built four sets of runtime libraries for each platform and I've integrated it into the build system so that each optimized build now uses a C/C++ runtime tuned for that specific processor family (the debug build is still built for generic ppc so it runs on anything). This is not as big an improvement as you might think because JavaScript performance is almost overwhelmingly dominated by the JIT, and as I mentioned, JavaScript is one of the few areas TenFourFox has tuned and tested to hell. But other things such as DOM, graphics, layout and such do show some benefit, and scripts that spend more time in the interpreter than the JIT (primarily short one-offs) do so as well. There are no changes in the gcc runtime otherwise and it's still the same code, just built with better flags.

This release also includes additional hosts for adblock and additional fonts for the ATSUI font blocklist, and will have the usual security updates as well. It will come out parallel with Firefox 68.11 on or about July 28.

http://tenfourfox.blogspot.com/2020/07/tenfourfox-fpr25b1-available.html

I wanted to play with the WireViz Python package, which makes pretty wire diagrams. Installation was pretty easy, just created a virtualenv and installed with pip:

pip install wireviz

Documentation is pretty limited, but looking through the tutorials and the data models you get a pretty good idea of what …

https://patrick.cloke.us/posts/2020/07/14/testing-wireviz/

Hello and welcome to another issue of This Week in Rust! Rust is a systems language pursuing the trifecta: safety, concurrency, and speed. This is a weekly summary of its progress and community. Want something mentioned? Tweet us at @ThisWeekInRust or send us a pull request. Want to get involved? We love contributions.

This Week in Rust is openly developed on GitHub. If you find any errors in this week's issue, please submit a PR.

Check out this week's This Week in Rust Podcast

Updates from Rust Community

News & Blog Posts

• Announcing Rustup 1.22.1
• Lang team design meeting: path to membership
• Perspective on Rust Community Moderation
• Programming Servo: the bird’s-eyes view
• Faster Integer Parsing (Rust port)
• Learning Rust: Let's Build a Parser
• nnnoiseless: porting audio code from C to rust
• The Soul of a New Debugger
• String interners in Rust
• Target Feature vs Target CPU for Rust
• Rust and it's Orphan Rules
• Async Interview #8: Stjepan Glavina
• Using RabbitMQ in Rust
• Creating a custom target
• Statically Sized Higher-kinded Polymorphism
• Getting in and out of trouble with Rust futures
• Rust Analyzer Changelog #33
• IntelliJ Rust Changelog #126
• This Month in Rust OSDev (June 2020)
• Cross-compiling Rust from ARM to x86-64
• Writing Rust NIFs for Elixir With Rustler
• Geometric Constraint Solvers Part 1: Algebraic Expressions
• A View of Async Memory Access in Rust
• Building Canrun: A Statically Typed Logic Programming Library for Rust (Part 1)
• Hunting down a non-determinism-bug in our Rust Wasm build
• Implementing the Clipper Chip Cipher in Rust
• Linux Developers

This is a cross-post of the official security advisory. The official post contains a signed version with our PGP key, as well.

The Rust Security Response Working Group was recently notified of a security issue affecting token generation in the crates.io web application, and while investigated that issue we discovered an additional vulnerability affecting crates.io API tokens.

We have no evidence of this being exploited in the wild, but out of an abundance of caution we opted to revoke all existing API keys. You can generate a new one at crates.io/me.

Overview

Until recently, API keys for crates.io were generated using the PostgreSQL random function, which is not a cryptographically secure random number generator. This means that in theory, an attacker could observe enough random values to determine the internal state of the random number generator, and use this information to determine previously created API keys up to the last database server reboot.

As part of the investigation for this, we also found that API keys were being stored in plain text. This would mean if our database were somehow compromised the attacker would be have API access for all current tokens.

Mitigations

We deployed a code change to production to use a cryptographically secure random number generator, and we implemented hashing for storing tokens in the database.

Exploiting either issue would be incredibly impractical in practice, and we've found no evidence of this being exploited in the wild. However, out of an abundance of caution, we've opted to revoke all existing API keys. You can generate a new API key by visiting crates.io/me. We apologize for any inconvenience this causes.

Acknowledgements

Thanks to Jacob Hoffman-Andrews for responsibly disclosing the random number generator issue according to our security policy. Thanks to Si^an Griffin and Justin Geibel from the crates.io team for helping the Security Response WG addressing both of the issues. Thanks to Pietro Albini from the Security Response WG for coordinating the work on this vulnerability.

Timeline of events

All times are listed in UTC.

• 2020-07-11 17:43 - The issue is reported to security@rust-lang.org
• 2020-07-11 20:56 - The issue is acknowledged, the leads of the crates.io team are looped in
• 2020-07-11 23:48 - The issue is confirmed and a planned fix is agreed on
• 2020-07-13 08:00 - The development of the fix is started
• 2020-07-14 12:53 - The fix is tested on the staging environment
• 2020-07-14 19:03 - The fix is deployed, existing tokens are revoked, and the issue is disclosed publicly

https://blog.rust-lang.org/2020/07/14/crates-io-security-advisory.html

https://mikeconley.ca/blog/2020/07/13/improving-firefox-startup-time-with-the-abouthome-startup-cache/

https://mikeconley.ca/blog/2020/07/13/improving-firefox-startup-time-with-the-abouthome-startup-cache/

https://blog.mozilla.org/blog/2020/07/13/password-security-part-ii/

As many web platform developer and Firefox users, I believe Mozilla’s mission is instrumental for a better Internet. In a recent Igalia’s chat about the Web Ecosystem Health, participants made the usual observation regarding this important role played by Mozilla on the one hand and the limited development resources and small Firefox’s usage share on the other hand. In this blog post, I’d like to explain an experimental idea we are launching at Igalia to try and make browser development better match the interest of the web developer and user community.

[750x255]

Igalia’s contribution to browser repositories

As mentioned in the past in this blog, Igalia has contributed to different part of Firefox such as multimedia (e.g.

Although commit count is an imperfect metric it is also one of the easiest to obtain. Let’s take a look at how Igalia’s commits repositories of the Chromium (chromium, v8), Mozilla (mozilla-central, servo, servo-web-render) and WebKit projects were distributed last year:

[374x305]

As you can see, in absolute value Igalia contributed roughly 3/4 to Chromium, 1/4 to WebKit, with a small remaining amount to Mozilla. This is not surprising since Igalia is a consulting company and our work depends on the importance of browsers in the market where Chromium dominates and WebKit is also quite good for iOS devices and embedded systems.

This suggests a different way to measure our contribution by considering, for each project, the percentage relative to the total amount of commits:

[436x339]

In the WebKit project, where ~80% of the contributions were made by Apple, Igalia was second with ~10% of the total. In the Chromium project, the huge Google team made more than 90% of the contributions and many more companies are involved, but Igalia was second with about 4% of the total. In the Mozilla project, Mozilla is also doing ~90% of the contributions but Igalia only had ~0.5% of the total. Interestingly, the second contributing organization was… the community of unindentified gmail.com addresses! Of course, this shows the importance of volunteers in the Mozilla project where a great effort is done to encourage participation.

Open Prioritization

From the commit count, it’s clear Igalia is not contributing as much to the Mozilla project as to Chromium or WebKit projects. But this is expected and is just reflecting the priority set by large companies. The solid base of Firefox users as well as the large amount of volunteer contributors show that the Mozilla project is nevertheless still attractive for many people. Could we turn this into browser development that is not funded by advertising or selling devices?

Another related question is whether the internet can really be shaped by the global community as defended by the Mozilla’s mission? Is the web doomed to be controlled by big corporations doing technology’s “evangelism” or lobbying at standardization committees? Are there prioritization issues that can be addressed by moving to a more collective decision process?

At Igalia, we internally try and follow a more democratic organization and, at our level, intend to make the world a better place. Today, we are launching a new Open Prioritization experiment to verify

Previous options of the week.

--silent (-s) existed in curl already in the first ever version released: 4.0.

Silent by default

I’ve always enjoyed the principles of Unix command line tool philosophy and I’ve tried to stay true to them in the design and implementation of the curl command line tool: everything is a pipe, don’t “speak” more than necessary by default.

As a result of the latter guideline, curl features the --verbose option if you prefer it to talk and explain more about what’s going on. By default – when everything is fine – it doesn’t speak much extra.

Initially: two things were “spoken”

To show users that something is happening during a command line invoke that takes a long time, we added a “progress meter” display. But since you can also ask curl to output text or data in the terminal, curl has logic to automatically switch off the progress meter display to avoid content output to get mixed with it.

Of course we very quickly figured out that there are also other use cases where the progress meter was annoying so we needed to offer a way to shut it off. To keep silent! --silent was the obvious choice for option name and -s was conveniently still available.

The other thing that curl “speaks” by default is the error message. If curl fails to perform the transfer or operation as asked to, it will output a single line message about it when it is done, and then return an error code.

When we added an option called --silent to make curl be truly silent, we also made it hush the error message. curl still returns an error code, so shell scripts and similar environments that invoke curl can still detect errors perfectly fine. Just possibly slightly less human friendly.

But I want my errors?

In May 1999, the tool was just fourteen months old, we added --show-error (-S) for users that wanted to curl to be quiet in general but still wanted to see the error message in case it failed. The -Ss combination has been commonly used ever since.

More information added

Over time we’ve made the tool more complex and we’ve felt that it needs some more informational output in some cases. For example, when you use --retry, curl will say something that it will try again etc. The reason is of course that --verbose is really verbose so its not really the way to ask for such little extra helpful info.

Only shut off the progress meter

Not too long ago, we ended up with a new situation where the --silent option is a bit too silent since it also disables the text for retry etc so what if you just want to shut off the progress meter?

--no-progress-meter was added for that, which thus is a modern replacement for --silent in many cases.

https://daniel.haxx.se/blog/2020/07/13/curl-ootw-silent/

Sustainability is not just about ticking a few boxes by getting your Greenhouse Gas emissions (GHG) inventory, adopting goals for reduction and mitigation, and accounting in shape. Any transformation towards sustainability also needs culture change.

In launching Mozilla‘s Sustainability Programme, our Environmental Champions are a key part of driving this organisational culture change.

Recruiting, training, and working with a first cohort of Environmental Champions has been a highlight of my job in the last couple of months. I can’t wait to see their initiatives taking root across all parts of Mozilla.

We have 14 passionate and driven individuals in this first cohort. They are critical amplifiers who will nudge each and every one us to incorporate sustainability into everything we do.

What makes people Champions?

“We don’t need hope, we need courage: The courage to change and impact our own decisions.”

This was among the top take-aways of our initial level-setting workshop on climate change science. In kicking off conversations around how to adjust our everyday work at Mozilla to a more sustainability-focused mindset, it was clear that hope won’t get us to where we need to be. This will require boldness and dedication.

Our champions volunteer their time for this effort. All of them have full-time roles and it was important to structure this process so that it is inviting, empowering, and impactful. To me this meant ensuring manager buy-in and securing executive sponsorship to make sure that our champions have the support to grow professionally in their sustainability work.

In the selection of this cohort, we captured the whole breadth of Mozilla: representatives from all departments, spread across regions, including office as well as remote workers, people with different tenure and job levels, and a diversity in roles. Some are involved with our GHG assessment, others are design thinkers, engineers, or programme managers, and yet others will focus on external awareness raising.

Responsibilities and benefits

In a nutshell, we agreed on these conditions:

Environmental Champions are:

• Engaged through a peer learning platform with monthly meetings for all champions, including occasional conversations with sustainability experts. We currently alternate between four time zones, starting at 8am CEST (UTC+2), CST (UTC+8), EDT (UTC-4), PDT (UTC-7), respectively to equally spread the burden of global working hours.
• Committed to spend about 2-5h each month supporting sustainability efforts at Mozilla.
• Committed to participate in at least 1 initiative a year.
• Committed to regularly share initiatives they are driving or participating in.
• Dedicated to set positive examples and highlight sustainability as a catalyst of innovation.
• Set up to provide feedback in their teams/departments, raise questions and draw attention to sustainability considerations.

The Sustainability team:

• Provides introductory training on climate science and how to incorporate it into our everyday work at Mozilla. Introductory training will be provided at least once a year or as soon as we have a critical mass of new champions joining us on this journey.
• Commits to inviting champions for initial feedback on new projects, e.g. sustainability policy, input on reports, research to be commissioned.
• Regularly amplifies progress and successes of champions’ initiatives to wider staff.
• May offer occasional access to consultants, support for evangelism (speaking, visibility, support for professional development) or other resources, where necessary and to the extent possible.

Curious about their initiatives?

We are just setting out and we already have a range of ambitious, inspiring projects lined up.

Sharmili, our Global Space Planner, is not only gathering necessary information around the impact of our global office spaces, she will also be leading on our reduction targets for real estate and office supplies. She puts it like this: “Reducing our Real Estate Footprint and promoting the 3 R’s (reduce, reuse, recycle) is as straight-forward as it can be tough in practice. We’ll make it happen either way.”

Ian, a machine learning engineer, is looking at Pocket recommendation guidelines and is keen to see more collections like this Earth Day 2020 one in the future.

Daria, Head of Product Design in Emerging Technologies, says: “There are many opportunities for designers to develop responsible technologies and to bring experiences that prioritize

Bonjour `a tous et `a toutes, this is episode 53 of your favorite and only Firefox graphics newsletter. From now on instead of peeling through commit logs, I will be simply gathering notes sent to me by the rest of the team. This means the newsletter will be shorter, hopefully a bit less overwhelming with only the juicier bits. It will also give yours-truly more time to fix bugs instead of writing about it.

Lately we have been enabling WebRender for a lot more users. For the first time, WebRender is enabled by default in Nightly for Windows 7 and macOS users with modern GPUs. Today 78% of Nightly users have WebRender enabled, 40% on beta, and 22% on release. Not all of these configurations are ready to ride the trains yet, but the numbers are going to keep going up over the next few releases.

WebRender

WebRender is a GPU based 2D rendering engine for the web written in Rust, currently powering Firefox‘s rendering engine as well as Mozilla’s research web browser Servo.

Ongoing work

• Part of the team is now focusing on shipping WebRender on some flavors of Linux as well.
• Worth highlighting also is the ongoing work by Martin Str'ansk'y and Robert Madder to switch Firefox on Linux from GLX to EGL. EGL is a more modern and better supported API, it will also let us share more code between Linux and Android.
• Lee and Jim continue work on WebRender’s software backend. It has had a bunch of correctness improvements, works properly on Windows now and has more performance improvements in the pipeline. It works on all desktop platforms and can be enabled via the pref “gfx.webrender.software”.

Performance

One of the projects that we worked on the last little while has been improving performance on lower-end/older Intel GPUs.

• Glenn fixed a picture caching issue while scrolling gmail
• Glenn fixed some over-invalidation on small screen resolutions.
• Glenn reduced extra invalidation some more.
• Dzmitry switched WebRender to a different CPU-to-GPU transfer strategy on Intel hardware on Windows. This avoid stalls during rendering.

Some other performance improvements that we made are:

• Nical reduced CPU usage by re-building the scene a lot less often during scrolling.
• Nical removed a lot of costly vector reallocation during scene building.
• Nical reduced the amount of synchronous queries submitted to the X server on Linux, removing a lot of stalls when the GPU busy.
• Nical landed a series of frame building optimizations.
• Glenn improved texture cache eviction handling. This means lower memory usage and better performance.
• Jeff enabled GPU switching for WebRender on Mac in Nightly. Previously WebRender only used the GPU that Firefox was started with. If the GPU was switched Firefox would have very bad performance because we would be drawing with the wrong GPU.
• Markus finished and preffed on the OS compositor configuration of WR on macOS, which uses CoreAnimation for efficient scrolling.

Driver bugs

• Dzmitry worked around a driver bug causing visual artifacts in Firefox’s toolbar on Intel Skylake and re-enabled direct composition on these configurations.

Desktop zooming

• Botond

Over the last three plus years, Julie Hanna has brought extensive experience on innovation processes, global business operations, and mission-driven organizations to her role as a board member of Mozilla Corporation. We have deeply appreciated her contributions to Mozilla throughout this period, and thank her for her time and her work with the board.

Julie is now stepping back from her board commitment at Mozilla Corporation to focus more fully on her longstanding passion and mission to help pioneer and bring to market technologies that meaningfully advance social, economic and ecological justice, as evidenced by her work with Kiva, Obvious Ventures and X (formerly Google X), Alphabet’s Moonshot Factory. We look forward to continuing to see her play a key role in shaping and evolving purpose-driven technology companies across industries.

We are actively looking for a new member to join the board and seeking candidates with a range of backgrounds and experiences.

The post Thank you, Julie Hanna appeared first on The Mozilla Blog.

https://blog.mozilla.org/blog/2020/07/09/thank-you-julie-hanna/

Mozilla, Atlassian, and Shopify yesterday filed a friend-of-the-court brief in Van Buren v. U.S. asking the U.S. Supreme Court to consider implications of the Computer Fraud and Abuse Act for online security and privacy.

Mozilla’s involvement in this case comes from our interest in making sure that the law doesn’t stand in the way of effective online security. The Computer Fraud and Abuse Act (CFAA) was passed as a tool to combat online hacking through civil and criminal liability. However, over the years various federal circuit courts have interpreted the law so broadly as to threaten important practices for managing computer security used by Mozilla and many others. Contrary to the purpose of the statute, the lower court’s decision in this case would take a law meant to increase security and interpret it in a way that undermines that goal.

System vulnerabilities are common among even the most security conscious platforms. Finding and addressing as many of these vulnerabilities as possible relies on reporting from independent security researchers who probe and test our network. In fact, Mozilla was one of the first to offer a bug bounty program with financial rewards specifically for the purpose of encouraging external researchers to report vulnerabilities to us so we can fix them before they become widely known. By sweeping in pro-security research activities, overbroad readings of the CFAA discourage independent investigation and reporting of security flaws. The possibility of criminal liability as well as civil intensifies that chilling effect.

We encourage the Supreme Court to protect strong cybersecurity by striking the lower court’s overbroad statutory interpretation.

The post Laws designed to protect online security should not undermine it appeared first on Open Policy & Advocacy.

https://blog.mozilla.org/netpolicy/2020/07/09/laws-designed-to-protect-online-security-should-not-undermine-it/

Firefox 79, which will be released on July 28, includes changes to the storage.sync area. Items that extensions store in this area are automatically synced to all devices signed in to the same Firefox Account, similar to how Firefox Sync handles bookmarks and passwords. The storage.sync area has been ported to a new Rust-based implementation, allowing extension storage to share the same infrastructure and backend used by Firefox Sync.

Extension data that had been stored locally in existing profiles will automatically migrate the first time an installed extension tries to access storage.sync data in Firefox 79. After the migration, the data will be stored locally in a new storage-sync2.sqlite file in the profile directory.

If you are the developer of an extension that syncs extension storage, you should be aware that the new implementation now enforces client-side quota limits. This means that:

• You can make a call using storage.sync.GetBytesInUse to estimate how much data your extension is storing locally over the limit.
• If your extension previously stored data above quota limits, all that data will be migrated and available to your extension, and will be synced. However, attempting to add new data will fail.
• If your extension tries to store data above quota limits, the storage.sync API call will raise an error. However, the extension should still successfully retrieve existing data.

We encourage you to use the Firefox Beta channel to test all extension features that use the storage.sync API to see how they behave if the client-side storage quota is exceeded before Firefox 79 is released. If you notice any regressions, please check your about:config preferences to ensure that webextensions.storage.sync.kinto is set to false and then file a bug. We do not recommend flipping this preference to true as doing so may result in data loss.

If your users report that their extension data does not sync after they upgrade to Firefox 79, please also file a bug. This is likely related to the storage.sync data migration.

Please let us know if there are any questions on our

We intend to update Mozilla’s Root Store Policy to reduce the maximum lifetime of TLS certificates from 825 days to 398 days, with the aim of protecting our user’s HTTPS connections. Many reasons for reducing the lifetime of certificates have been provided and summarized in the CA/Browser Forum’s Ballot SC22. Here are Mozilla’s top three reasons for supporting this change.

1. Agility

Certificates with lifetimes longer than 398 days delay responding to major incidents and upgrading to more secure technology. Certificate revocation is highly disruptive and difficult to plan for. Certificate expiration and renewal is the least disruptive way to replace an obsolete certificate, because it happens at a pre-scheduled time, whereas revocation suddenly causes a site to stop working. Certificates with lifetimes of no more than 398 days help mitigate the threat across the entire ecosystem when a major incident requires certificate or key replacements. Additionally, phasing out certificates with MD5-based signatures took five years, because TLS certificates were valid for up to five years. Phasing out certificates with SHA-1-based signatures took three years, because the maximum lifetime of TLS certificates was three years. Weakness in hash algorithms can lead to situations in which attackers can forge certificates, so users were at risk for years after collision attacks against these algorithms were proven feasible.

2. Limit exposure to compromise

Keys valid for longer than one year have greater exposure to compromise, and a compromised key could enable an attacker to intercept secure communications and/or impersonate a website until the TLS certificate expires. A good security practice is to change key pairs frequently, which should happen when you obtain a new certificate. Thus, one-year certificates will lead to more frequent generation of new keys.

3. TLS Certificates Outliving Domain Ownership

TLS certificates provide authentication, meaning that you can be sure that you are sending information to the correct server and not to an imposter trying to steal your information. If the owner of the domain changes or the cloud service provider changes, the holder of the TLS certificate’s private key (e.g. the previous owner of the domain or the previous cloud service provider) can impersonate the website until that TLS certificate expires. The Insecure Design Demo site describes two problems with TLS certificates outliving their domain ownership:

• “If a company acquires a previously owned domain, the previous owner could still have a valid certificate, which could allow them to MitM the SSL connection with their prior certificate.”
• “If a certificate has a subject alt-name for a domain no longer owned by the certificate user, it is possible to revoke the certificate that has both the vulnerable alt-name and other domains. You can DoS the service if the shared certificate is still in use!”

The change to reduce the maximum validity period of TLS certificates to 398 days is being discussed in the CA/Browser Forum’s Ballot SC31 and can have two possible outcomes:

     a) If that ballot passes, then the requirement will automatically apply to Mozilla’s Root Store Policy by reference.

     b) If that ballot does not pass, then we intend to proceed with our regular process for updating Mozilla’s Root Store Policy, which will involve discussion in mozilla.dev.security.policy.

In preparation for updating our root store policy, we surveyed all of the certificate authorities (CAs) in our program and found that they all