Mozilla Nederland LogoDe Nederlandse

Mozilla GFX: WebRender newsletter #6

Mozilla planet - ma, 02/10/2017 - 18:30

Hi there, the 6th newsletter has arrived. Without further ado:

Notable WebRender changes
  • Glenn fixed rounded clips on rotated rectangles.
  • Glenn reduced the GPU allocations for intermediate render targets.
  • Glenn added color emoji support on mac.
  • Glenn fixed some of the filters to work with pre-multiplied alpha.
Notable Gecko changes
  • Kats, Ethan, Morris and Peter made Layers-free the default now.
  • Continuous repainting has been solved. This previously caused WebRender to get into a mode where it was always repainting which would ruin battery life.
  • Kats enabled rendering background-image with WebRender by default.
  • Michael converted nsDisplaySolidColorRegion to WebRender display items.
  • Nical improved the allocation of video frames (improves memory usage and reduce the CPU time spent re-building scenes in WebRender).
  • Morris landed support for the backface-visibilty property.

Categorieën: Mozilla-nl planet

Firefox Test Pilot: Kicking the tires on A/B testing

Mozilla planet - ma, 02/10/2017 - 17:53

We just concluded our first A/B test on Firefox Send and we’d like to share our results. This being our first test we wanted to start with something super simple just to get comfortable with the tools and reporting. To be totally honest the change we ended up making was so minor, in my mind, that I didn’t expect to learn anything interesting and fully expected both the control group and experiment group to show nearly identical behavior. Annoyingly, I did end up learning a few things.

The Experiment

We wanted to see if we could increase our upload rate with a tweak to the UI. Here’s what the original, control group, page looks like…

We made a slight change to two styles on the main page. We increased the thickness of the dotted line border around the file drop area and made the file selection button slightly bigger with bolder text. The hypothesis was that the increased “beefiness” of these elements would make it easier for folks to notice what to do next, thereby increasing the rate they successfully upload a file versus just leaving the page. Here’s the experiment UI…

We use Google Analytics (GA) to run our experiments and to collect anonymous usage statistics to help guide us in improving the service so I want to take a moment to explain how we try to use it respectfully. We keep a list of all the types of events and data we gather, limiting what we collect to things directly helpful to improving the service. If you’re opposed to sharing this data with us the easiest way to opt-out is to use Send in Private Browsing Mode. We also respect the Do Not Track (DNT) browser setting. Consequently, doing so will also exclude you from experiments like this one. We care about making our products better but we also care about your privacy.

We launched this experiment on September 13th, but due to a configuration snafu on my part we didn’t start getting good data until the 14th. This was one of the minor annoyances with setting up, and getting used to, GA’s version of A/B experiments. It takes about a day to see any new data so it took a day to notice the mistake and correct it. Once the experiment was running smoothly the rest was mostly just a waiting game to see how each variant performed.

The Results

Early results showed the Beefy variant outperforming the control by a fairly significant margin but by the end they were performing pretty close to the same in terms of visit to upload conversion rate. The lesson here is to not declare a winner too soon.

Overall the Beefy UI had a conversion rate of 37.47% compared to the original at 36.18%, a 3.58% increase. Not mind-blowing but respectable.

In addition we used Data Studio to analyze some other behavior. The most interesting to me was the method of upload, being either drag & drop or a click on the button.

In the first few days of the experiment Beefy had a 14% increase in drag & drop compared to the control. Over time, as with the upload conversion rate, it started to even out, but it maintained about a 4% increase at the end. From a conversion standpoint it doesn’t matter how users are choosing to upload, but it is interesting that the change in the border thickness that I thought was barely noticeable even side-by-side, actually had a measurable effect. Small changes can make a difference.


Since Beefy performed slightly better we’ll be using it as the default UI in our next release. We learned a bit about our tools, our workflow, and our users. We plan on doing some more, and more exciting, experiments in the near future and are excited to see what we learn and to share our progress with y’all.

Kicking the tires on A/B testing was originally published in Firefox Test Pilot on Medium, where people are continuing the conversation by highlighting and responding to this story.

Categorieën: Mozilla-nl planet

Asa Dotzler: Some of the Press Coverage of Firefox 57 Beta (Quantum)

Mozilla planet - ma, 02/10/2017 - 01:46

Firefox takes a Quantum leap forward with new developer edition  by Peter Bright at Ars Technica

Firefox 57 beta arrives with major visual overhaul and next-generation browser engine by Emil Protalinski at VentureBeat

Mozilla release Firefox 57 beta (Quantum): It’s 2x faster than Firefox 52 by Brad Linder at Liliputing

Mozilla’s Firefox Quantum browser is ridiculously fast by Matthew Hughes at TNW

Mozilla announces Firefox Quantum, the next major update with new UI and huge performance improvements by Pradeep at MSPoweruser

Mozilla Gives Firefox a ‘Quantum’ Speed Boost by Angela Moscaritolo at PCMag

Firefox Quantum challenges Chrome in browser speed by Stephen Shankland at CNET

New Firefox Beta Released With New User Interface, New Core Engine by Catalin Cimpanu at BleepingComputer

Firefox Announces New ‘Quantum’ Browser With 2X Faster Speeds, Coming November 14 by Mitchel Broussard at MacRumors

Firefox Quantum Next Generation Web Browser Launches November 14, Beta Out Now by Marius Nestor at Softpedia News

Mozilla Firefox 57 rebranded as Firefox Quantum by Paul Hill at

Download the super-speedy Firefox Quantum beta today by Cat Ellis at TechRadar

Firefox 57 Hits Beta, is Renamed to Firefox Quantum by Paul Thurrott at

Mozilla’s Firefox Quantum next-generation browser is ready for you to try out by Mark Hachman at PCWorld

‘Project Quantum’ Doubles Firefox’s Performance In Latest Beta by Lucian Armasu at Tom’s Hardware

Mozilla is Making a New Firefox That’s Twice as Fast by Lee Mathews at Forbes

Mozilla whips out Rusty new Firefox Quantum (and that’s a good thing) by Shaun Nichols at The Register

Firefox Quantum is the latest browser to challenge Google Chrome  by Jacob Siegal at BGR

Firefox Quantum beta promises to double your browser speeds by Rachel England at Engadget

Mozilla: Firefox 57 is so fast we’re calling it Firefox Quantum by Liam Tung at ZDNet

Mozilla Accelerates Firefox 57 with Quantum Speed Boost by Sean Michael Kerner at eWeek

Mozilla previews its faster ‘Firefox Quantum’ browser by Gregg Keizer at Computerworld

Loyal to Google Chrome? Firefox Quantum might change that. by Monica Chin at Mashable

You Can Now Try the New Firefox Quantum Beta by Dave Parrack at MakeUseOf

Faster and even more minimalist, Firefox Quantum makes Chrome look old by Jayce Wagner at Digital Trends

It’s time to give Firefox another chance by Frederic Lardinois at TechCrunch

Categorieën: Mozilla-nl planet

Asa Dotzler: Some Nice Things People Said About Firefox 57 Beta (Quantum)

Mozilla planet - ma, 02/10/2017 - 00:48

“Super impressed by @firefox quantum. I’ve been using it for a few days now and I’m switching permanently. Noticeably faster than Chrome.” Erik Reppel

“Firefox Quantum is blazing fast! Good job, Mozilla!” Oleksandr Shpak

“Using the new Firefox beta. it is much faster then the old one. It is as fast as Chrome. maybe faster. #fb” alex

“Firefox Quantum… really is an amazing overhaul of Firefox. It is hella fast.” rrees

“Trying out Firefox 57 beta – Quantum, And its been great so far. Far better than Chrome in speed, and hardly any bugs. Thanks @mozilla” Abhishek

“Wow, very impressed by @firefox ‘s beta version speed increase. I literally just ditched Chrome just now.” Florian Monfort

“I’m not sure what @mozilla did, but Firefox Quantum is fantastic. Easily made me switch back to Firefox :-o” Chris King

“The new Firefox Quantum (57 beta) is really nice, good job @mozilla. I think I might like it better than Chrome first time in a decade.” Axel Gneiting

“@mozilla i am using the latest firefox developer version quantum and has to say its just awesome very smooth in performance. HATS OFF TO U” Manhar sodhi

“I mostly moved from Firefox to Chrome about a year ago, but I’ve desperately waiting for FF Quantum to get back in… And it’s awesome!” Davide Borsatto

“Delightful experience with FF Nightly 57. Quantum + photon is love. Welcome back Firefox, you’ve been gone for too long.” Ahmad Albakri Zabri

“Anyone here using firefox quantum? It’s like a breath of fresh air, and so quick. It completely blows chrome out of the water on speed.” Jayesh M

“Been using @firefox beta on my laptop for days now! It’s one of the best browser experience ever!” Zan Cerne

“Holy shit, Firefox 57 is so much faster. Can’t wait for it to come out of beta.” Will Johansson

“After trying @firefox beta, I don’t want to go back to stable.” Saša Stamenkovic

“Just downloaded the Firefox Quantum Beta and it’s faaast. Beating the pants off Chrome right now” Tony Haile

“I know I’ve spent only one day with it so far, but the Firefox beta is quick and easy on the eyes. Might switch back to Firefox full-time” Daniel D. Beck

“So the #Firefox #quantum beta is absolutely phenomenal. I’m super excited for the full release so I can finally switch back from chrome.” David Burns

“holy shit, @firefox beta is killing me, it’s so much smoother than Chrome at almost everything” ghastly geist

“Been using the new @Firefox Quantum all day at work. Got home and tried to use Chrome, wayyyy too slow. Time to download Quantum!” Rich Burton

“Pleased with the speed and customization options in @firefox 57 beta. Got everything I want to see on screen in the tab bar and address bar.” Derrick Rossignol

“Been testing @Firefox Quantum these past few days. Cannot believe how damn fast it load web pages. Very exciting! Hopefully Chrome follows!” Jeremy Krantz


Categorieën: Mozilla-nl planet

Mozilla Open Innovation Team: Ready to Launch! Building an Open Source Student Network in the US

Mozilla planet - vr, 29/09/2017 - 17:37

In Spring 2017 Mozilla’s Open Innovation team conducted research to better understand the current state of open source on US Campuses. Through that study we discovered a high level of interest around open source but also a knowledge gap and a pressing need for well-supported, networked, informal structures that could help bring people to the open source movement that was already blossoming on campuses in the US.

Based on that research we began developing an idea that would become the Open Source Student Network. A pilot program to create and support a network of clubs on university campuses to learn about, create and contributing to open source.

In parallel to developing a website as a platform for facilitating updates, interactions and knowledge sharing, we initiated a process to structurally support club leaders. This included identifying dedicated students who were passionate about open source and excited to develop their own clubs as part of a larger network.

To find our student leaders, we worked with the Professor’s Open Source Software Experience (POSSE) to ask professors from across the country to nominated students who they thought had the leadership capabilities, passion and entrepreneurial attitude to guide and shape the launch of an open source program. After reviewing dozens of applications we identified 20 students from 7 different countries, at schools in 10 different states. 50% identified as female.

<figcaption>Students & Mentors at the first Open Source Student Leader Weekend at Drexel University</figcaption>

Learning from Mentors

On August 10th, after weeks of virtual trainings, meetings, and independent work, Mozilla’s first ever Open Source Student Leader cohort came together at Drexel University campus in Philadelphia to meet their fellow leaders face to face and to further develop the skills they’d need to bring the Open Source Student Network to their campuses in the fall. Throughout the weekend in Philadelphia, the students had the opportunity to learn from six mentors, each experts in their respective fields.

<figcaption>Katrina Owen from GitHub shares her tips for maintaining welcoming open source projects</figcaption>

These mentors ran workshops and gave talks on a series of topics designed to empower and inspire. Highlights included Don Marti, Open Innovation Experimenter at Mozilla, who had participants laughing and thinking in his presentation Why Open Source Matters that delivered an “off message”, thought provoking history of the open source movement(s) and the factors that threatened its past and its future.

As well, Emma Irwin, who leads Diversity & Inclusion for Participation at Mozilla, held a workshop on Overcoming Imposter Syndrome which guided participants through a deep examination of their own privilege and opportunities, while delivering practical advice for fostering diverse, safe spaces within a club environment.

“Each of the workshops was incredibly insightful, and in addition to the practical knowledge I gained, it was a breath of fresh air to be able to connect with other likeminded students in a safe and open environment.” — Jeffrey Qiu, UCLA

Meet The Leaders

As the school year kicks off each of these student leaders are now starting or advancing clubs on their campuses. You can learn more about the clubs and follow along with their progress on the open source student network website.

Joining the Network

If you’re a US university student with an open source or technical club who is interested in becoming a part of this network, you can register your club on the website:

Ready to Launch! Building an Open Source Student Network in the US was originally published in Mozilla Open Innovation on Medium, where people are continuing the conversation by highlighting and responding to this story.

Categorieën: Mozilla-nl planet

Chris H-C: Data Science is Hard: Dangerous Data

Mozilla planet - vr, 29/09/2017 - 15:36

I sit next to a developer at my coworking location (I’m one of the many Mozilla staff who work remotely) who recently installed the new Firefox Quantum Beta on his home and work machines. I showed him what I was working on at the time (that graph below showing how nicely our Nightly population has increased in the past six months), and we talked about how we count users.

Screenshot-2017-9-28 Desktop Nightly DAU MAU for the Last Six Months by Version

=> “But of course we’ll be counting you twice, since you started a fresh profile on each Beta you installed. Actually four times, since you used Nightly to download and install those builds.” This, among other reasons, is why counting users is hard.

<= “Well, you just have to link it to my Firefox Account and then I’ll only count as one.” He figured it’d be a quick join and then we’d have better numbers for some users.

=> “Are you nuts?! We don’t link your Firefox Account to Telemetry! Imagine what an attacker could do with that!”

In a world with adversarial trackers, advertising trackers, and ever more additional trackers, it was novel to this pseudo-coworker of mine that Mozilla would specifically not integrate its systems.

Wouldn’t it be helpful to ourselves and our partners to know more about our users? About their Firefox Accounts? About their browsing history…

Mozilla doesn’t play that game. And our mission, our policies, and our practices help keep us from accidentally providing “value” of this kind for anyone else.

We know the size of users’ history databases, but not what’s in them.

We know you’re the same user when you close and reopen Firefox, but not who you are.

We know whether users have a Firefox Account, but not which ones they are.

We know how many bookmarks users have, but not what they’re for.

We know how many tabs users have open, but not why. (And for those users reporting over 1000 tabs: WHY?!)

And even this much we only know when you let us:


Why? Why do we hamstring our revenue stream like this? Why do we compromise on the certainty that having complete information would provide? Why do we allow ourselves to wonder and move cautiously into the unknown when we could measure and react with surety?

Why do we make Data Science even harder by doing this?

Because we care about our users. We think about what a Bad Actor could do if they had access to the data we collect. Before we okay a new data collection we think of all the ways it could be abused: Can it identify the user? Does it link to another dataset? Might it reveal something sensitive?

Yes, we have confidence in our security, our defenses in depth, our privacy policies, and our motivations to work for users and their interests.

But we are also confident that others have motivations and processes and policies that don’t align with ours… and might be given either the authority or the opportunity to gain access in the future.

This is why Firefox Send doesn’t know your encryption key for the files you share with your friends. This is why Firefox Accounts only knows six things (two of them optional) about you, and why Firefox Sync cannot read the data it’s storing for you.

And this is why Telemetry doesn’t know your Firefox Account id.


Categorieën: Mozilla-nl planet

Firefox Test Pilot: Screenshots is Shipping in Firefox 56

Mozilla planet - vr, 29/09/2017 - 13:09

Let’s start with the big news: we just shipped Firefox Screenshots with Firefox 56. Screenshots began life as the Test Pilot experiment Page Shot, and this marks the first time an experiment from Test Pilot has graduated into Firefox.

This is a big deal for Firefox users and a big deal for the Test Pilot team who have worked on this project for the last eighteen months or more, but most of all this is a huge moment for all of our brave Test Pilot participants. Your feedback, usage and support have changed Firefox for millions and millions of people. We couldn’t be more proud or more grateful.

What was Page Shot?<figcaption>The page shot selection interface.</figcaption>

Page Shot was a smart screenshotting experiment. Screenshots are pretty much ubiquitous these days, and even though there are a lot of options in the market on desktop, we knew from user research that we had an opportunity to innovate. Page Shot brought a few differentiating features into the mix:

  1. Smart selection: Page Shot was built for the web and let users intelligently select individual elements on a web page for shooting. Want to capture a specific image? Just click it and Page Shot will do the rest.
  2. Smart search: We built Page Shot to not only capture screenshots, but to capture lots of metadata as well. Page Shot extracted text and other attributes from underlying pages (within the shot area) and stored it along with each screenshot. In practice, this meant that shots of text were fully searchable.
  3. Full page shooting: Page Shot could take shots of full websites (up to 5000px), and not just visible page content.
  4. Expiring shots: Page Shot let users save shots to the web, but these saves expired after two weeks. We let users modify expiration dates on shots if they liked so they disappeared more quickly or stuck around longer.
Why Ship in Firefox?

In terms of sheer user-adoption, Page Shot has been our most popular Test Pilot experiment to date. Over the duration of its active run in Test Pilot, Page Shot had nearly twice as many daily enrollees as any of our other experiments. The difference in adoption made us pay special attention to Page Shot from the start.

<figcaption>Page Shot had nearly double the daily active enrollees as the next experiment. Also interesting to note is how many of our participants disappear around the New Year holiday.</figcaption>

Just as importantly, we saw sustained usage throughout the life of the experiment. Test Pilot doesn’t put a ton of focus on marketing since we believe our audience is sizable and diverse enough to give us the kinds of feedback we need to judge success. We tend to look at retention (do people keep using an experiment) more than growth (are more people coming to an experiment over time) as a key metric, and Page Shot retained users extremely well. People took shots and continued taking them.

<figcaption>Given a stable user base, we saw strong overall retention for screenshots.</figcaption>

We learned that Page Shot had significant network effects beyond Firefox. Because shots were sharable, we saw lots of people viewing shots across lots of different contexts. While Page Shot was a desktop-only experiment, we saw lots of shot views on mobile devices.

<figcaption>Sessions other than those initiated by taking a shot by device over the last six months of the experiment.</figcaption>

Further, while Page Shot was only available on Firefox, we saw significant traffic from other browsers like Chrome, Internet Explorer and Safari. The graph below shows that while Firefox normally accounted for the majority of Page Shot sessions, there were specific instances where other browsers spiked dramatically. We hypothesize that these spikes occurred around specific screenshots that went viral.

<figcaption>Viral events led to big spikes in sessions on other browsers.</figcaption>

While we don’t have any direct evidence that Page Shot led to growth for the Firefox product, we nevertheless really like the idea that Page Shot gave people a way to express their use of Firefox in public through social sharing.

Ultimately, the decision to move Page Shot to Firefox was made because of the combination of all of the above factors. Positive signals around adoption, retention and network effects all played a part in the decision. We also just thought Page Shot was really cool.

How is Firefox Screenshots Different from Page Shot?

Since last spring, our team has focused on the (herculean) task of transforming Page Shot into Firefox Screenshots. There has been a massive amount of behind-the-scenes engineering work from the Test Pilot, Firefox and Add-ons teams to make this possible.* On the product side, instead of adding new features before launch, we stripped out features with a focus on simplifying user experience, improving user interface polish and ensuring Screenshots works across all locales.

So What’s Changed?<figcaption>First things first, we changed the icon.</figcaption>

The UI in Screenshots is significantly more polished than it was for Page Shot. We touched up colors, animations, transitions, layouts and icons across the application. We also added a beautiful landing page and a new onboarding flow to introduce users to the experience.

<figcaption>Crucial beziers!</figcaption>

Users in Test Pilot loved Page Shot’s smart selection tool, so we drastically improved the overall polish of that feature. We also added googly eyes.

<figcaption>The Screenshots selection interface.</figcaption>

At the same time, we decided to temporarily remove full page and visible shooting features from Screenshots. Not only were these features not performant enough to make the final cut, but we did not include the option to directly download full/visible page captures without uploading to the Page Shot servers. In order to respect the privacy of our users, we backed out these features while a new user experience could be evaluated. As the graph below shows, people were definitely using these features in Page Shot, but not as much as saving and downloading cropped shots.

<figcaption>The yellow and green lines represent full and visible page saves.</figcaption>

Additionally, we added a cloud icon next to the save button on the shot selection screen. Again, we did this in order to promote transparency about saving to the web and better signal that Screenshots is backed by a service.

<figcaption>The Save icon before and after</figcaption>

We also removed smart search from Screenshots. While we still like the feature, we wanted to take time to reason about the privacy implications of capturing page metadata. Page Shot showed us that our audience didn’t search much anyway, which made the decision easier. Compared to the more than a quarter-million shots taken in the last six months of the experiment, there were only 1100 total interactions with the search bar.

<figcaption>Nobody searched so we killed the feature for launch.</figcaption>What’s Next

While we’re launching Screenshots today in Firefox 56, our other area of focus for the last six months has been on Firefox Quantum. Quantum is a brand new Firefox coming this November that drastically improves the performance and style of the browser. As we’ve built Screenshots for the 56 release, we’ve also had to track and implement many interface changes so that we fit seamlessly into the next generation of Firefox.

When Quantum launches this November, you’ll notice that Screenshots fits beautifully into the new interface. Quantum’s design language is all about decluttering your browser, and Screenshots will take its place alongside bookmarks, Pocket saves, synced tabs and other things you collect and share while browsing with Firefox.

<figcaption>Don’t worry, you’ll be able to pin Screenshots to the search bar with a right click.</figcaption>

For Quantum, we’re also bringing back full and visible-page shooting. Thanks to great work by Neha Khanna over the summer, we have a far more flexible design than before. Instead of saving shots to the web by default, Screenshots will preview the shot and prompt users to save to the web or download directly. We’ve also resolved some performance issues by using JPEGs instead of PNGs for very large images.

Beyond Quantum, we’ll continue to add more features to Screenshots. On our latest development builds we have two more features under active development:

  • Accounts integration so that users can connect Screenshots to their Firefox Accounts and access them on all of their devices.
  • Annotation tools for doodling on, meme-ifying, and otherwise marking-up screenshots.

We’ve already started rolling out Screenshots to some users in Firefox 55, and we’ve seen downloaded shots edge past saves to the web. We’re eager to conduct further user research around the order and design of the download and save buttons and hope to add more options like saving images directly to clipboard.

<figcaption>Screenshots users in Firefox 55 split evenly between uploads and downloads, but recently downloads have pushed ahead.</figcaption>

As we officially launch Firefox Screenshots, we’ll continue to actively solicit feedback from our new users to figure how to keep improving. We chose to keep the Beta label on Firefox Screenshots to signify that this is the beginning of something and not the end.

We’re excited to get to work!

*The saga of the technical transformation from Page Shot to Firefox Screenshots is another really excellent story. We’ll tell that one here as well.

Screenshots is Shipping in Firefox 56 was originally published in Firefox Test Pilot on Medium, where people are continuing the conversation by highlighting and responding to this story.

Categorieën: Mozilla-nl planet

Gervase Markham: SSL/TLS and PKI History

Mozilla planet - vr, 29/09/2017 - 11:18

A really good, high-level summary of the history of the SSL/TLS protocols and WebPKI from Feisty Duck.

Categorieën: Mozilla-nl planet

Mozilla Security Blog: Improving AES-GCM Performance

Mozilla planet - vr, 29/09/2017 - 09:25

AES-GCM is a NIST standardised authenticated encryption algorithm (FIPS 800-38D). Since its standardisation in 2008 its usage increased to a point where it is the prevalent encryption used with TLS. With 88% it is by far the most widely used TLS cipher in Firefox.

Firefox telemetry on symmetric ciphers in TLS

Unfortunately the AES-GCM implementation used in Firefox (provided by NSS) until now did not take advantage of full hardware acceleration on all platforms; it used a slower software-only implementation on Mac, Linux 32-bit, or any device that doesn’t have all of the AVX, PCLMUL, and AES-NI hardware instructions. Based on hardware telemetry information, only 30% of Firefox 55 users get full hardware acceleration (as well as the resulting resistance to side channel analysis). In this post I describe how I made AES-GCM in NSS and thus Firefox 56 significantly faster, more side-channel resistant, and more energy efficient on most platforms using hardware support.

To evaluate  the actual impact on Firefox users, I tested the practical speed of our encryption by downloading a large file from a secure site using various hardware configurations:  Downloading a file on a mid-2015 MacBook Pro Retina with Firefox 55 spends 17% of its CPU usage in ssl3_AESGCM, the routine that performs the decryption. On a Windows laptop with an AMD C-70 (without the  AES-NI instruction) Firefox CPU usage is 60% and the download speed is capped at 3.5MB/s. This doesn’t seem to be only an academic issue: Particularly for battery-operated devices, the energy consumption difference would be noticeable.

Improving GCM performance

Speeding up the GCM multiplication function is the first obvious step to improve AES-GCM performance. A bug was opened on integration of the original AES-GCM code to provide an alternative to the textbook implementation of gcm_HashMult. This code is not only slow but has timing side channels as you can see in the following excerpt from the binary multiplication algorithm:

for (ib = 1; ib < b_used; ib++) { b_i = *pb++; /* Inner product:  Digits of a */ if (b_i) s_bmul_d_add(MP_DIGITS(a), a_used, b_i, MP_DIGITS(c) + ib); else MP_DIGIT(c, ib + a_used) = b_i; }

We can improve on two fronts here. First NSS should use the PCLMUL hardware instruction to speed up the ghash multiplication if possible. Second if PCLMUL is not available, NSS should use a fast constant-time implementation.

Bug 868948 has several attempts of speeding up the software implementation without introducing timing side-channels. Unfortunately the fastest code that was proposed uses table lookups and is therefore not constant-time (accessing memory locations in the same cache line still leaks timing information). Thanks to Thomas Pornin I re-implemented the binary multiplication in a way that doesn’t leak any timing information and is still faster than any other proposed C code (see Bug 868948 or openssl/boringssl for other software implementations). Check out Thomas’ excellent write-up for details.

If PCLMUL is available on the CPU, using it is the way to go. All modern compilers support intrinsics, which allow us to write “inline assembly” in C that runs on all platforms without having to write assembly code files. A hardware accelerated implementation of the ghash multiplication can be easily implemented with _mm_clmulepi64_si128.

On Mac and Linux the new 32-bit and 64-bit software ghash functions (faster and constant-time) are used on the respective platforms if PCLMUL or AVX is not available. Since Windows doesn’t support 128-bit integers (outside of registers) NSS falls back to the slower 32-bit ghash code – which is still more than 25% faster than the previous ghash implementation.

Improving AES performance

To speed up AES, NSS requires hardware acceleration on Mac as well as on Linux 32-bit and any machine that doesn’t support AVX (or has it disabled). When NSS can’t use the specialised AES code it falls back to a table-based implementation that is again not constant-time (in addition to being slow). There are currently no plans of rewriting the existing fallback code. AES is impossible to implement efficiently in software without introducing side channels. Implementing AES with intrinsics on the other hand is a breeze.

m = _mm_xor_si128(m, cx->keySchedule[0]);     for (i = 1; i < cx->Nr; ++i) {       m = _mm_aesenc_si128(m, cx->keySchedule[i]); } m = _mm_aesenclast_si128(m, cx->keySchedule[cx->Nr]); _mm_storeu_si128((__m128i *)output, m);

Key expansion is a little bit more involved (for 192 and 256 bit), but is written in about 100 lines as well.

Mac sees the biggest improvement here. Previously, only Windows and 64-bit Linux used AES-NI, and now all desktop x86 and x64 platforms use it when available.

Looking at the numbers

To measure the performance gain of the new AES-GCM code I encrypted a 479MB file with a 128-bit key (the most widely used key size for AES-GCM). Note that these numbers are supposed to show a trend and heavily depend on the used machine and system load at the time.

Linux measurements are done on an Intel Core i7-4790, Windows measurements on a Surface Pro 2 with an Intel Core i5-4300U, and Mac mid 2015 Core i7-4980HQ. For all following graphs lower is better.

Linux 64 AES-GCM 128 encryption performance improvements

Linux 32 AES-GCM 128 encryption performance improvements

Performance of AES-GCM 128  on any 64-bit Linux machine without hardware support for the AES, PCLMUL, or AVX instructions is at least twice as fast now. If the AES and PCLMUL instructions are available, the new code only needs 33% of the time the old code took.

The speed-up for 32-bit Linux is more significant as it didn’t previously have any hardware accelerated code. With full hardware acceleration the new code is more than 5 times faster than before. Even in the worst case – when PCLMUL is not available – the speedup is still more than 50%.

The story is similar on Windows, although NSS already had fast code for 32-bit Windows users.

Windows 64 AES-GCM 128 encryption performance improvements


Windows 32 AES-GCM 128 encryption performance improvements


Performance improvements on Mac (64-bit only) range from 60% in the best case to 44% when AES-NI or PCLMUL is not available.

Mac OSX AES-GCM 128 encryption performance improvements

The numbers in Firefox

NSS 3.32 (Firefox 56) ships with the new accelerated AES-GCM code. It provides significantly reduced CPU usage for most TLS connections or higher download rates –  meaning better energy efficiency, too. NSS 3.32 is more intelligent in detecting the CPU’s capabilities and using hardware acceleration whenever possible. Assuming that all intrinsics and mathematical operations (other than division) are constant-time on the CPU, the new code doesn’t have any timing side-channels.

On the very basic laptop with the AMD C-70 download rates increased from ~3MB/s to ~6MB/s, and this is a device that has no hardware acceleration support.

To see the performance improvement we can look at the case where AVX is not available (which is the case for about 2/3 of the Firefox population). Assuming that at least AES-NI and PCLMUL is supported by the CPU we see the CPU usage drop from 15% to 3%.

AES_Decrypt CPU usage with NSS 3.31 without AVX hardware support

AES_Decrypt CPU usage with NSS 3.32 without AVX hardware support

The most immediate effect can be seen on Mac. AES_Decrypt NSS 3.31 used 9% CPU while in NSS 3.32 it uses only 4%.

AES_Decrypt CPU usage with NSS 3.31 on Mac OSX

AES_Decrypt CPU usage with NSS 3.32 on Mac OSX

The most significant performance improvements are summarise din the following table depicting the time in seconds to decrypt a ~500MB file with AES-GCM 128; lower is better.

Linux 32-bit Mac No AVX support NSS 3.31 (Firefox 55) 20.3 11.5 21.3 NSS 3.32 (Firefox 56) 3.4 4.6 3.5

These improvements to AES-GCM in NSS make Firefox 56 significantly faster, more side-channel resistant, and more energy efficient on most platforms using hardware support.

The post Improving AES-GCM Performance appeared first on Mozilla Security Blog.

Categorieën: Mozilla-nl planet

Air Mozilla: Kernel Recipes 29 Sept. (Full Day)

Mozilla planet - vr, 29/09/2017 - 09:00

Kernel Recipes 29 Sept. (Full Day) Share Kernel Contributions and Community

Categorieën: Mozilla-nl planet

Air Mozilla: Kernel Recipes 29 Sept. (Full Day)

Mozilla planet - vr, 29/09/2017 - 09:00

Kernel Recipes 29 Sept. (Full Day) Share Kernel Contributions and Community

Categorieën: Mozilla-nl planet

The Mozilla Blog: Improving the Firefox Privacy Notice

Mozilla planet - vr, 29/09/2017 - 05:57

Back in 2014, we reorganized our privacy policies to make them simple, clear, and usable. That effort was based on simplifying the then 14-page privacy policy around a framework that retained some detail but helped users find information more quickly. We did this because of our Data Privacy Principles that offer us guardrails as we develop our products and services.

Today I’m happy to announce another revision of our Firefox Privacy Notice, which follows our initial announcement on the topic.  We continue to build our products focusing on user control and fulfilling our “no surprises” rule when it comes to privacy.  We believe that in context notices with the user experience in mind make notices more understandable and actionable for users. Our updated notice includes:

  • A layered design to show what we collect, why we collect it, where you can learn more, and what your choices are.
  • Language that is more specific and transparent when describing the types of data.  We have used the same terms as our internal teams, including: “technical” data, “interaction” data, “webpage” data and “location” data.
  • A more holistic explanation of how a feature interacts with data.  For example, we previously had a separate privacy notice for cloud features like Sync.  This technical distinction was confusing, so we removed that separate privacy notice and have made it a part of the new Firefox Privacy Notice where context is more understandable.
  • On desktop platforms that support it, we have begun adding the ability to link the user directly into the appropriate user preferences so they can easily and quickly access privacy controls.

We’ve also changed our Firefox onboarding experience so that the Privacy Notice now displays on the second tab of a newly installed browser.

Take a look and tell us if we met the standards we set by going to Governance mailing list.

We hope all of this offers a more meaningful opportunity for users to learn about how we design privacy into Firefox, and make choices about the data they wish to share.

The post Improving the Firefox Privacy Notice appeared first on The Mozilla Blog.

Categorieën: Mozilla-nl planet

Air Mozilla: Privacy Lab

Mozilla planet - vr, 29/09/2017 - 03:00

Privacy Lab Join us to hear Uber discuss their new, privacy-engineered, open-source tool that helps gather statistical results from massive datasets while concealing users' personal details. Known...

Categorieën: Mozilla-nl planet

Air Mozilla: Privacy Lab

Mozilla planet - vr, 29/09/2017 - 03:00

Privacy Lab Join us to hear Uber discuss their new, privacy-engineered, open-source tool that helps gather statistical results from massive datasets while concealing users' personal details. Known...

Categorieën: Mozilla-nl planet

Marco Zehe: Rethinking Web Accessibility On Windows

Mozilla planet - vr, 29/09/2017 - 02:35

For the past 18 years, screen readers on Windows have had a particular way of presenting web content to their users. This model no longer scopes well in light of modern web applications and dynamically changing web sites. The model, therefore, needs to be reimagined and modernized.<!— more —>

A little bit of history

In 1999, the two major screen reader vendors on the market, JAWS and Window-Eyes, released new versions of their software that introduced a new way of web browsing for blind and visually impaired users when using Microsoft Internet Explorer. Web content was represented in a document-like form, much as was known already from word processors such as Microsoft Word. Semantic information like links, form controls, and later headings, lists and tables, were inlined and spoken accordingly.

To achieve this, the screen readers interfaced directly with IE and slurped in all the HTML of the currently loaded web page. Then, they interpreted the HTML themselves to build up the virtual document, sometimes also called virtual buffer. Virtual, because it was not a real document, but a close approximation of one that used very similar navigation paradigms as a real document.

The advantages of this approach were that the screen reader always knew everything there was to know about the mostly static web pages of the time. They could also perform operations such as listing all links on a page, or all form fields. Later, the vendors also introduced so-called quick navigation keys. By pressing a single letter, like h, for example, the user can move to next items of a particular type. That way, users could quickly jump to the next heading, list, table, form field, visited or unvisited link, etc.

However, as the web became more dynamic, first in the mid 2000s through mechanisms such as AJAX, and later through full-fledged JavaScript frameworks, the virtual buffers began showing signs of inadequacy. Because they needed to be kept in sync with the actually loaded document, a lot of communication had to take place between the browser and screen reader while the user was operating the page, and content be changed under the user’s nose, often dramatically changing the shape of the virtual document.

New browsers, new APIs

When Mozilla began producing Firefox in the early 2000s, it became apparent that it would not only run on Windows, but on Linux and Mac as well. On Linux, the requirement was that a full-fledged accessibility programming interface would have to be used, and no own HTML parsing was wanted by the assistive technology. The saying went: The browser already knows everything, why should the assistive technology have to reinterpret it again? The browser should, instead, tell the AT what it had through a set of standard programming interfaces.

And because on Windows, there was a project being started calledNVDA, a free and open-source screen reader, the same requirements were formulated for this platform as well. Instead of devising a whole new API, it was decided to enhance an existing accessibility programming interface called Microsoft Active Accessibility (MSAA), and add to it all the pieces that it was lacking to support full-fledged web content. The result was named IAccessible2, to indicate that IAccessible, the official interface name for MSAA, had been enhanced.

Around the same time, Apple started implementing accessibility support into WebKit, the engine powering the Safari web browser on OS X, now called MacOS. It, too, went the way of defining all that was needed to know for VoiceOver, Apple’s screen reader, through a set of standardized interfaces, instead of having VoiceOver interpret the HTML itself.

And when Microsoft started its work on Edge, the successor to Internet Explorer, it took the same approach, no longer allowing screen readers access to the raw HTML, and instead defining web content through its successor to MSAA, called UI Automation, or UIA.

Differences in architecture

On Windows, there are two ways to communicate between applications when using MSAA. One is called in-process, the other out-of-process. In the in-process case, one application injects part of its code into the other application’s running instance. It essentially becomes part of that other application. In our case, the screen reader injects part of its code into the browser, in order to get at the information for building the virtual document fast.

The other method, where the screen reader would communicate with the browser across application boundaries through a set of protocols defined by the operating system, is between 12 and 50 times slower than the process-injection method, depending on the actual queries being made. So depending on the size of the loaded web page, loading it into a virtual buffer could take under 1 second when in-process methods are being used, versus 12 to over 40 seconds when doing it across process boundaries. The advantage of in-process methods is therefore very clear.

The disadvantage, however, is that either component could bring the other down with it when crashing. If the screen reader module had a problem and crashed, it could take the browser down with it, being part of it now. Likewise, if the browser crashes, it can render parts of the screen reader inoperable. There are also security implications, and rumor has it that process injection might not be possible for much longer.

On other platforms such as Linux and MacOS, there is no such thing as injecting parts of one process into another. Inter-process communication, such as between an assistive technology and a browser, has to always happen across process boundaries and through standardized protocols. Additionally, Microsoft no longer allows process injection when using UI Automation to communicate between applications. Therefore, all communication between Microsoft Edge and a screen reader has to happen out of process, or in some cases through a specialized UIA bridge between applications.

Retire virtual buffers

As a consequence, both Orca, the dominant screen reader on Linux, and VoiceOver on MacOS and iOS, have no concept of a virtual buffer as is known from Windows screen readers. Moreover, due to the above mentioned limitations, for Microsoft Edge, NVDA also no longer uses a virtual buffer concept to represent web content when browsing with Edge.

So, to make screen readers on Windows future-proof for the next 10 to 20 years in web content, it is time to retire the virtual buffer concept and work with the notion that screen readers no longer know everything about a whole web document at any given time, but only parts of it that the user is currently working with. Once process injection is no longer possible on Windows even when using MSAA or IAccessible2, trying to maintain a full virtual buffer and keeping it dynamically updated is no longer going to be feasible in a performant manner.

Browsers must take more responsibility

To achieve equality with already existing functionality in screen readers, and therefore ensuring competitiveness of current users with their sighted peers, browsers must take on several of the tasks the screen reader previously performed inside its virtual buffer. Some of these are:

  • Provide means to fetch all items of a certain type on the currently loaded web page, for example all links, all headings etc.
  • Allow a means to jump rom the current position to the next heading, table, list, or other desired particular element without the screen reader having to crawl through all accessible objects in-between. The browser knows much more about the loaded web content than the screen reader, so should leverage that and help with this type of navigation by providing the next relevant object directly.
  • Fetch a current range of text and all its attributes and other semantic information so the screen reader can give the user a proper representation of what’s hot.
  • And other things that will need to be determined as this transition happens.

Examples where parts of the above already exist are the AT-SPI collections on Linux, and the APIs introduced in MacOS 10.11 El Capitan into Safari and Chrome to make navigation and fetching particular lists of items with VoiceOver much more responsive. Especially the Linux case, though, shows that there is still room for improvement. AT-SPI collections can do some things, but not others that would help performance greatly when quickly navigating by headings or lists, for example.


The following two examples demonstrate how certain types of interaction work now, and should work in the future on Windows.

Moving to next heading

A very common task is to move to the next heading. The way screen readers work now is that they suck in all the web content at once, always having it at the ready when the user wants to do quick navigation. The user invokes the Next Heading command. The screen reader crawls through its document and places the virtual cursor onto the next heading. The browser, on the other hand, is totally unaware that the screen reader user has changed reading context. The screen reader might or might not ask the browser to focus on the new element if possible.

In the future, the screen reader should tell the browser to give it the next heading relative to the current reading position. The browser then does the searching, which it can do much faster than the screen reader across boundaries, and provide the new location back to the screen reader, which in turn will then read out the information, and both browser and screen reader are now aware of the new reading position.

Inserting new content dynamically

When using Twitter in the so-called forms or application or focus mode, in which the user interacts with the browser directly, the user can use Twitter’s keyboard shortcuts. But because the user might switch back to virtual mode at any time, the screen reader needs to keep its buffer up to date at all times regardless of whether the buffer is actually being used.

So while the user is merrily reading tweets, they suddenly are being notified that new tweets were added at the top, and to press the Perios key to load them. By default, Twitter loads 50 tweets at once, and expands to more once the user reads the last two or three currently loaded tweets. Now the user has maybe reached a number of 70 or 80, and 30 new are waiting to be inserted.

The user presses Period. Twitter loads the new tweets and puts focus at the top. The screen reader gets notified that the list of previously 70 items now has expanded to show 100. But because the whole list layout has changed, the most efficient way is to simply replace the old list in the buffer with the new one. So the screen reader goes and removes the old list, and crawls through the hierarchy and fetches the new 100 list items, which may each consist of 6 to up to 10 or more accessible objects, and rerenders it. This will take some time, even when done in-process.

The future way of doing this is far less processing power intense. The new tweets come in, the user presses Period, the browser adds the items, Twitter changes focus to that newest item, and tells the screen reader. The screen reader now only needs to go and ask the parent list container about how many items it now has, so it can tell the user. It does not need to crawl through the whole list because there is no buffer to maintain.

This is why, for example, the experience of using Twitter on MacOS in Safari or Chrome is such a much smoother experience than on Windows with, for example, Firefox or Chrome and NVDA.

In conclusion

At Mozilla, we do want to start a project to enhance current APIs to allow screen readers to move away from the virtual buffer concept. The ideas are already floating around between team members. And because NVDA is also open-source, we can use an experimental branch to actually prototype approaches and check the theory against the practicality of day to day use. Sometimes, theories sound good, but the practice then falls on its face.

We expect to fail at some first attempts, learn from the experience, and reiterate. The end goal is to give an as good as, if not better, experience for browsing the web and being ready for dynamic web applications built in frameworks such as Angular or React, or being more efficient in complex web applications such as Gmail or Slack than we are now on Windows.

And we certainly hope that our friends at other browser accessibility teams such as Chrome or Edge, as well as commercial assistive technology vendors, will take an interest in what we do, and in a collaborative fashion, we’ll all strive to give our users better experiences.

The web accessibility on Windows needs to grow up now that it’s 18, and we want to try and make this happen!

The post Rethinking Web Accessibility On Windows appeared first on Marco's Accessibility Blog.

Categorieën: Mozilla-nl planet

Mozilla Addons Blog: WebExtensions in Firefox 57

Mozilla planet - do, 28/09/2017 - 22:32

Firefox 57 has reached Beta, and a bevy of new APIs and improvements have landed that will put us in a good place for the Firefox Quantum launch in November.

Legacy add-ons no longer load in Firefox 57, but there is still time to migrate (almost 5,000 have migrated so far!), and you can do so even after it lands in release. Just update your listing with the new code and your users will automatically update to the compatible version. When you do, be sure to tell them about it.

Documentation for the APIs discussed here can be found on MDN Web Docs.

API changes Tabs and Sessions APIs

Tabs now have a discarded state added to the Tab object. It will be set to true if the tab is not loaded with content, for example when restored from a previous session. This is part of getting ready for a tabs.discard API.

The tabs.opener API has now been implemented which means that openerTabId is available to the update and create methods and on the Tab object. This allows extensions to track the opener of tabs.

Also, the tabs API can now open URLs that are view-source: links and do a “load replace” which changes the page and replaces the current history so that the back button is unaffected.

The session API now has some APIs for setting, getting and removing data on a per tab or per window basis. This allows information about tabs or windows to survive session restores without the data needing to be stored by individual extensions.

webRequest API

The webRequest details object now includes proxy information. This proxy information will let webRequest listeners determine how the request interacted with a proxy.

A major new API for webRequest is now available which allows an extension to filter the HTTP response bodies as they come in. The code below alters the text on You could do this through a content script, but being able to alter the HTTP response body gives a whole new set of possibilities:

function listener(details) { let filter = browser.webRequest.filterResponseData(details.requestId); let decoder = new TextDecoder("utf-8"); let encoder = new TextEncoder(); filter.ondata = event => { let str = decoder.decode(, {stream: true}); str = str.replace(/Example/g, 'WebExtension Example'); filter.write(encoder.encode(str)); filter.disconnect(); } return {}; } browser.webRequest.onBeforeRequest.addListener( listener, {urls: ["*"], types: ["main_frame"]}, ["blocking"] ); Storage API

A basic implementation of has landed. This allows administrators or other applications to configure extensions for users. In Firefox you can place a JSON file in a directory, just like for native messaging. For example, a file called could be placed in the appropriate place:

{ "name": "", "description": "ignored", "type": "storage", "data": { "colour": "blue!" } }

Then in the extension:'colour').then((colour) => { console.log(colour); });

Would output “blue!”.

Clipboard API

A new clipboard API has been added to allow the copying of images to the clipboard. The clipboard.setImageData allows you to populate the clipboard with image data. This API is compatible with the Chrome apps API, but at this point it should be considered experimental. This API requires the clipboardWrite permission.

Developer Tools API

The developer tools gained the panels.elements.createSidebarPane API and a panels.elements sidebar.setExpression method. This lets extensions create sidebars in the developer tools. Here’s an example extension that parses jQuery variables:

Find API

A find API has landed in Firefox. This allows extensions to call the Firefox find API on a tab and get information about the results. It can then add or remove syntax highlighting from that tab, based on the previous search.

This example extension uses the API to search across multiple tabs and highlights them:

Miscellaneous changes Android

There have been multiple bugs fixed to ensure that pageActions and browserActions work well on Android. There has been multiple options_ui fixes and some additions. The runtime.openOptionsPage API has been added, and for those pages the activeTab permission takes effect. The browser_action.default_popup manifest property along with setPopup and getPopup has been added.

Firefox for Android now has support for installation permission prompts from the user, closely matching Desktop. When a user installs an add-on, they will be given a permission prompt.

Here’s an example when installing uBlock Origin:

If an extension chooses not to use installation permissions, the optional permission prompts have also been implemented which enable permission prompts at runtime.

Startup check

Firefox has had a brief compatibility check that occurs each time Firefox upgrades a major release. Because there are some extension that might update from legacy extensions sometime after Firefox 57 is released, we wanted to ensure that we could update users to new WebExtensions version when we can.

We took the opportunity to streamline this. The new check is quick and will only occur each time you upgrade to a major version (for example 56 to 57) and have legacy extensions:

User notification

There’s an ongoing project to show Firefox users what changes extensions make to their browser. Often it’s not clear to a user what an extension has done. It can be especially confusing if a user forgets what extensions are installed and finds changes they don’t understand later on.

An API was added that allows extensions to read the home page and new page values so extensions can tell if a user or another extension has changed the values. Along with this API, we’re now surfacing changes through to the about:preferences pages. If an extension uses the provided APIs to change: the home page, the new tab or contextual identities in Firefox 57, then a message will displayed to the user.

Here’s an example where an extension changes the home page:

An example where an extension enables contextual identities:

Long running scripts in an extension will now generate a warning that mentions the extension name, so users can choose what to do with extensions that might be taking a long time.

If an extension changes the new tab through the API, the URL bar will be empty when the new tab page is opened. This allows keyboard users to quickly navigate to new URLs. We’ve also fixed a bug where the identity was not shown in the URL bar for new tabs.

Over the coming releases we plan to add in more information into about:preferences for more and more APIs.


Thank you once again to our many contributors for this release, especially our volunteers including: Adam Hillier, angelsl, dw-dev, Jan Henning, Kevin Jones, Lee Bousfield, Tomislav Jovanovic and Tushar Saini. This release marked a record 171 bugs fixed.

The post WebExtensions in Firefox 57 appeared first on Mozilla Add-ons Blog.

Categorieën: Mozilla-nl planet

The Mozilla Blog: Screenshots, Send Tabs and more! Today’s faster Firefox provides upgraded features for all users

Mozilla planet - do, 28/09/2017 - 18:17

When our intrepid user research team goes into the field and observes Firefox users in the wild, they find that users have all sorts of creative solutions to do things that the browser doesn’t already do, like email links and screenshots to themselves and others, as a way to get things done.

We want Firefox to be the absolute best way to get things done, so we stuffed a ton of new features into today’s release.

Take, save, and share the web with Screenshots

The web is personal – often the site you visit, whether it’s your social network of choice or a proposed travel itinerary with a funny ad on it, is not something that you can easily save or share. With Screenshots, saving and sharing the things you see online is as easy as a click.

Screenshots started as Page Shot in Test Pilot – a program that allows users to test drive potential new features for Firefox. The feature proved its worth quickly as we watched it become the most downloaded experiment in the history of Test Pilot. To make the Screenshots experience even better, our team dedicated time to reviewing usability tests and event metrics to better understand how the feature was being used. With that in mind, Firefox Screenshots allows you to take, save and share screenshots – all without leaving your browser.

Here’s how it works:

First, Screenshots lets you capture a screen within your Firefox browser without downloading any new software. Either click and drag to grab the content you want, or because Screenshots is web aware, let Screenshots do it for you.  Just hover over the area you want to grab, let Screenshots automatically identify the outline of the area you’re looking at, then click.


Screenshot lets you click and drag to grab the content you want

You can choose the screenshots you want to save, and easily access your saved screenshots through a toolbar in your browser. Firefox automatically stores your screenshots in the cloud for two weeks, but you can change the expiration date or delete them anytime from your online library. You can also easily share your screenshots as a link with anyone, no matter what device they’re on or browser they use – all without having to click or save before you share. Try it out and discover what our Test Pilots loved so much about the feature.



Stop emailing links to yourself! Send Tabs is here to the rescue

Firefox is giving users a quicker way to share content between all of your mobile and desktop devices. It’s called Send Tabs.

Send Tabs provides the quickest route for users to instantly send any web page to and from your desktop, mobile browser, or any mobile app. This means you don’t have to email yourself links anymore! And your data is encrypted end-to-end. Even Mozilla can’t decrypt it.

Check it out for yourself:

Save time and breeze through checkout with form autofill

Whether you’re making a new online purchase or making a donation to a relief organization, filling out forms is tedious. Starting in the US, we’ll be gradually rolling out this feature to all your desktop devices to make it easier to fill out most address forms.

Firefox now allows users to complete online forms with multiple input fields like the address fields on your favorite shopping site, by simply selecting a suggestion from the autocomplete dropdown. When users first fill in a form on a compatible website, Firefox automatically saves the field data to “Saved Addresses” under Options (Preferences) so users can reuse such information with forms on new websites.


Firefox now saves addresses so you can fill out forms faster


Users can also save multiple addresses, so you can add work and home addresses of friends and family. Saved addresses can be synced to all your desktop devices.


Multiple addresses can be saved


Download this latest version of Firefox to experience these new and improved updates. With this latest release, we’re getting one step closer to the fastest Firefox yet – Firefox Quantum coming November 14. If you can’t wait until then try Firefox Quantum in Beta.

The post Screenshots, Send Tabs and more! Today’s faster Firefox provides upgraded features for all users appeared first on The Mozilla Blog.

Categorieën: Mozilla-nl planet

Air Mozilla: Reps Weekly Meeting Sep. 28, 2017

Mozilla planet - do, 28/09/2017 - 18:00

Reps Weekly Meeting Sep. 28, 2017 This is a weekly call with some of the Reps to discuss all matters about/affecting Reps and invite Reps to share their work with everyone.

Categorieën: Mozilla-nl planet

Hacks.Mozilla.Org: RNNoise: Using Deep Learning for Noise Suppression

Mozilla planet - do, 28/09/2017 - 16:49


The Mozilla Research RRNoise project shows how to apply deep learning to noise suppression. It combines classic signal processing with deep learning, but it’s small and fast. No expensive GPUs required — it runs easily on a Raspberry Pi. The result is easier to tune and sounds better than traditional noise suppression systems (been there!).

RNNoise will help improve the quality of WebRTC calls, especially for multiple speakers in noisy rooms. It is also small enough and fast enough to be executed directly in JavaScript, making it possible for Web developers to embed it directly in Web pages when recording audio.

RNNoise audio samples

Screenshot of the player that evaluates the effect of RNNoise. Play the demo.

You can improve RNNoise by donating your noise to science. We’re interested in noise from any environment where you might communicate using voice. That can be your office, your car, on the street, or anywhere you might use your phone or computer. The more realistic noise we have, the better the models we can build and the better the output.

Read in depth about the RNNoise project.

Categorieën: Mozilla-nl planet

Air Mozilla: Kernel Recipes 28 Sept. (afternoon)

Mozilla planet - do, 28/09/2017 - 14:15

Kernel Recipes 28 Sept. (afternoon) The first embedded conference in Paris

Categorieën: Mozilla-nl planet