Tagged: mozilla

An Explanation of the Heartbleed bug for Regular People

I’ve put this explanation together for those who want to understand the Heartbleed bug, how it fits into the bigger picture of secure internet browsing, and what you can do to mitigate its affects.

HTTPS vs HTTP (padlock vs no padlock)

When you are browsing a site securely, you use https and you see a padlock icon in the url bar. When you are browsing insecurely you use http and you do not see a padlock icon.

Firefox url bar for HTTPS site (above) and non-HTTPS (below).
Firefox url bar for HTTPS site (above) and non-HTTPS (below).

HTTPS relies on something called SSL/TLS.

Understanding SSL/TLS

SSL stands for Secure Sockets Layer and TLS stands for Transport Layer Security. TLS is the later version of the original, proprietary, SSL protocol developed by Netscape. Today, when people say SSL, they generally mean TLS, the current, standard version of the protocol.

Public and private keys

The TLS protocol relies heavily on public-key or asymmetric cryptography. In this kind of cryptography, two separate but paired keys are required: a public key and a private key. The public key is, as its name suggests, shared with the world and is used to encrypt plain-text data or to verify a digital signature. (A digital signature is a way to authenticate identity.) A matching private key, on the other hand, is used to decrypt data and to generate digital signatures. A private key should be safeguarded and never shared. Many private keys are protected by pass-phrases, but merely having access to the private key means you can likely use it.

Authentication and encryption

The purpose of SSL/TLS is to authenticate and encrypt web traffic.

Authenticate in this case means “verify that I am who I say I am.” This is very important because when you visit your bank’s website in your browser, you want to feel confident that you are visiting the web servers of — and thereby giving your information to — your actual bank and not another server claiming to be your bank. This authentication is achieved using something called certificates that are issued by Certificate Authorities (CA). Wikipedia explains thusly:

The digital certificate certifies the ownership of a public key by the named subject of the certificate. This allows others (relying parties) to rely upon signatures or assertions made by the private key that corresponds to the public key that is certified. In this model of trust relationships, a CA is a trusted third party that is trusted by both the subject (owner) of the certificate and the party relying upon the certificate.

In order to obtain a valid certificate from a CA, website owners must submit, at minimum, their server’s public key and demonstrate that they have access to the website (domain).

Encrypt in this case means “encode data such that only authorized parties may decode it.” Encrypting internet traffic is important for sensitive or otherwise private data because it is trivially easy eavesdrop on internet traffic. Information transmitted not using SSL is usually done so in plain-text and as such clearly readable by anyone. This might be acceptable for general internet broswing. After all, who cares who knows which NY Times article you are reading? But is not acceptable for a range of private data including user names, passwords and private messages.

Behind the scenes of an SSL/TLS connection

When you visit a website with HTTPs enabled, a multi-step process occurs so that a secure connection can be established. During this process, the sever and client (browser) send messages back and forth in order to a) authenticate the server’s (and sometimes the client’s) identity and, b) to negotiate what encryption scheme, including which cipher and which key, they will use for the session. Identities are authenticated using the digital certificates mentioned previously.

When all of that is complete, the secure connection is established and the server and client send traffic back and forth to each other.

All of this happens without you ever knowing about it. Once you see your bank’s login screen the process is complete, assuming you see the padlock icon in your browser’s url bar.

Keepalives and Heartbeats

Even though establishing an ssl connection happens almost imperceptibly to you, it does have an overhead in terms of computer and network resources. To minimize this overhead, network connections are often kept open and active until a given timeout threshold is exceed. When that happens, the connection is closed. If the client and server wish to communicate again, they need to re-negotiate the connection and re-incur the overhead of that negotiation.

One way to forestall a connection being closed is via keepalives. A keepalive message is used to tell a server “Hey, I know I haven’t used this connection in a little while, but I’m still here and I’m planning to use it again really soon.”

Keepalive functionality was added to the TLS protocol specification via the Heartbeat Extension. Instead of “Keepalives,” they’re called “Heartbeats,” but they do basically the same thing.

Specification vs Implementation

Let’s pause for a moment to talk about specifications vs implementations. A protocol is a defined way of doing something. In this case of TLS, that something is encrypted network communications. When a protocol is standardized, it means that a lot of people have agreed upon the exact way that protocol should work and this way is outlined in a specification. The specification for TLS is collaboratively developed, maintained and promoted by the standards body Internet Engineering Task Force (IETF). A specification in and of itself does not do anything. It is a set of documents, not a program. In order for a specifications to do something, they must be implemented by programmers.

OpenSSL implementation of TLS

OpenSSL is one implementation of the TLS protocol. There are others, including the open source GnuTLS as well as proprietary implementations. OpenSSL is a library, meaning that it is not a standalone software package, but one that is used by other software packages. These include the very popular webserver Apache.

The Heartbleed bug only applies to webservers with SSL/TLS enabled, and only those using specific versions of the open source OpenSSL library because the bug relates to an error in the code of that library, specifically the heartbeat extension code. It is not related to any errors in the TLS specification or and in any of the underlying ciper suites.

Usually this would be good news. However, because OpenSSL is so widely used, particularly the affected version, this simple bug has tremendously reach in terms of the number of servers and therefor the number of users it potentially affects.

What the heartbeat extension is supposed to do

The heartbeat extension is supposed to work as follows:

  • A client sends a heartbeat message to the server.
  • The message contains two pieces of data: a payload and the size of that payload. The payload can by anything up to 64kb.
  • When the server receives the heartbeat message, it is to add a bit of extra data to it (padding) and send it right back to the client.

Pretty simple, right? Heartbeat isn’t supposed to do anything other than let the server and client know they are each still there and accepting connections.

What the heartbeat code actually does

In the code for affected versions (1.0.1-1.0.1f) of the OpenSSL heartbeat extension, the programmer(s) made a simple but horrible mistake: They failed to verify the size of the received payload. Instead, they accepted what the client said was the size of the payload and returned this amount of data from memory, thinking it should be returning the same data it had received. Therefore, a client could send a payload of 1KB, say it was 64KB and receive that amount of data back, all from server memory.

If that’s confusing, try this analogy: Imagine you are my bank. I show up and make a deposit. I say the deposit is $64, but you don’t actually verify this amount. Moments later I request a withdrawal of the $64 I say I deposited. In fact, I really only deposited $1, but since you never checked, you have no choice but to give me $64, $63 of which doesn’t actually belong to me.

And, this is exactly how a someone could exploit this vulnerability. What comes back from memory doesn’t belong to the client that sent the heartbeat message, but it’s given a copy of it anyway. The data returned is random, but would be data that the OpenSSL library had been storing in memory. This should be pre-encryption (plain-text) data, including your user names and passwords. It could also technically be your server’s private key (because that is used in the securing process) and/or your server’s certificate (which is also not something you should share).

The ability to retrieve a server’s private key is very bad because that private key could be used to decrypt all past, present and future traffic to the sever. The ability to retreive a server’s certificate is also bad because it gives the ability to impersonate that server.

This, coupled with the widespread use of OpenSSL, is why this bug is so terribly bad. Oh, and it gets worse…

Taking advantage of this vulnerability leaves no trace

What’s worse is that logging isn’t part of the Heartbeat extension. Why would it be? Keepalives happen all the time and generally do not represent transmission of any significant data. There’s no reason to take up value time accessing the physical disk or taking up storage space to record that kind of information.

Because there is no logging, there is no trace left when someone takes advantage of this vulnerability.

The code that introduced this bug has been part of OpenSSl for 2+ years. This means that any data you’ve communicated to servers with this bug since then has the potential to be compromised, but there’s no way to determine definitively if it was.

This is why most of the internet is collectively freaking out.

What do server administrators need to do?

Server (website) administrators need to, if they haven’t already:

  1. Determine whether or not their systems are affected by the bug. (test)
  2. Patch and/or upgrade affected systems. (This will require a restart)
  3. Revoke and reissue keys and certificates for affected systems.

Furthermore, I strongly recommend you enable Perfect forward secrecy to safeguard data in the event that a private key is compromised:

When an encrypted connection uses perfect forward secrecy, that means that the session keys the server generates are truly ephemeral, and even somebody with access to the secret key can’t later derive the relevant session key that would allow her to decrypt any particular HTTPS session. So intercepted encrypted data is protected from prying eyes long into the future, even if the website’s secret key is later compromised.

What do users (like me) need to do?

The most important thing regular users need to do is change your passwords on critical sites that were vulnerable (but only after they’ve been patched). Do you need to change all of your passwords everywhere? Probably not. Read You don’t need to change all your passwords for some good tips.

Additionally, if you’re not already using a password manager, I highly recommend LastPass, which is cross-platform and works on pretty much every device. Yesterday LastPass announced they are helping users to know which passwords they need to update and when it is safe to do so.

If you do end up trying LastPass, checkout my guide for setting it up with two-factor auth.

Further Reading


If you like visuals, check out this great video showing how the Heartbleed exploit works.

If you’re interested in learning more about networking, I highly recommend Ilya Grigorik‘s High Performance Browser Networking, which you can also read online for free.

If you want some additional technical details about Heartbleed (including actual code!) checkout these posts:

Oh, and you can listen to Kevin and I talk about Heartbleed on In Beta episode 96, “A Series of Mathy Things.”

Conclusion

On Brendan Eich as CEO of Mozilla

Today Mozilla announced a number of leadership changes, including the appointment of Brendan Eich as CEO. Amid the analysis of the change, there is a lengthy post on Hacker News specifically discussing Brendan’s support of anti-LGBT Prop. 8 in 2008 and whether or not it affects his suitability as CEO.

As a single employee of Mozilla, I am not sure I can definitively determine Brendan’s suitability. I can, however, give insight as to what I experience at Mozilla as a queer woman and how I feel about the appointment.

Mozilla is a very unique organization in that it operates in a strange hybrid space between tech company and non-profit. There simply aren’t a lot of models for what we do. Wikimedia Foundation is always the one that comes closest to mind for me, but remains a very different thing. As such, people with experience relevant Mozilla, relevant enough to lead Mozilla well, are in very short supply. An organization can always choose to make an external hire and hope the person comes to understand the culture, but that is a risky bet. Internal candidates who have demonstrated they get the culture, the big picture of where we need to go and have demonstrated they can effectively lead large business units, on the other hand, present as very strong options.

And, from my limited vantage point, that’s what I see in Brendan.

Like a lot of people, I was disappointed when I found out that Brendan had donated to the anti-marriage equality Prop. 8 campaign in California. It’s hard for me to think of a scenario where someone could donate to that campaign without feeling that queer folks are less deserving of basic rights. It frustrates me when people use their economic power to further enshrine and institutionalize discrimination. (If you haven’t seen it, here’s Brendan’s response to the issue.)

However, during the intervening years, I’ve spent a lot of time navigating communities like Mozilla and figuring out how to get things done. I’ve learned that it’s hard working with people but that you have to do it anyway. I’ve learned that it can be even harder to work with someone when you think you don’t share your fundamental beliefs, or when you think they hold opposing or contradictory beliefs, but you have to do that sometimes, too.

The key is to figure out when it’s important to walk away from interacting with a person or community because of a mis-alignment in beliefs and when you need to set aside the disagreement and commit to working together in service of the shared goal. Context is really important here. What is the purpose or mission of the community? Who is its audience? What are its guiding principles?

Mozilla’s mission is “to promote openness, innovation & opportunity on the Web.” Our audience is the global community of people connecting to the internet. Our guiding principles are numerous, but include protecting the internet as a public resource and upholding user privacy, security and choice.

At the same time, many Mozillians are themselves advocates for human rights, animal rights, prison abolition, marriage equality, racial equality, etc. As much as some of those causes might overlap with the cause of a free and open internet, they are separate causes and none of them are the focus of Mozilla the organization. Focus is important because we live in a world of limited resources. Mozilla needs to stay focused on the mission we have all come together to support and move forward.

Another factor to consider: What is their behavior within the community, where we have agreed to come together and work towards a specific mission? How much does a person’s behavior outside the scope of community affect the community itself? Does the external behavior conflict directly with the core mission of the organization?

To be clear, I’m personally disappointed about Brendan’s donation. However, aside from how it affected me emotionally, I have nothing to indicate that it’s materially hurt my work within the Mozilla community or as a Mozilla employee. Mozilla offers the best benefits I have ever had and goes out of its way to offer benefits to its employees in same-sex marriages or domestic partnerships on par with those in heterosexual marriages. Last year we finally got trans-inclusive healthcare. We didn’t have an explicit code of conduct when I started, but adopted the guidelines for participation within my first year. Progress might be slow, but it’s being made. And I don’t see Brendan standing in the way of that.

Certainly it would be problematic if Brendan’s behavior within Mozilla was explicitly discriminatory, or implicitly so in the form of repeated microagressions. I haven’t personally seen this (although to be clear, I was not part of Brendan’s reporting structure until today). To the contrary, over the years I have watched Brendan be an ally in many areas and bring clarity and leadership when needed. Furthermore, I trust the oversight Mozilla has in place in the form of our chairperson, Mitchell Baker, and our board of directors.

It’s true there might be a kind of collateral damage from Brendan’s actions in the form of some people withdrawing from participation in Mozilla or never joining in the first place. There’s a lot I could say about people’s responses to things that happen at Mozilla, but I’ll save those for another time.

For now, I’ll just say that if you’re queer and don’t feel comfortable at Mozilla, that saddens me and I’m sorry. I understand where you’re coming from, at least in part, because I had a rocky start at Mozilla and often questioned my fit in the community. That’s why I’m putting considerable effort into changing how we interact with and support contributors from marginal groups. If you want to join me, look at what we’re doing with the Education Working Group and then get in touch.

To conclude, what I offer to my fellow Mozillians, including Brendan, is this:

  • I respect that you have a private life, including interactions in other communities, that may not match my beliefs or may even conflict with them.
  • I recognize that despite possible differences in our personal beliefs, you are just as committed as I am to Mozilla’s mission and have a lot to offer the community.
  • I agree, and ask you to do the same, to set aside those differences to create a shared space in which we can work together on the Mozilla mission.
  • In that space, we’ll treat each other as human beings, following the participation guidelines, even if doing so will stretch our skills and make us slightly uncomfortable.
  • We agree to communicate with honesty and empathy and to find ways to support each other’s work in the project.

Update 28 March 2014 8:30 PDT:

Since Monday, Brendan and Mitchell have both published responses, which I’ve included below. I’ve also included posts from some colleagues.

Update 30 March 2014 15:45 PT:

Some additional posts from colleagues:

Joining the Community Building Team at Mozilla

Grow Mozilla

After almost a year and a half on the Technical Evangelism team, my role at Mozilla is changing. As of March 3rd, I am the Education Lead on the recently formed Community Building Team (CBT) led by David Boswell.

The purpose of the CBT is to empower contributors to join us in furthering Mozilla’s mission. We strive to create meaningful and clear contribution pathways, to collect and make available useful data about the contribution life-cycle, to provide relevant and necessary educational resources and to help build meaningful recognition systems.

As Education Lead, I’ll drive efforts to: 1) identify the education and culture-related needs common across Mozilla, and b) to develop and implement strategies for creating and maintaining these needs. Another part of my role as Education Lead will be to organize the Education and Culture Working Group as well as the Wiki Working Group.

Community Building Team, March 2014 in SF
Community Building Team, March 2014 in SF

I’m super excited to be joining Dino Anderson, David Boswell, Michelle Marovich, Pierros Papadeas, William Quiviger, and Larissa Shapiro and for community building to be a recognized, full-time aspect of my job at Mozilla.

If I had been working with you on Firefox OS App localization and you still have questions, let me know or email appsdev@mozilla.com.

VidyoDesktop 2.2.x on Linux with PulseAudio 4.0 (Ubuntu 13.10)

Recently I upgraded my work laptop from Xubuntu 13.04 to 13.10. The upgrade went well, except for an issue with audio output from VidyoDesktop. Every other application worked fine. Skype, audio from Flash inside both Firefox and Chromium, gmusicbrower, Rhythmbox, and the system sounds all performed as expected.

After spending a day spelunking the depths of PulseAudio, a co-worker pointed me to this bug report which links to this blog post about making Skype compatible with changes in PulseAudio 4.0.

I confirmed that manually starting Vidyo with the following command re-enabled audio:

PULSE_LATENCY_MSEC=60 VidyoDesktop

And then modified the Exec line in /etc/xdg/autostart/vidyo-vidyodesktop.desktop to this:

Exec=env PULSE_LATENCY_MSEC=60 VidyoDesktop -AutoStart

The non-autostart menu file (/usr/share/applications/vidyo-vidyodesktop.desktop) just needs the following:

Exec=env PULSE_LATENCY_MSEC=60 VidyoDesktop

We’re using version 2.2.x of the VidyoDesktop client, which I believe has been superseded and so you may not need this fix at if you use a later client version.

Notes from Code for America Summit session on “Localization: Benefits & Challenges”

Day three of this year’s Code for America Summit followed an unconference format. Luke Crouch and I facilitated a session called “Localization: Benefits & Challenges.” During the session, each of us talked about why we find localization a valuable and beneficial activity, challenges to localization and brain-stormed tools and solutions.

Here are our notes. If you’re working on localization/internationalization in open source projects, especially mobile web apps, I’d love to hear from you!

Why localize?

  • greatest need for access to info is often non-english speaking
  • human needs are language agnostic, services should be as well
  • incorporating all perspectives requires crossing languages
  • empower cross-cultural understanding

What needs L10n?

  • websites
  • documentation
  • knowledge bases
  • phone trees
  • SMS
  • forums
  • social media
  • print media

Challenges

  • keeping content up to date
  • maintaining parity with english-language content
  • machine translation vs human translation
  • quality assurance
  • analytics
  • keeping entire loop translated / fractured experiences
  • cost
  • selecting and prioritizing languages
  • fonts / non-roman alphabets
  • right-to-left languages and user interactions
  • partnership building takes time
  • determining best practices
  • trust between communities?
  • socio-political context

Solutions

Note: Internationalization (I18n) is the process of preparing a project for localization. Localization (L10n) is the process of translating content.

Approaches

  • have users be translators
  • concentrate on building local communities
  • *listen* to needs of users. what do they need translated?
  • user interface vs content
  • platforms & tools address user interface
  • content is trickier: micro-sites, data stores, other?

Tools (libraries for L10n)

Platforms (for collecting/managing translations)

Action items moving forward

  • establish best practices
  • create a turn-key process and/or technology stack
  • organized translation camps

“One-thing” takeaways

Unconference facilitators asked each member of the session to provide a “one-thing” take-away from the session.

  • Localization is not just an international issue
  • Frame of reference for doing localization
  • Localization is solvable and urgent
  • We can work together right now to make this better

Why I Go to Conferences

Usually by 9pm on a given evening, I am winding down, feeling introspective and generally not chatty. However, this Sunday evening I had just arrived home after attending PyCon in Santa Clara, California. Upon realizing I was talking Sherri’s ears off, I stopped to ask, “Am I always like this after I get home from a conference.” The answer was a definitive: “Yes.”

It got me thinking about about why I go to conferences.

Not For the Technical Content

Perhaps this is heretical to say, but for whatever reason, it’s really difficult for me to learn technical topics deeply at conferences. I learn best in environments where I can minimize distractions, go at my own pace and engage one on one with my subject matter and instructor.  Conference learning is the antithesis of this: tons of distractions, the speakers set the pace and the learning is one to many, even in the smallest sessions and tutorials.

This does not mean that I get nothing from technical talks. Some are very inspiring and give me ideas of subjects to look up and study later, when I get home.

For the Community

Conferences connect me with community, and that is their most important offering. Over the years, I have found there is simply no substitute for time spent with people in real spaces.

Don’t misunderstand me. I love that our world is made smaller by technology. I love that I can work for Mozilla remotely using Skype, Vidyo, IRC and other internet-based technologies. I enjoy the convenience of being able to attend local planning meetings without leaving my home. It’s allowed me to continue participating even though my family obligations have increased substantially over the last year.

But technology doesn’t provide the same sense of connection and of belonging that I get from joining the physical space of my community. At conferences I see people I never see in person except at conferences. I run into people  with whom I have trouble connecting online due to our mutually busy schedules or offset timezones. At conferences I am able to interact with whole, three dimensional persons rather than flat images or disembodied voices. Because of this, conversation itself feels as if it has greater depth and meaning.

The connections that I form and strengthen at conferences have a lasting and cumulative effect. They provide the connective agent that makes online interactions between in-person events stronger and more productive. The people that I meet at community events become my friends, colleagues, peers, managers and mentors.

Why do you go to conferences and other community events?

How to Install Firefox and Thunderbird (Including Beta, Aurora & Nightly) on Ubuntu

One of the first things I do when setting up a new machine is install Firefox, Firefox Nightly and Thunderbird Aurora. There isn’t one source for all of these programs, and I always forget where to get each of them and how to make language packs work.

This article explains how to install the various releases of Firefox and Thunderbird on Ubuntu.

Overview of Firefox Builds

At any given time, there are four builds of Firefox available:

  • Release: Highly tested, relatively bug-free and stable. This is the build most people should use.
  • Beta: Needs a few final touches, but is otherwise stable and almost ready for prime-time. This build is for those who want a preview of upcoming features and are will to put up with a few minor bugs here and there.
  • Aurora: Aurora is a pre-Beta build. It’s most stable than a nightly, but not as stable as a beta. Use this build if you want a balance of cutting-edge features and stability.
  • Nightly: The most cutting-edge build you can get. It will have the most recent features, but might not be completely stable. Use this if you have a high tolerance for bugs.

Release

The most current release of Firefox should be available in the official Ubuntu repositories for all recent versions. As of the writing of this post, release from Quantal (12.10) to Precise (11.10) have Firefox 17, which is the current release version. The official repository for Raring (13.04), not yet released, has a beta build of Firefox 18.

Moreover, Firefox comes installed by default for these versions of Ubuntu. You shouldn’t have to do anything to install it. If you’ve un-installed it for some reason, you can install it with:

sudo apt-get install firefox

UPDATE 7 Jan: A commenter mentioned Ubuntuzilla, which I did not know about before. If you’re on a version of Ubuntu prior to 11.10 and want to install the current version of Firefox, this could be a good option for you.

Beta

A group called Mozilla Team maintains a repository for Firefox Beta (as well as and Thunderbird Beta).

To install from these repositories, first you have to add the ppa:

sudo add-apt-repository ppa:mozillateam/firefox-next

For Thunderbird, the command is:

sudo add-apt-repository ppa:mozillateam/thunderbird-next

Note: if your system doesn’t have add-apt-repository for some reason, try installing python-software-properties and if that doesn’t work then try installing software-properties-common.

Then update packages and install:

sudo apt-get update
sudo apt-get install firefox

Note: You’ll notice that this package name is the same as it is in the official repository. This means that you can’t have both installed at the same time. You can ‘pin’ a package to a given source and version, allowing you to install a specific version from a specific source. But, as long as the package names are the same, they can’t be installed concurrently. You’ll have to compile and execute one version from the source if you want to do this.

(If anyone knows how to re-name packages within a PPA, let me know how in the comments.)

Aurora & Nightly

Aurora & Nightly packages are maintained by Ubuntu Mozilla Daily Build team and there is one PPA for Firefox and Thunderbird nightlies, and then two other PPAs for the Aurora versions of each.

Installing Aurora versions:

sudo add-apt-repository ppa:ubuntu-mozilla-daily/firefox-aurora
sudo add-apt-repository ppa:ubuntu-mozilla-daily/thunderbird-aurora
sudo apt-get update
sudo apt-get install firefox
sudo apt-get install thunderbird

Note: See note in previous section regarding the limitations of packages with the same name.

Installing nightlies:

sudo add-apt-repository ppa:ubuntu-mozilla-daily/ppa
sudo apt-get update
sudo apt-get install firefox-trunk
sudo apt-get install thunderbird-trunk

You’ll notice that the packages names for both Firefox and Thunderbird are appended with ‘-trunk’. This means you can install and run nightly versions along side release, beta or aurora. In fact, this is what I do. I install and use release and nightly.

Installing Locales / Language Packs

For whatever reason, I’ve had a lot of trouble getting other locales to work with Firefox on recent versions of (X)Ubuntu. I always try installing the relevant language pack from the official repository. Packages like language-pack-de and language-pack-es should install everything you need for those locales, including the language packs for Firefox. But it never works. Here’s a method I’ve found that reliably works, at lease in 12.10.

Install your desired language pack xpi from:

You’ll also need to set your preferred language for displaying pages.

  1. In Firefox, open Preferences > Content.
  2. Under Languages press Choose.
  3. If you don’t see your desired language, click Select a language to add… and add one.
  4. If this doesn’t work, open about:config and set general.useragent.locale to your desired locale.

Almost there. Firefox will select the language pack to use based on what the system language is. If you’re not sure what your locale is, type this in a prompt:

printenv LANG

In my case, I get:

en_US.UTF8

This presents a problem because I don’t want to have to change the language for my entire system just to test another locale in Firefox. Luckily, there’s a solution.

You can start Firefox from the command line and specific the LANG environmental variable:

LANG=es_ES.UTF8 firefox

If you want to change the menu and/or or launcher command, you would use:

sh -c "LANG=es_ES.UTF8 /usr/bin/firefox-trunk %u"

Troubleshooting

I tested the above procedures on Xubuntu 12.10 with both Firefox release and nightly (trunk). If you have trouble with other configurations, let me know.

If you install a language pack that renders Firefox unable to start, start it in safe mode and remove the language pack. From the command-line, issue:

firefox --safe-mode

What Keeps Me at Mozilla

Doing good is part of our code.

A friend of mine is considering an offer to work at Mozilla and asked the question “what keeps me at Mozilla?” Below is my response to them.

(Note: As a couple of colleagues have indicated in the comments, this list is very-US centric. Benefits and even ability to work for Mozilla varies by your country of citizenship/residency.)

  • Near total flexibility in working environment. I can work at home, or from our Portland space, or any of the many Mozilla offices.
  • Ability to travel and go to conferences. Different teams have different policies about this, but over the last year I have been able to go to the conferences I’ve wanted to. Plus I can book travel to the MTV/SF offices whenever I feel like I need actual face-time.
  • Good salary and benefits. I don’t know exactly how Mozilla salaries compare to other Bay Area companies, but compared to Portland they are awesome. Last year I was able to pay off my student loan debt, save 10% of my salary AND buy a house. The health insurance is pretty good (not perfect; e.g. we don’t have complete coverage for trans folks yet). Paid time-off is plentiful as well (by US standards, anyway). And, having a flexible work environment means you can use for PTO for actual vacation as opposed to running errands or going to medical appointments.
  • Relative freedom in selecting your tools. You pick your hardware and operating system. You have root on your own machine. You can request a new laptop at least every two years (some people seem to get them sooner). There are gadgets like tablets, Android and now Firefox OS phones. If you need something to get your job done, you will get it.
  • Significant choice regarding what projects you work on. That’s not to say you can work on whatever you want according to whim alone. There is oversight, and your projects need to fit within Mozilla’s high-level goals. But within your functional team, you often have a great amount of say in what you spend your day-t0-day time doing. And, if you get in a position where you’re not doing what you really want to be, there are avenues for changing that.
  • Ability to work for mission-driven, open source oriented organization. Jobs at such organizations are rare because such organizations are few in number. At Mozilla, you have the honor of working for a project that has a ton of world-wide visibility and impact. We are working on initiatives that really matter, such as keeping the web open and bringing that open web to as much as the globe as possible (with Firefox OS).
  • You will work with brilliant, driven folks. These folks far outnumber the assholes. And it’s not just employees you’ll be working with. You will become part of a global army of awesome volunteer contributors.

If that’s piqued your interest, head on over to our Careers website and see if any of the open listings interest you. Got questions? I’m happy to answer them.

Oh, and to any co-workers who are reading, free free to add your own responses to ‘what keeps you at Mozilla’ by leaving a comment.

(Photo of Firefox billboard courtesy of Fligtar.)

A Moment of Reflection on Firefox’s Birthday

8 years ago today, Mozilla released Firefox 1.0. I remember when this happened. I was 23 and working for a small technology publisher in San Francisco. Even now, I can feel the excitement I felt then at having a viable open source alternative to Internet Explorer. I was an early Firefox Affiliate and I installing it on every computer I could get access to, including all the ones at work.

Never in my wildest dreams did I think then that I’d be fortunate enough to make my living in open source, let alone working for Mozilla. Mozilla isn’t a perfect organization, and it’s been a stressful first year for me, but I’m still proud to call myself a Mozillian and look forward to being here for a long while. At least long enough so see us successfully launch FirefoxOS and hire some more women and queer people (especially in technical roles).

What about you? Where were you when Firefox 1.0 launched?

Oh, and If you’re curious about this history of the Mozilla Project, including key releases, check out this timeline.

Joining the Technical Evangelism Team at Mozilla

I’m happy to announce that next Monday, 5 November will be my first day working full-time as a technical project manager and evangelist on the Technical Evangelism team within Mozilla’s Developer Engagement group, lead by Stormy Peters.

I joined Mozilla 13 months ago as a Web Product Engineer on the Web Productions team. During that time I helped guide the successful launches of Firefox Live, Firefox Flicks, the Legacy Firefox Startpage, a re-vamped Mozilla Careers and De Todos Para Todos. I’m going to miss working day-to-day with my awesome colleagues on this team!

However, I’m also excited about what I’ll be working during the next year because I’ll be contributing to programs directly related to the launch of FirefoxOS. This includes the early adopter hardware program, and programs to engage developers in writing HTML5 apps for FirefoxOS.

If you love technical project management, consider applying for my previous role. Got questions about that or how you can get involved in FirefoxOS? Drop me a line.