Yesterday Let's Encrypt reached a new milestone: the unique set of all fully-qualified domain names in the currently-unexpired certificates issued by Let's Encrypt is now 10,022,446.

This data is coming from the same source as my previous posts: my CT box which is maintaining a state of Censys.io and Certificate Transparency using github.com/jcjones/ct-sql and a much-abused MariaDB server.

Let's Encrypt Growth Timeline

You can take a look at the graph in live-form, as well as some of the datasets coming from it at ct.tacticalsecret.com.

This is the future of the Let's Encrypt Statistics page on letsencrypt.org. The current graphs on LE's site are my doing, and they were 20 minutes of work late one night just to get something out there (We've all done that, right?). Of course, they've stayed online as "the" stats for far longer than I had ever intended. Doubly-problematic, those graphs' queries look like they show data all the way back to first issuance, but they actually don't - there's some LIMIT statements which are there because the queries were fast and ugly.

The update to the Let's Encrypt website to use these new datasets is live as PR #61 on the LE Website repo, awaiting @LetsEncrypt_Ops time to set up the cron job. In the meanwhile, enjoy ct.tacticalsecret.com as the demo and the bleeding-edge site.

https://tacticalsecret.com/lets-encrypts-growth-to-10m-fqdns/

Digital Economy Board of Advisors (DEBA) 2016

https://air.mozilla.org/digital-economy-30sep16-pm/

Foundation Demos September 30 2016

https://air.mozilla.org/foundation-demos-september-30-2016/

For the past year or so, I and a few others have been iterating on some tutorial slides for learning Rust. I’ve given this tutorial here at the local Boston Rust Meetup a few times, and we used the same basic approach at RustConf; I’ve been pretty happy with the results. But until now it’s been limited to in person events.

That’s why I’m so happy to announce a new site, Into Rust. Into Rust contains screencasts of many of these slides, and in particular the ones I consider most important: those that cover Ownership and Borrowing, which I think is the best place to start teaching Rust. I’ve divided up the material into roughly 30min screencasts so that they should be relatively easy to consume in one sitting – each also has some associated exercises to help make your knowledge more concrete.

I want to give special thanks to Liz Baillie, who did all the awesome artwork on the site.

http://smallcultfollowing.com/babysteps/blog/2016/09/30/announcing-intorust-dot-com/

Second, as promised, patchlevel 4 of the TenFourFox debugger (our hacked version of gdb) is available from SourceForge. This is a minor bugfix update that wallpapers a crash when doing certain backtraces or other operations requiring complex symbol resolution. However, the minimum patchlevel to debug TenFourFox is still 2, so this upgrade is merely recommended, not required.

http://tenfourfox.blogspot.com/2016/09/gdb7-patchlevel-4-available.html

Los dispositivos de estado s'olido o SSD, como com'unmente se les conoce siguen ganando terreno a los discos duros tradicionales y pr'acticamente cualquiera que compre un ordenador moderno elegir'a estas unidades de almacenamiento en lugar de un disco mec'anico. Sin embargo, los SSD no son eternos y tienen un per'iodo de vida limitado a la cantidad de operaciones de escritura establecidas por sus fabricantes.

Teniendo en cuenta lo antes mencionado, entonces deber'iamos tener cuidado y estar informados del tiempo “que le queda” a nuestra unidad SSD para no perder los datos almacenados repentinamente. Si desean saber m'as sobre el tema pueden leer este art'iculo publicado en Blogthinkbig.

Seg'un un estudio realizado por STH, los navegadores Firefox y Chrome afectan las SSD al escribir aproximadamente unos 10 Gb cada d'ia y como principal responsable de este problema a la generaci'on de archivos recovery.js empleados para guardar los datos de la sesi'on actual en caso de un cierre o fallo inesperado.

La buena noticia para los usuarios de Firefox es que este valor se puede modificar gracias a la p'agina about:config. En Chrome no es posible ajustar esta configuraci'on.

En Firefox debemos hacer lo siguiente:

1. Abrir la p'agina about:config y aceptar la advertencia.
2. Localizar la preferencia browser.sessionstore.interval y modificar su valor a uno deseado. Ver'as que aparece el valor 15000, esto quiere decir que cada 15 segundos se genera un nuevo recovery.js, as'i que simplemente tenemos que cambiar ese n'umero por uno mayor. 1000 equivale a 1 segundo.
3. Si deseas que Firefox no almacene el estado de lo que haces (no recomendado), debes cambiar la preferencia browser.sessionhistory.max_entries a 0. Por defecto se mantienen en el historial 50 entradas.

Espero que les haya sido 'util el art'iculo a todos aquell@s que tienen SSD.

Fuente: omicrono

http://firefoxmania.uci.cu/como-se-hace-evitar-que-firefox-afecte-tu-ssd/

Today Mozilla is hosting the second meeting of the Digital Economy Board of Advisors of the United States Department of Commerce, of which I am co-chair.

Support for the global open Internet is the heart of Mozilla’s identity and strategy. We build for the digital world. We see and understand the opportunities it offers, as well as the threats to its future. We live in a world where a free and open Internet is not available to all of the world’s citizens; where trust and security online cannot be taken for granted; and where independence and innovation are thwarted by powerful interests as often as they are protected by good public policy. As I noted in my original post on being named to the Board, these challenges are central to the “Digital Economy Agenda,” and a key reason why I agreed to participate.

Department of Commerce Secretary Pritzker noted earlier this year: “we are no longer moving toward the digital economy. We have arrived.” The purpose of the Board is to advise the Commerce Department in responding to today’s new status quo. Today technology provides platforms and opportunities that enable entrepreneurs with new opportunities. Yet not everyone shares the benefits. The changing nature of work must also be better understood. And we struggle to measure these gains, making it harder to design policies that maximize them, and harder still to defend the future of our digital economy against myopic and reactionary interests.

The Digital Economy Board of Advisors was convened to explore these challenges, and provide expert advice from a range of sectors of the digital economy to the Commerce Department as it develops future policies. At today’s meeting, working groups within the Board will present their initial findings. We don’t expect to agree on everything, of course. Our goal is to draw out the shared conclusions and direction to provide a balanced, sustainable, durable basis for future Commerce Department policy processes. I will follow up with another post on this topic shortly.

Today’s meeting is a public meeting. There will be two live streams: one for the 8:30 am-12:30 pm PT pre-lunch session and one for the afternoon post-lunch 1:30-3:00pm PT. We welcome you to join us.

Although the Board has many more months left in its tenure, I can see a trend towards healthy alignment between our mission and the outcomes of the Board’s activities. I’m proud to serve as co-chair of this esteemed group of individuals.

https://blog.lizardwrangler.com/2016/09/30/mozilla-hosting-the-u-s-commerce-department-digital-economy-board-of-advisors/

A few weeks ago I listened to Hanno B"ock talk about TLS version intolerance at the Berlin AppSec & Crypto Meetup. He explained how with TLS 1.3 just around the corner there again are growing concerns about faulty TLS stacks found in HTTP servers, load balancers, routers, firewalls, and similar software and devices.

I decided to dig a little deeper and will use this post to explain version intolerance, how version fallbacks work and why they’re insecure, as well as describe the downgrade protection mechanisms available in TLS 1.2 and 1.3. It will end with a look at version negotiation in TLS 1.3 and a proposal that aims to prevent similar problems in the future.

What is version intolerance?

Every time a new TLS version is specified, browsers usually are the fastest to implement and update their deployments. Most major browser vendors have a few people involved in the standardization process to guide the standard and give early feedback about implementation issues.

As soon as the spec is finished, and often far before that feat is done, clients will have been equipped with support for the new TLS protocol version and happily announce this to any server they connect to:

Client: Hi! The highest TLS version I support is 1.2.
Server: Hi! I too support TLS 1.2 so let’s use that to communicate.
[TLS 1.2 connection will be established.]

In this case the highest TLS version supported by the client is 1.2, and so the server picks it because it supports that as well. Let’s see what happens if the client supports 1.2 but the server does not:

Client: Hi! The highest TLS version I support is 1.2.
Server: Hi! I only support TLS 1.1 so let’s use that to communicate.
[TLS 1.1 connection will be established.]

This too is how it should work if a client tries to connect with a protocol version unknown to the server. Should the client insist on any specific version and not agree with the one picked by the server it will have to terminate the connection.

Unfortunately, there are a few servers and more devices out there that implement TLS version negotiation incorrectly. The conversation might go like this:

Client: Hi! The highest TLS version I support is 1.2.
Server: ALERT! I don’t know that version. Handshake failure.
[Connection will be terminated.]

Or:

Client: Hi! The highest TLS version I support is 1.2.
Server: TCP FIN! I don’t know that version.
[Connection will be terminated.]

Or even worse:

Client: Hi! The highest TLS version I support is 1.2.
Server: (I don’t know this version so let’s just not respond.)
[Connection will hang.]

The same can happen with the infamous F5 load balancer that can’t handle ClientHello messages with a length between 256 and 512 bytes. Other devices abort the connection when receiving a large ClientHello split into multiple TLS records. TLS 1.3 might actually cause more problems of this kind due to more extensions and client key shares.

What are version fallbacks?

As browsers usually want to ship new TLS versions as soon as possible, more than a decade ago vendors saw a need to prevent connection failures due to version intolerance. The easy solution was to decrease the advertised version number by one with every failed attempt:

Client: Hi! The highest TLS version I support is 1.2.
Server: ALERT! Handshake failure. (Or FIN. Or hang.)
[TLS version fallback to 1.1.]
Client: Hi! The highest TLS version I support is 1.1.
Server: Hi! I support TLS 1.1 so let’s use that to communicate.
[TLS 1.1 connection will be established.]

A client supporting everything from TLS 1.0 to TLS 1.2 would start trying to establish a 1.2 connection, then a 1.1 connection, and if even that failed a 1.0 connection.

Why are these insecure?

What makes these fallbacks insecure is that the connection can be downgraded by a MITM, by sending alerts or TCP packets to the client, or blocking packets from the server. To the client this is indistinguishable from a network error.

The POODLE attack is one example where an attacker abuses the version fallback to force an SSL 3.0 connection. In response to this browser vendors disabled version fallbacks to SSL 3.0, and then SSL 3.0 entirely, to prevent even up-to-date clients from being exploited. Insecure version fallback in browsers pretty much break the actual version negotiation mechanisms.

Version fallbacks have been disabled since Firefox 37 and Chrome 50. Browser telemetry data showed it was no longer necessary as after years, TLS 1.2 and correct version negotiation was deployed widely enough.

The TLS_FALLBACK_SCSV cipher suite

You might wonder if there’s a secure way to do version fallbacks, and other people did so too. Adam Langley and Bodo M"oller proposed a special cipher suite in RFC 7507 that would help a client detect whether the downgrade was initiated by a MITM.

Whenever the client includes TLS_FALLBACK_SCSV {0x56, 0x00} in the list of cipher suites it signals to the server that this is a repeated connection attempt, but this time with a version lower than the highest it supports, because previous attempts failed. If the server supports a higher version than advertised by the client, it MUST abort the connection.

The drawback here however is that a client even if it implements fallback with a Signaling Cipher Suite Value doesn’t know the highest protocol version supported by the server, and whether it implements a TLS_FALLBACK_SCSV check. Common web servers will likely be updated faster than others, but router or load balancer manufacturers might not deem it important enough to implement and ship updates for.

Signatures in TLS 1.2

It’s been long known to be problematic that signatures in TLS 1.2 don’t cover the list of cipher suites and other messages sent before server authentication. They sign the ephemeral DH params sent by the server and include the *Hello.random values as nonces to prevent replay attacks:

h = Hash(ClientHello.random + ServerHello.random + ServerParams)

Signing at least the list of cipher suites would have helped prevent downgrade attacks like FREAK and Logjam. TLS 1.3 will sign all messages before server authentication, even though it makes Transcript Collision Attacks somewhat easier to mount. With SHA-1 not allowed for signatures that will hopefully not become a problem anytime soon.

Downgrade Sentinels in TLS 1.3

With neither the client version nor its cipher suites (for the SCSV) included in the hash signed by the server’s certificate in TLS 1.2, how do you secure TLS 1.3 against downgrades like FREAK and Logjam? Stuff a special value into ServerHello.random.

The TLS WG decided to put static values (sometimes called downgrade sentinels) into the server’s nonce sent with the ServerHello message. TLS 1.3 servers responding to a ClientHello indicating a maximum supported version of TLS 1.2 MUST set the last eight bytes of the nonce to:

0x44 0x4F 0x57 0x4E 0x47 0x52 0x44 0x01

If the client advertises a maximum supported version of TLS 1.1 or below the server SHOULD set the last eight bytes of the nonce to:

0x44 0x4F 0x57 0x4E 0x47 0x52 0x44 0x00

If not connecting with a downgraded version, a client MUST check whether the server nonce ends with any of the two sentinels and in such a case abort the connection. The TLS 1.3 spec here introduces an update to TLS 1.2 that requires servers and clients to update their implementation.

Unfortunately, this downgrade protection relies on a ServerKeyExchange message being sent and is thus of limited value. Static RSA key exchanges are still valid in TLS 1.2, and unless the server admin disables all non-forward-secure cipher suites the protection can be bypassed.

The comeback of insecure fallbacks?

Current measurements show that enabling TLS 1.3 by default would break a significant fraction of TLS handshakes due to version intolerance. According to Ivan Risti'c, as of July 2016, 3.2% of servers from the SSL Pulse data set reject TLS 1.3 handshakes.

This a very high number and would affect way too many people. Alas, with TLS 1.3 we have only limited downgrade protection for forward-secure cipher suites. And that is assuming that most servers either support TLS 1.3 or update their 1.2 implementations. TLS_FALLBACK_SCSV, if supported by the server, will help as long as there are no attacks tampering with the list of cipher suites.

The TLS working group has been thinking about how to handle intolerance without bringing back version fallbacks, and there might be light at the end of the tunnel.

Version negotiation with extensions

The next version of the proposed TLS 1.3 spec, draft 16, will introduce a new version negotiation mechanism based on extensions. The current ClientHello.version field will be frozen to TLS 1.2, i.e. {3, 3}, and renamed to legacy_version. Any number greater than that MUST be ignored by servers.

To negotiate a TLS 1.3 connection the protocol now requires the client to send a supported_versions extension. This is a list of versions the client supports, in preference order, with the most preferred version first. Clients MUST send this extension as servers are required to negotiate TLS 1.2 if it’s not present. Any version number unknown to the server MUST be ignored.

This still leaves potential problems with big ClientHello messages or choking on unknown extensions unaddressed, but according to David Benjamin the main problem is ClientHello.version. We will hopefully be able to ship browsers that have TLS 1.3 enabled by default, without bringing back insecure version fallbacks.

However, it’s not unlikely that implementers will screw up even the new version negotiation mechanism and we’ll have similar problems in a few years down the road.

GREASE-ing the future

David Benjamin, following Adam Langley’s advice to have one joint and keep it well oiled, proposed GREASE (Generate Random Extensions And Sustain Extensibility), a mechanism to prevent extensibility failures in the TLS ecosystem.

The heart of the mechanism is to have clients inject “unknown values” into places where capabilities are advertised by the client, and the best match selected by the server. Servers MUST ignore unknown values to allow introducing new capabilities to the ecosystem without breaking interoperability.

These values will be advertised pseudo-randomly to break misbehaving servers early in the implementation process. Proposed injection points are cipher suites, supported groups, extensions, and ALPN identifiers. Should the server respond with a GREASE value selected in the ServerHello message the client MUST abort the connection.

https://timtaubert.de/blog/2016/09/tls-version-intolerance/

I've had the opportunity to attend the Beyond the Code conference for the past two years.  This year, the venue moved to a location in Toronto, the last two events had been held in Ottawa.  The conference is organized by Shopify who again managed to have a really great speaker line up this year on a variety of interesting topics.  It was a two track conference so I'll summarize some of the talks I attended.  

Pay gap for white woman, African American women and Hispanic women compared to a white man in the United States.

The average white American has 91 white friends and one black friend so it's not very likely that they will refer non-white people. Not sure what the numbers are like in Canada but I'd guess that they are quite similar.

http://relengofthenerds.blogspot.com/2016/09/beyond-code-2016-recap.html

Three days talks around the Linux Kernel

https://air.mozilla.org/kernel-recipes-2016-09-30-PM-Session/

In response to recent developments attacking Diffie-Hellman key exchange (https://weakdh.org/) and to protect the privacy of Firefox users, we have increased the minimum key size for TLS handshakes using Diffie-Hellman key exchange to 1023 bits. A small number of servers are not configured to use strong enough keys. If a user attempts to connect to such a server, they will encounter the error “ssl_error_weak_server_ephemeral_dh_key”.

https://blog.mozilla.org/security/2016/09/30/mitigating-logjam-enforcing-stronger-diffie-hellman-key-exchange/

Three days talks around the Linux Kernel

https://air.mozilla.org/kernel-recipes-2016-09-30-AM-Session/

Digital Economy Board of Advisors (DEBA) 2016

https://air.mozilla.org/digital-economy-30Sep16-am/

Hello, SUMO Nation!

Change is a constant, and Mozilla is no different. Bigger and smaller changes are coming up across many a project, including SUMO – and we need your help figuring out what they should be like. Learn more about the ways you can make us be better below!

Welcome, new contributors!

• Pranav Karakavalasa
• rajivjhaimin
• heeralsakrani

If you just joined us, don’t hesitate – come over and say “hi” in the forums!

SUMO Community meetings

• LATEST ONE: 28th of September- you can read the notes here and see the video at AirMozilla.
  
• NEXT ONE: happening on the 5th of October!
• If you want to add a discussion topic to the upcoming meeting agenda:
  • Start a thread in the Community Forums, so that everyone in the community can see what will be discussed and voice their opinion here before Wednesday (this will make it easier to have an efficient meeting).
  • Please do so as soon as you can before the meeting, so that people have time to read, think, and reply (and also add it to the agenda).
  • If you can, please attend the meeting in person (or via IRC), so we can follow up on your discussion topic during the meeting with your feedback.

Community

• Help Mozilla choose the new look – take this survey!
• Reminder: MozFest is a bit more than a month away! Are you going to attend this year?
• Ongoing reminder #1: if you think you can benefit from getting a second-hand device to help you with contributing to SUMO, you know where to find us.
• Ongoing reminder #2: we are looking for more contributors to our blog. Do you write on the web about open source, communities, SUMO, Mozilla… and more? Do let us know!
• Ongoing reminder #3: want to know what’s going on with the Admins? Check this thread in the forum.

Platform

• PLATFORM REMINDER! The Platform Meetings are BACK! If you missed the previous ones, you can find the notes in this document. (here’s the channel you can subscribe to). We really recommend going for the document and videos if you want to make sure we’re covering everything as we go.
  • Several Admins will be meeting with members of the Lithium team to work closely on the platform migration.
  • More updates and questions in this document.
• Don’t forget about the main migration thread, with the list of areas that can benefit from your input:
  • Roles
  • Gamification: ranks & badges
  • Metrics and measurement
  • Design ideas (1st wave)
  • Forum moderation
  • Shutting down Kitsune
• If you are interested in test-driving the new platform now, please contact Madalina.
  • IMPORTANT: the whole place is a work in progress, and a ton of the final content, assets, and configurations (e.g. layout pieces) are missing.
  • QUESTIONS? CONCERNS? Use the migration thread to put questions/comments about it for everyone to share and discuss.

Social

Support Forum

Knowledge Base & L10n

• We are 5 weeks before next release / 1 week after current release What does that mean? (Reminder: we are following the process/schedule outlined here).
  • No work on next release content for KB editors or localizers 
  • All existing content is open for editing and localization as usual; please focus on localizing the most recent / popular content
• Since pizza turned out to be a great success, if you have ideas how to virtually gather your l10n team mates, contact me about that!

Firefox

• for Android
  • Version 50 is slated to come out on November 8th. It should bring video viewing and controlling improvements.

• for Desktop
  • Version 50 (November 8th as well) will bring the following goodies:
    • WebRTS – full duplex audio streams
    • Tracking Protection supporting Do Not Track
    • Electrolysis – e10s RTL for Windows and Mac
    • First e10s sandbox for Mac OS X and Windows
    • Find in page with a mode to search for whole words only
    • New preference for cycling tabs using Ctrl + Tab
    • Improved printing options via the Reader Mode

• for iOS
  • Still quiet… Keep using 5.0!
    

…and that’s it for this week! Remember that we <3 you all for being there for the users when it matters most! Keep rocking the helpful web!

https://blog.mozilla.org/sumo/2016/09/29/whats-up-with-sumo-29th-september/

Weekly project updates from the Mozilla Connected Devices team.

https://air.mozilla.org/connected-devices-weekly-program-update-20160929/

I recorded an episode for the WeCodeSign podcast. It’s in Spanish!

You can download / listen from their website.

We actually talked about more than Web Audio; there’s a list of links to things we mentioned during the episode. From progressive enhancement to Firefox’s Web Audio editor, to the old PCMania tracking stories, to Firefox for iOS… lots of things!

I was really pleased with the experience. The guys were really good at planning, and did a great job editing the podcast as well (and they use Audacity!).

Editando el #podcast de ma~nana con @supersole sobre Web Audio desde Londres para que est'e a tiempo si la "conexi'on" me deja bajar un archivo pic.twitter.com/mEjTabVWjO

— WeCodeSign Podcast (@wecodesign) September 26, 2016

Totally recommended—in fact I suggested that both my fantastic colleague Bel'en and the very cool Buritic'a are interviewed at some point in the future.

I’d love to hear what they have to say!

Throwback to the last time I recorded a podcast in Spanish–at least this time I wasn’t under a massive cold!

https://soledadpenades.com/2016/09/29/talking-about-web-audio-in-wecodesign-podcast/

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.

https://air.mozilla.org/reps-weekly-meeting/

Firefox 51 landed in Developer Edition this week, so we have another update on WebExtensions for you. In this update, we’re making it easier for you to port your existing add-ons to WebExtensions. In addition to being fully compatible with multiprocess Firefox, WebExtensions are becoming the standard for add-on development.

Embedded WebExtensions

In Firefox Developer Edition, you can now embed a WebExtensions add-on inside an existing SDK or bootstrapped add-on.

This is especially useful to developers of SDK or bootstrapped add-ons who want to start migrating to WebExtensions and take advantage of new APIs like Native Messaging, but can’t fully migrate yet. It’s also useful for developers who want to complete data migration towards WebExtensions, and who want to take parts of their add-on that are not compatible with multiprocess Firefox and make them compatible.

For more documentation on this, please head over to MDN or check out some examples.

If you need help porting to WebExtensions, please start with the compatibility checker, and check out these resources.

Manifest Change

Because of confusion around the use of strict_min_version in WebExtensions manifests, we’ve prevented the use of * in strict_min_version, for example 48.* is no longer valid. If you upload an add-on to addons.mozilla.org we’ll warn you of that fact.

API Changes

The clipboardWrite permission is now enabled which removes the need to be in a user gesture. This is usable from extension tabs, popups and content scripts.

When a WebExtensions add-on is uninstalled, any local storage is now cleared. If you’d like to persist data across an uninstall then you can use the upcoming sync storage.

The management API now supports the uninstallSelf and getSelf methods. The idle.queryState API has been updated to accurately reflect the state, previously it always returned the value “idle”.

In the webRequest API, onBeforeRequest is now supported in Firefox Nightly and Developer Edition. There are some platform changes that are required to get that to land in a Release version of Firefox.

Developers have been testing out Native messaging and a couple of bugs were filed and fixed on that. New, more detailed, documentation has been written. One of the useful pieces of feedback involved the performance of the round-trip time, and that has now improved.

There has been a few improvements to the appearance of popup windows including the popup arrow, the corners of the popup and reducing flicker on the animation. Here’s a before and after:

Out of process extensions

Now that the majority of the work multi process Firefox has been completed, we are looking ahead to the many improvements it can bring. One of them is allowing WebExtensions to be run in a separate process. This process-sandboxing of add-ons will bring clear performance and security benefits.

But before we can do that, there is quite a bit of work that needs to be done. The main tracking bug lists some of these tasks. There is also a video of Rob Wu presenting the work he has done on this. There currently isn’t a timeline for when this will be landed, but the work is progressing.

Recognition

We’d also like to give a thank you to four new contributors to WebExtensions, who’ve helped with this release. Thanks to sj, Jorg K, fiveNinePlusR and Tomislav.

Update: link to Robs presentation fixed.

https://blog.mozilla.org/addons/2016/09/29/webextensions-in-firefox-51/

Years ago, every time we were releasing a new version of Firefox and bumped the version number for all Firefox channels, nightly builds were also getting a “What’s New” page displayed at restart after that major version number change (this old page is still available on the WayBack Machine and you can even see a video with ex-QA team lead Juan Becerra).

Then, at some point (Bug 748503), the call to that What’s New page was redirected to the First Run page. It made sense at the time as nobody was actively maintaining that content and it had not been updated in years, but it was also shutting down one of the few direct communication channels with our Nightly users.

Kohei Yoshino and myself worked on resurrecting that page and turn it into a simple yet effective communication channel with our Nightly users where they can get news about what’s new in the Nightly world.

Unlike the old page we had, this new updated version is integrated correctly into mozilla.org framework (bedrock) which means that we inherit from the nice templates they create and have a workflow which allows localization of that page (see the French and Japanese version of the page) and we might even be able to provide conditional content based on geolocation in the future.

We have created this page with the objective of increasing participation and communication with our core technical users and we intend to update it periodically and make it useful not only to Mozilla with calls to feedback and testing of recently landed features but also to Nightly users (how about having a monthly power-user tip there for example?).

If you have ideas on what information could be part of this What’s New page, don’t hesitate to leave a comment on the blog or to reach out to me directly (pascal At mozilla Dot com)!

CREDITS

Many thanks to Kohei for his great work on the design and the quality of his code. Thanks to the rest of the Release Management team and in particular to Liz Henry and Marcia Knous for helping fix my English! Many thanks to the mozilla.org webdev team for helping with reviews and suggesting nice visual tricks such as the responsive multi-column layout and improved typography tips for readability. Finally, thanks to the localizers that took the time to translate that page in a couple of days before we shipped it even though the expected audience is very small!

BONUS

We were asked via our @FirefoxNightly Twitter account if we could provide the nice background on the What’s New page as a wallpaper for desktop. Instead of providing the file, I am showing you in the following video tutorial how you can do it by yourself with Firefox Nightly Developer Tools, enjoy hacking with your browser and the Web, that’s what Nightly is for!

https://blog.nightly.mozilla.org/2016/09/29/firefox-nightly-got-its-whats-new-page-back-last-week/

I’m getting a lot of reports that the Google “I’m Feeling Lucky” option is no longer working with Keyword Search. Unfortunately Google seems to have broken this in their latest search update even though they’ve left the button on the homepage. There’s nothing I can really do to work around it at this time.

If you want a similar feature, you can switch to DuckDuckGo and use their “I’m Feeling Ducky” option.

https://mike.kaply.com/2016/09/29/keyword-search-is-no-longer-feeling-lucky/