For the record, in case it was unclear, I'm 100% interested in pushing the use of Rust in GNOME. It is all held down by the amount of free time I have.
https://www.figuiere.net/hub/blog/?2016/11/07/864-rust-and-gnome
The Monday Project Meeting
The webinar will answer questions around the Equal Rating Innovation Challenge including what we are looking for as well as how to submit. To ask...
https://air.mozilla.org:443/webinar-innovation-challenge-mechanics-2016-11-07/
Currently, Mozilla’s ban on using the old and insecure SHA-1 hash algorithm as part of the construction of digital certificates is implemented via the ban in the CAB Forum Baseline Requirements, which we require all CAs to adhere to. However, implementing the ban via the BRs is problematic for a number of reasons:
- It allows the issuance of SHA-1 certs in publicly-trusted hierarchies in those cases where the cert is not within scope of the BRs (e.g. email certs).
- The scope of the BRs is a matter of debate, and so there are grey areas, as well as areas clearly outside scope, where SHA-1 issuance could happen.
- Even when the latest version of Firefox stops trusting SHA-1 certs in January, a) that block is overrideable, and b) that doesn’t address risks to older versions.
Therefore, I’ve started a discussion on updating Mozilla’s CA policy to implement a “proper” SHA-1 ban, which we would implement via a CA Communication, and
then later in an updated version of our policy. See mozilla.dev.security.policy if you want to contribute to the discussion.
http://feedproxy.google.com/~r/HackingForChrist/~3/O1Q6JsxwwCw/
Firefox DevTools has now a network throttling tool to simulate slow connections, so you can get a rough idea of the user experience under different connection types (bug #1283453).
This is extremely important when building responsive sites, which are meant to perform well on many different devices and scenarios.
To access this tool, make sure you’re running an updated version of Nightly, then open the Responsive Design Mode tool via Tools -> Web Developer -> Responsive Design Mode. You can then select the desired simulated speed with the dropdown menu to the right of “Responsive Design Mode”, and reload the page to see the effect of the changes.
And if you want to find out what is being loaded, use this tool in combination with the Network inspector:
Once upon a time, I started geotagging my photos. For that I bought a GPS logger, an Holux M-1200E. The device works great with gpsbabel, and since my photography workflow was stuck on MacOS, I used Houdah GPS (which uses gpsbabel behind the scene, BTW). Also I have been working for too long on moving that workflow to Linux and GNOME. At one point I even started to write an app I called "Magellan" to do what that MacOS tool did, as a part of my other project, Niepce. I didn't really get motivated so it went nowhere. It was written in C++ like the rest of Niepce. The technology isn't the problem here.
Fast forward, my photography machine got upgraded to a more recent version of its operating system after the one I was using was abandonned by browser vendors, and it happens that in that upgrade, the GPS logger stopped working because MacOS 10.11 stopped providing the USB->Serial driver needed. I could install some random driver, but given how much trust I have, I decided to pass. On Linux, it still works.
I had already started rewriting Magellan in Rust using gtk-rs ; I did that as just another Rust learning project. This breakage came right as a good motivator to actually push the development of that application and make it work. And it does.
The name "Magellan" was already used for some GPS related product (not surprising), so my app became GPS Ami ("Ami" means "friend" in French).
The design
I basically reimplemented Houdah GPS, UI and such. It works OK, but I think it will act as a transitionary state. I have bigger plans.
Notably, I want to allow a better control of the device, like what bt747 can do - my logger is based on that chipset, and other automation feature so I can use GPS Ami from Niepce to download the tracks. I currently only tested with the device I have.
The implementation
As explained before GPS Ami is written in Rust and uses gtk-rs for the UI. I have to be honest, gtk-rs is not ready for prime-time, but it looks very promising and I'm very happy to be able to contribute as needed. Not surprising, but you should be ready to have to put your hands in it if you want to use it. I did just that: provided more APIs, filed some bugs, sometime fixing them. I also had to implement gudev-rs to be able to have gudev functionnality for device hotplug — to plug into the mainloop. This was a learning experience.
Rust tooling is a lot about generating a monolithic binary, without
data files. This is not bad per see, but when you need data files like
.ui from glade to load the UI in Gtk (albeit this not required on Gtk
side, it is more convenient), you are a bit stuck. Fortunately there
is the includestr!() macro in Rust which mean "load this file at
compile time and put it in this string".
Another problem I had was installing the rest of the files, like the .desktop or icons, problem I solved by wrapping cargo into an automake build system.
On overall, I'm just calling gpsbabel from a UI to download file.
The future
So what should come into the future?
- polish the UI more, possibly tweaking it. This will probably require more gtk-rs work. IMHO there are a few show stopper for a first version.
- implement a driver for this GPS, in Rust so that the actual driver be written in memory safe language.
- see about adding more control feature: we should be able to read the GPS values like it is done in bt747.
- support other devices officially (I don't have any other though)
Help wanted
- I don't have an icon
- I only have one device to test with
https://www.figuiere.net/hub/blog/?2016/11/06/863-introducting-gps-ami
I talked with Ed Hoover on the between screens podcast a while ago and that episode has now been published. It is a dense 12 minutes as the good Ed edited it massively.
With “RepsNext” we increased alignment between the Reps program and the Participation team. The main outcome is setting quarterly Objectives and Key Results together. This enables all Reps to see which contributions have a direct link to the Participation team . Of course, Reps are welcome to keep doing amazing work in other areas.
| Objective 1 | A focus set of relevant training and learning opportunities for Reps are systematized and they regularly access these opportunities to be more effective in their contributions and as a result providing more impact to Mozilla’s main initiatives. |
| KR1 | Core mobilizers who took the leadership training report being more effective to support Mozilla by actively using their new skills. |
| KR2 | Mobilizers from at least 90% of our (10) regions are interested in the training |
| KR3 | 80% of the people who took coaching training report having used these new skills in their volunteer work and report being more effective |
| KR4 | Gatherings toolkit quality is enough for volunteers to drive impactful gatherings on their own. |
| Objective 2 | Reps is the program for most core volunteers where many communities feel their voice represented and influencing the organization, and where mozillians join to be more aligned, grow their skills and be more impactful in mobilizing others. |
| KR1 | Communities are making Activate Mozilla successful by running 100 activities. |
| KR2 | 30% more effectiveness (time and positive sentiment) on budget process |
| KR3 | Initial material for Reps Resources track foundation is created. |
| KR4 | Plan for integrating all efforts (Leadership, Coaching, Regional, Resources) into Reps structure delivered. |
| KR5 | There is an implementation plan in place to decrease the time between an application and the onboarding by at least 50% compared to H1 2016. |
| KR6 | We have at least 3 different solid ideas around Recognition in place and started at least one experiment. |
Which of the above objectives are you most interested in? What key result would you like to hear more about? What do you find intriguing? Which thoughts cross your mind upon reading this?
Let’s keep the conversation going! Please provide your comments in Discourse.
https://blog.mozilla.org/mozillareps/2016/11/04/reps-program-objectives-q4-2016/
El pasado martes 19 de septiembre Mozilla liber'o una nueva versi'on de su navegador e inmediatamente compartimos con ustedes sus novedades y su descarga. Pedimos disculpa a todas las personas por las molestias que esto pudo causar.
Lo nuevo
El administrador de contrase~nas ha sido actualizado para permitir a las p'aginas HTTPS emplear las credenciales HTTP almacenadas. Esta es una forma m'as para soportar Let’s Encrypt y ayudar a los usuarios en la transici'on hacia una web m'as segura.
El modo de lectura ha recibido varias funcionalidades que mejoran nuestra lectura y escucha mediante la adici'on de controles para ajustar el ancho y el espacio entre l'ineas del texto, y la inclusi'on de narraci'on donde el navegador lee en voz alta el contenido de la p'agina; sin dudas caracter'isticas que mejorar'an la experiencia de uso en personas con discapacidad visual.
El reproductor de audio y video HTML5 ahora posibilita la reproducci'on de archivos a diferentes velocidades (0.5x, Normal, 1.25x, 1.5x, 2x) y repetirlos indefinidamente. En este sentido, se mejor'o el rendimiento al reproducir videos para usuarios con sistemas que soportan instrucciones SSSE3 sin aceleraci'on por hardware.
Firefox Hello, el sistema de comunicaci'on mediante videollamadas y chat ha sido eliminado por su bajo empleo. No obstante, Mozilla seguir'a desarrollando y mejorando WebRTC.
Fin del soporte para sistemas OS X 10.6, 10.7 y 10.8, y Windows que soportan procesadores SSE.
Para desarrolladores
- A~nadida la columna Causa al Monitor de Red para mostrar la causa que gener'o la petici'on de red.
- Introducida la API web speech synthesis.
Para Android
- Adicionado el modo de vista de p'agina sin conexi'on, con esto podr'as ver algunas p'aginas aunque no tengas acceso a Internet.
- A~nadido un paseo por caracter'isticas fundamentales como el Modo de Lectura y Sync a la p'agina Primera Ejecuci'on.
- Introducidos las localizaciones Espa~nol de Chile (es-CL) y Noruego (nn-NO).
- El aspecto y comportamiento de las pesta~nas ha sido actualizado y ahora:
- Las pesta~nas antiguas ahora son ocultadas cuando la opci'on restaurar pesta~nas est'a establecida en “Siempre restaurar”.
- Recuerdo de la posici'on del scroll y el nivel de zoom para las pesta~nas abiertas.
- Los controles multimedia han sido actualizados para evitar sonidos desde m'ultiples pesta~nas al mismo tiempo.
- Mejoras visuales al mostrar los favicons.
Otras novedades
- Mejoras en la p'agina about:memory para reportar el uso de memoria dedicada a las fuentes.
- Rehabilitado el valor por defecto para la organizaci'on de las fuentes mediante Graphite2.
- Mejorado el rendimiento en sistemas Windows y OS X que no cuentan con aceleraci'on por hardware.
- Varias correcciones de seguridad.
Si prefieres ver la lista completa de novedades, puedes llegarte hasta las notas de lanzamiento (en ingl'es).
Puedes obtener esta versi'on desde nuestra zona de Descargas en espa~nol e ingl'es para Android,
As Brian Krebs is discovering, a large number of internet-connected devices with bad security can really ruin your day. Therefore, a lot of energy is being spent thinking about how to solve the security problems of the Internet of Things. Most of it is focussed on how we can make sure that these devices get regular security updates, and how to align the incentives to achieve that. And it’s difficult, because cheap IoT devices are cheap, and manufacturers make more money building the next thing than fixing the previous one.
Perhaps, instead, of trying to make water flow uphill, we should be taking a different approach. How can we design these devices such that they don’t need any security updates for their lifetime?
One option would be to make them perfect first time. Yeah, right.
Another option would be the one from my blog post, An IoT Vision. In that post, I outlined a world where IoT devices’ access to the Internet is always mediated through a hub. This has several advantages, including the ability to inspect all traffic and the ability to write open source drivers to control the hardware. But one additional outworking of this design decision is that the devices are not Internet-addressable, and cannot send packets directly to the Internet on their own account. If that’s so, it’s much harder to compromise them and much harder to do anything evil with them if you do. At least, evil things affecting the rest of the net. And if that’s not sufficient, the hub itself can be patched to forbid patterns of access necessary for attacks.
Can we fix IoT security not by making devices secure, but by hiding them from attacks?
http://feedproxy.google.com/~r/HackingForChrist/~3/FNdZrZ-877Y/
One of my roles at Mozilla is that I’m part of the Root Program team, which manages the list of trusted Certificate Authorities (CAs) in Firefox and Thunderbird. And, because we run our program in an open and transparent manner, other entities often adopt our trusted list.
In that connection, I’ve recently been the lead investigator into the activities of a Certificate Authority (CA) called WoSign, and a connected CA called StartCom, who have been acting in ways contrary to those expected of a trusted CA. The whole experience has been really interesting, but I’ve not seen a good moment to blog about it. Now that a decision has been taken on how to move forward, it seems like a good time.
The story started in late August, when Google notified Mozilla about some issues with how WoSign was conducting its operations, including various forms of what seemed to be certificate misissuance. We wrote up the three most serious of those for public discussion. WoSign issued a response to that document.
Further issues were pointed out in discussion, and via the private investigations of various people. That led to a longer, curated issues list and much more public discussion. WoSign, in turn produced a more comprehensive response document, and a “final statement” later.
One or two of the issues on the list turned out to be not their fault, a few more were minor, but several were major – and their attempts to explain them often only led to more issues, or to a clearer understanding of quite how wrong things had gone. On at least one particular issue, the question of whether they were deliberately back-dating certificates using an obsolete cryptographic algorithm (called “SHA-1”) to get around browser blocks on it, we were pretty sure that WoSign was lying.
Around that time, we privately discovered a couple of certificates which had been mis-issued by the CA StartCom but with WoSign fingerprints all over the “style”. Up to this point, the focus has been on WoSign, and StartCom was only involved because WoSign bought them and didn’t disclose it as they should have done. I started putting together the narrative. The result of those further investigations was a 13-page report which conclusively proved that WoSign had been intentionally back-dating certificates to avoid browser-based restrictions on SHA-1 cert issuance.
If you can write an enthralling page-turner about f**king certificate authorities doing scuzzy nerd sh*t, damn, I couldn't pull that off.
— SwiftOnSecurity (@SwiftOnSecurity) September 28, 2016
The report proposed a course of action including a year’s dis-trust for both CAs. At that point, Qihoo 360 (the Chinese megacorporation which is the parent of WoSign and StartCom) requested a meeting with Mozilla, which was held in Mozilla’s London office, and attended by two representatives of Qihoo, and one each from StartCom and WoSign. At that meeting, WoSign’s CEO admitted to intentionally back-dating SHA-1 certificates, as our investigation had discovered. The representatives of Qihoo 360 wanted to know whether it would be possible to disentangle StartCom from WoSign and then treat it separately. Mozilla representatives gave advice on the route which might most likely achieve this, but said that any plan would be subject to public discussion.
WoSign then produced another updated report which included their admissions, and which outlined a plan to split StartCom out from under WoSign and change the management, which was then repeated by StartCom in their remediation plan. However, based on the public discussion, the Mozilla CA Certificates module owner Kathleen Wilson decided that it was appropriate to mostly treat StartCom and WoSign together, although StartCom has an opportunity for quicker restitution than WoSign.
And that’s where we are now :-) StartCom and WoSign will no longer be trusted in Mozilla’s root store for certs
Over the last few weeks I was busy recording interviews with different exciting people of the web. Now I am happy to announce that the first edition of Decoded Chats is live on the new Decoded Blog.
In this first edition, I’m interviewing Rob Conery about his “Imposter Handbook“. We cover the issues of teaching development, how to deal with a constantly changing work environment and how to tackle diversity and integration.
We’ve got eight more interviews ready and more lined up. Amongst the people I talked to are Sarah Drasner, Monica Dinculescu, Ada-Rose Edwards, Una Kravets and Chris Wilson. The format of Decoded Chats is pretty open: interviews ranging from 15 minutes to 50 minutes about current topics on the web, trends and ideas with the people who came up with them.
Some are recorded in a studio (when I am in Seattle), others are Skype calls and yet others are off-the-cuff recordings at conferences.
Do you know anyone you’d like me to interview? Drop me a line on Twitter @codepo8 and I see what I can do :)
https://www.christianheilmann.com/2016/10/18/decoded-chats-first-edition-live-on-the-decoded-blog/
Tl;dr: I just shipped
scriptworker 0.8.1 (changelog) (github) (pypi)
and
scriptworker 0.7.1 (changelog) (github) (pypi)
These are patch releases, and are currently the only versions of scriptworker that work.
scriptworker 0.8.1
The json, embedded in the Azure XML, now contains a new property, hintId. Ideally this wouldn't have broken anything, but I was using that json dict as kwargs, rather than explicitly passing taskId and runId. This means that older versions of scriptworker no longer successfully poll for tasks.
This is now fixed in scriptworker 0.8.1.
scriptworker 0.7.1
Scriptworker 0.8.0 made some non-backwards-compatible changes to its config format, and there may be more such changes in the near future. To simplify things for other people working on scriptworker, I suggested they stay on 0.7.0 for the time being if they wanted to avoid the churn.
To allow for this, I created a 0.7.x branch and released 0.7.1 off of it. Currently, 0.8.1 and 0.7.1 are the only two versions of scriptworker that will successfully poll Azure for tasks.
Due to some recent changes in the way that we use eslint to check that our coding style linting Mozilla source code in Atom has been broken for a month or two.
I have recently spent some time working on Atom's linter-eslint plugin making it possible to bring all of that linting goodness back to life!
From the root of the project type:
./mach eslint --setup
Install the linter-eslint package v.8.00 or above. Then go to the package settings and enable the following options:
Once done, you should see errors and warnings as shown in the screenshot below:
http://flailingmonkey.com/running-eslint-in-atom-for-mozilla-development/
MozFest 2016 Brown Bag - October 18th, 2016 - 16:00 London
An algorithm we’ve depended on for most of the life of the Internet — SHA-1 — is aging, due to both mathematical and technological advances. Digital signatures incorporating the SHA-1 algorithm may soon be forgeable by sufficiently-motivated and resourceful entities.
Via our and others’ work in the CA/Browser Forum, following our deprecation plan announced last year and per recommendations by NIST, issuance of SHA-1 certificates mostly halted for the web last January, with new certificates moving to more secure algorithms. Since May 2016, the use of SHA-1 on the web fell from 3.5% to 0.8% as measured by Firefox Telemetry.
In early 2017, Firefox will show an overridable “Untrusted Connection” error whenever a SHA-1 certificate is encountered that chains up to a root certificate included in Mozilla’s CA Certificate Program. SHA-1 certificates that chain up to a manually-imported root certificate, as specified by the user, will continue to be supported by default; this will continue allowing certain enterprise root use cases, though we strongly encourage everyone to migrate away from SHA-1 as quickly as possible.
This policy has been included as an option in Firefox 51, and we plan to gradually ramp up its usage. Firefox 51 is currently in Developer Edition, and is currently scheduled for release in January 2017. We intend to enable this deprecation of SHA-1 SSL certificates for a subset of Beta users during the beta phase for 51 (beginning November 7) to evaluate the impact of the policy on real-world usage. As we gain confidence, we’ll increase the number of participating Beta users. Once Firefox 51 is released in January, we plan to proceed the same way, starting with a subset of users and eventually disabling support for SHA-1 certificates from publicly-trusted certificate authorities in early 2017.
Questions about SHA-1 based certificates should be directed to the mozilla.dev.security.policy forum.
https://blog.mozilla.org/security/2016/10/18/phasing-out-sha-1-on-the-public-web/
Also on Medium, in case you want to comment.
When I first heard about Crossfit, I thought it to be an excellent idea. I still do, to be fair:
- Short, very focused and intense workouts instead of time consuming exercise schedules
- No need for expensive and complex equipment; it is basically running and lifting heavy things
- A lot of the workouts use your own body weight instead of extra equipment
- A strong focus on good nutrition. Remove the stuff that is fattening and concentrate on what’s good for you
In essence, it sounded like the counterpoint to overly complex and expensive workouts we did before. You didn’t need expensive equipment. Some bars, ropes and tyres will do. There was also no need for a personal trainer, tailor-made outfits and queuing up for machines to be ready for you at the gym.
Fast forward a few years and you’ll see that we made Crossfit almost a running joke. You have overly loud Crossfit bros crashing weights in the gym, grunting and shouting and telling each other to “feel the burn” and “when you haven’t thrown up you haven’t worked out hard enough”. You have all kind of products branded Crossfit and even special food to aid your Crossfit workouts.
Thanks, commercialism and marketing. You made something simple and easy annoying and elitist again. There was no need for that.
One thing about Crossfit is that it can be dangerous. Without good supervision by friends it is pretty easy to seriously injure yourself. It is about moderation, not about competition.
I feel the same thing happened to JavaScript and it annoys me. JavaScript used to be an add-on to what we did on the web. It gave extra functionality and made it easier for our end users to finish the tasks they came for. It was a language to learn, not a lifestyle to subscribe to.
Nowadays JavaScript is everything. Client side use is only a small part of it. We use it to power servers, run tasks, define build processes and create fat client software. And everybody has an opinionated way to use it and is quick to tell others off for “not being professional” if they don’t subscribe to it. The brogrammer way of life rears its ugly head.
Let’s think of JavaScript like Crossfit was meant to be. Lean, healthy exercise going back to what’s good for you:
- Use your body weight – on the client, if something can be done with HTML, let’s do it with HTML. When we create HTML with JavaScript, let’s create what makes sense, not lots of DIVs.
- Do the heavy lifting – JavaScript is great to make complex tasks easier. Use it to create simpler interfaces with fewer reloads. Change user input that was valid but not in the right format. Use task runners to automate annoying work. However, if you realise that the task is a nice to have and not a need, remove it instead. Use worker threads to do heavy computation without clobbering the main UI.
- Watch what you consume – keep dependencies to a minimum and make sure that what you depend on is reliable, safe to use and update-able.
- Run a lot – performance is the most important part. Keep your solutions fast and lean.
- Stick to simple equipment – it is not about how many “professional tools” we use. It is about keeping it easy for people to start working out.
- Watch your calories – we have a tendency to use too much on the web. Libraries, polyfills, frameworks. Many of these make our lives easier but weigh heavy on our end users. It’s important to understand that our end users don’t have our equipment. Test your products on a cheap Android on a flaky connection, remove what isn’t needed and make it better for everyone.
- Eat good things – browsers are evergreen and upgrade continuously these days. There are a lot of great features to use to make your products better. Visit “Can I use” early and often and play with new things that replace old cruft.
- Don’t be a code bro – nobody is impressed with louts that constantly tell people off for not being as fit as they are. Be a code health advocate and help people get into shape instead.
JavaScript is much bigger these days than a language to learn in a day. That doesn’t mean, however, that every new developer needs to know the whole stack to be a useful contributor. Let’s keep it simple and fun.
Hello Mozillians!
As you may already know, last Friday – October 14th – we held a new Testday event, for Firefox 50 Beta 7.
Thank you all for helping us making Mozilla a better place – Onek Jude, Sadamu Samuel, Moin Shaikh, Suramya,ss22ever22 and Ilse Mac'ias.
A big thank you goes out to all our active moderators too!
Results:
- there were 3 verified bugs:
- all the tests performed on the New Awesome Bar and on Flash 23 were marked as PASS.
Keep an eye on QMO for upcoming events!
https://quality.mozilla.org/2016/10/firefox-50-beta-7-testday-results/
The Firefox Desktop team met yet again last Tuesday to share updates. Here are some fresh updates that we think you might find interesting:
Highlights
- The add-ons team is landing more WebExtension APIs, namely: identity, topSites, omniBox
- If you’re interested in keeping tabs on what WebExtension work is in the pipe, check out their public Trello board
- jaws and mikedeboer are working on the new theming API in the Cedar twig repository. Once ready, it will merge into mozilla-central.
- Recently landed on Cedar is the ability to set the background image of about:home
- In an effort to reduce e10s tab switch spinners, billm landed a patch that lets us pause GCs to force a paint
- ddurst happily reports that Nightly is currently blocking all NPAPI plugins except for Flash!
- This is done behind a pref, which will be disabled for ESR 52, but enabled for release 52. In the next cycle, the pref will be removed and this will be hardcoded.
- ddurst also reports that the stub installer will soon be able to install 64-bit versions of Firefox on supported systems
- nhnt11 has returned from his time off, and will now continue his captive portal work!
Contributor(s) of the Week
- adamg2 helped to make the Histograms.json parser more bulletproof!
- Ajay freed us all from some unnecessary code within Telemetry!
- Saad fixed a bug in the AwesomeBar that would occur if a hex code was put in as an address!
- Thau~a Silveira added a new Telemetry probe so that we can get a sense of how often people abort print jobs!
Project Updates
Context Graph
- tobyelliot reports that the Recommendation Engine Experiment has gathered over 2000 volunteer participants
Electrolysis (e10s)
- mconley has landed a patch that will annotate hangs that occur in the main thread in the content process during tab switch
- This should give the team important clues on what kinds of things are causing tab switch spinners
- mrbkap has started an etherpad the brainstorm ways in which e10s-multi might accidentally break some add-ons
Platform UI
- MSU students continue to improve the
- seanlee is working on making the autocomplete popup for logins warn you if the form you’re submitting is insecure
- jessica’s patch to add the layout for has landed in Nightly, and scottwu’s
Because software defaults matter, we have just changed the default bookmarks for the Nightly channel to be more useful to power-users deeply interested in day to day progress of Firefox and potentially willing to help Mozilla improve their browser through bug and crash reports, shared telemetry data and technical feedback.
Users on the Nightly channels had the same bookmarks than users on the release channel, these bookmarks target end-users with limited technical knowledge and link to Mozilla sites providing end-user support, add-ons or propose a tour of Firefox features. Not very compelling for a tech-savvy audience that installed pre-alpha software!
As of last week, new Nightly users or existing Nightly users creating a new profile have a different set of bookmarks that are more likely to meet their interest in the technical side of Mozilla and contributing to Firefox as an alpha tester. Here is what the default bookmarks are:
There are links to this blog of course, to Planet Mozilla, to the Mozilla Developer Network, to the Nightly Testers Tools add-on, to about:crashes and to the IRC #nightly channel in case you find a bug and would like to talk to other Nightly users about it and of course a link to Bugzilla. The Firefox tour link was also replaced by a link to the contribute page on mozilla.org.
It’s a minor change to the profile data as we don’t want to make of Nightly a different product from Firefox, but I hope another small step in the direction of empowering our more technical user base to help Mozilla build the most stable and reliable browser for hundreds of millions of people!
https://blog.nightly.mozilla.org/2016/10/17/better-default-bookmarks-for-nightly/