Participate in supporting the Directory by adding new entries and updating existing ones. We will be on IRC in the #fsf channel on irc.freenode.org.

Tens of thousands of people visit directory.fsf.org each month to discover free software. Each entry in the Directory contains a wealth of useful information, from basic category and descriptions, to providing detailed info about version control, IRC channels, documentation, and licensing info that has been carefully checked by FSF staff and trained volunteers.

While the Directory has been and continues to be a great resource to the world for over a decade now, it has the potential to be a resource of even greater value. But it needs your help!

This week we're back to work on adding new entries to the Directory. The backlog of unapproved packages continues to dwindle, but we want to get it all the way down to zero, and keep adding more. Each new package helps to make the Directory a better resource for finding any sort of software that you may need. The Directory is one of our most visited resources, so keeping it growing ensures there's lots for all those users to see.

If you are eager to help, and you can't wait or are simply unable to make it onto IRC on Friday, our participation guide will provide you with all the information you need to get started on helping the Directory today! There are also weekly Directory Meeting pages that everyone is welcome to contribute to before, during, and after each meeting.

Participate in supporting the Directory by adding new entries and updating existing ones. We will be on IRC in the #fsf channel on irc.freenode.org.

Tens of thousands of people visit directory.fsf.org each month to discover free software. Each entry in the Directory contains a wealth of useful information, from basic category and descriptions, to providing detailed info about version control, IRC channels, documentation, and licensing info that has been carefully checked by FSF staff and trained volunteers.

While the Directory has been and continues to be a great resource to the world for over a decade now, it has the potential to be a resource of even greater value. But it needs your help!

It was 47 years ago on November 17th that Douglas Engelbart received the first patent on the computer mouse. This advent in the realm of human interface devices (HID) would open the world of computers to many new people. To this day though, a battle rages in terms of the mouse's general use: the classic battle of window managers between the mouse-less Awesome and mouse-centric Mutter. This week, the Directory theme for entries is mice as input devices, and we will be discussing HIDs in general.

If you are eager to help, and you can't wait or are simply unable to make it onto IRC on Friday, our participation guide will provide you with all the information you need to get started on helping the Directory today! There are also weekly Directory Meeting pages that everyone is welcome to contribute to before, during, and after each meeting.

Users shouldn't be forced to use nonfree software when interacting with their own government. Every user has the right to control their own computing, and the government shouldn't be forcing you to download and install proprietary software just to take advantage of its services. But when it comes to registering as an agent under the Digital Millenium Copyright Act (DMCA) in the United States, that's exactly what the government expects you to do.

Users are likely familiar with the DMCA's more draconian aspects, namely the creation of legal penalties for circumventing Digital Restrictions Management. The Free Software Foundation's Defective by Design campaign is fighting to end that nightmare and repeal that part of the law. But like many laws, it's crammed full of a wide variety of provisions, the anti-circumvention rules being only one of them.

Another piece of the law creates what are known as the safe harbor provisions. These rules set out some steps that maintainers of Web sites can take to avoid liability when a user of their site uploads potentially infringing copyrighted materials. The main provision here is that if a copyright holder finds their work on your site without their permission, they can submit a take down notice to an agent registered for your site. This agent can then remove the work, thus avoiding liability for the potentially infringing distribution. Without this safe harbor, the site maintainer could potentially be sued.

While this safe harbor rule can lead to abuse, with improper take downs, it also allows maintainers of Web sites to permit their users to share works. If the rule wasn't in place, it would be too dangerous to accept such uploads without reviewing each work -- something most Web sites can't afford to do. The Free Software Foundation takes advantage of the safe harbor provisions to ensure that we can continue to share software created and uploaded by free software developers, or to share information like that found in the Free Software Directory, or to help people organize locally via LibrePlanet.org.

As mentioned before, though, taking advantage of the safe harbor provisions requires having an agent to accept the notices. This is where the problem arises. The U.S. Copyright Office is now requiring Web site maintainers to re-register using https://www.copyright.gov/dmca-directory/ by December 31st of 2017. This site, like many others that the Copyright Office requires use of, is lousy with nonfree JavaScript. Unlike the server software you may interact with when visiting any Web site, JavaScript is actually downloaded and run on your machine. Like any proprietary software, it does not serve the user, and cannot be trusted. Users must avoid nonfree JavaScript just as they would avoid any piece of proprietary software. But if they want to continue to enjoy safe harbor provisions, they must allow this intrusion onto their computer.

The Free Software Foundation reached out to the Copyright Office with these issues, and we still hope to work out a solution with them for the long term. But with the deadline coming up, we had to fix it ourselves. We collaborated with a volunteer to develop a workaround that allows you to register using only free software. The fix requires installing two freely licensed add-ons, Register DMCA claim contacts w/o bad Javascript and Automatically reveal hidden HTML elements. These add-ons, when used with GNU LibreJS, allow anyone who needs to register as a DMCA agent to do so without loading the harmful nonfree JavaScript.

There are still a few quirks that are being hammered out. Currently you have to add alternate names by uploading a document rather than filling in a text field. The only document type that they will accept is Excel, a proprietary format, but users can create documents in that format using LibreOffice. It's not a perfect solution, but it does enable users to actually complete the entire registration process using only free software. We will also be talking with the Copyright Office about supporting better formats. That is one of the beautiful things about free software: when people see a problem and have control over their own tools, they have the power to come together and make things right.

Users have a right to control their own computing. Governments everywhere should ensure that participating in any program they provide does not require the use of nonfree software. But where governments are slow to react, we all have to work together to route around the threat of proprietary software. Here's what you can do to help:

• Spread the word to any Web site maintainers you know that they can register using free software.
• Use the add-ons to register for your own sites, and let us know you did by emailing us at licensing@fsf.org.
• Help improve GNU LibreJS.
• Support the work of the Free Software Foundation by donating or becoming a member.

Participate in supporting the Directory by adding new entries and updating existing ones. We will be on IRC in the #fsf channel on irc.freenode.org.

Tens of thousands of people visit directory.fsf.org each month to discover free software. Each entry in the Directory contains a wealth of useful information, from basic category and descriptions, to providing detailed info about version control, IRC channels, documentation, and licensing info that has been carefully checked by FSF staff and trained volunteers.

While the Directory has been and continues to be a great resource to the world for over a decade now, it has the potential to be a resource of even greater value. But it needs your help!

November 10th, 1834, a ship set sail from Valparaiso, Chile. This ship was named the H.M.S. Beagle, and on it was a very special passenger, Charles Darwin. This trip would serve as a solidifying moment for Darwin in the formation of his theories. With this event in mind, the Directory theme this week is focused on evolution. Whether it's the email client known as Evolution, or Genetic Algorithm Utility Library (GAUL), which utilizes evolutionary models to to assist in the development of code requiring genetic algorithms, we will be looking at evolution in many different forms

If you are eager to help, and you can't wait or are simply unable to make it onto IRC on Friday, our participation guide will provide you with all the information you need to get started on helping the Directory today! There are also weekly Directory Meeting pages that everyone is welcome to contribute to before, during, and after each meeting.

On Wednesday, October 25th, we received an email letting us know that an old Drupal database backup file was publicly accessible on defectivebydesign.org, a site operated by the Free Software Foundation. This backup file contained contact information and other details that should not have been public, submitted from 2007-2012.

Within minutes of receiving the report, we removed the file and started auditing defectivebydesign.org and the rest of our sites. The file did not contain any passwords or password hashes, financial information, mailing addresses, or information about users who interacted with the site without ever logging in.

On Friday, October 27th, once we were reasonably confident we understood the scope of the problem and had fixed the most urgent issues, we sent a notification email to every address that was in the database backup file. We explained what had happened, took responsibility, and apologized.

If you did not receive such an email, then your address was not in the exposed file.

The file included (from both real and spambot users' profiles):

• ~28,000 email addresses;
• contact names;
• some IP addresses associated with comments on posts;
• ~120 phone numbers;
• some information users shared about whether they participated in a particular campaign action (like a call-in), and
• timestamps of users submitting data.

While some of this information was intended by users to be public, some of it definitely was not.

I and the rest of the FSF staff are deeply sorry for this mistake. We know how important privacy is to our supporters; we fight on your behalf every day against restrictive and invasive technologies that threaten it. We also don't believe in covering up our mistakes, so we wanted to let everyone affected know as soon as possible, and then share our mistake and what we learned from it here, publicly.

Even though we are a small team, under pressure to move fast against extremely large forces, this kind of mistake is absolutely unacceptable. We have made many improvements in our security practices since 2012, and in light of this failure will be taking a deeper look at what else we need to do.

I'd also like to share some of the technical details about what happened, because in just a few minutes of searching, we found others who are making the same mistake we did.

A backup of defectivebydesign.org's Drupal database was made with the backup-migrate module in 2012, likely to assist migration of the site to a new host. We failed to delete or move that file.

In 2014, or some time before then, the directory name of our Drupal installation was manually changed as part of an upgrade. However we didn't update the part of our Apache configuration that enabled .htaccess files for specific directories. Drupal's .htaccess file normally hides files by disallowing directory indexes. The site appeared to work normally despite the disabled .htaccess file because our main Apache configuration contained functionality normally performed by that file. We also mistakenly didn't have another .htaccess file to fully disable access to the backup. As a result, the backup file was left exposed.

The documentation for backup_migrate has a "VERY IMPORTANT SECURITY NOTE" indicating that "Backup and Migrate attempts to protect backup files using a .htaccess file," which we failed to mind.

We currently don't use this module, and instead backup the site as part of our global backup procedures. We are reviewing and improving several other policies and procedures to both avoid making similar mistakes again, and to detect them should they be made. This includes, for example, deleting personal data from sites where we no longer use it or need it, and accelerating our progress toward full coverage by our centralized server configuration management system.

Thank you all for your support and trust. Our technical team can also use more hands on some of their work to help expedite improvements; if you have expertise in systems administration and are interested in volunteering some time to help, please let us know at sysadmin@gnu.org.