Instead of showing the user an alert that something might not work, maybe we can build a smarter algorithm. Instead of asking the user to make a choice up front, maybe we can set a smart default and see if there is high demand after launch for more customization.
— Rebecca Rolfe on the Google Chrome team, interviewed in The Badass Women of Chrome’s Security Team in Refinery29.
(More on making decisions, not options.)
The need for effective government services is rising, while confidence in our ability to deliver them is dropping. More than ever, day-to-day interactions with government are powered by digital systems, and yet far too many Federal IT projects arrive late or over budget. Others are simply abandoned. These failures are often felt by those who count on it most — working class Americans and people who turn to government in a moment of need.
The U.S. Digital Service on whitehouse.gov
When you’re presented with an opportunity to help transform how the federal government works for the American people, it’s really hard to say no.
For five years and counting, I’ve had the honor and privilege as a lead developer of WordPress to play a role in a large, incredible movement to democratize publishing. From my home in D.C., I’ve closely watched open data and open government efforts. I feel very strongly about an open, transparent, and efficient government — boosted in no small part by WordPress and open source.
I’ve long admired a number of my new teammates, especially Erie Meyer, Gray Brooks, and Haley van Dyck, for years of tenacity and hard work trying to change government from the inside out. I’ve always felt I could be more effective helping government from the outside, by continuing to work on WordPress. After all, we’ve all heard horror stories of all sorts of red tape, from hiring to procurement and everything in between. And we’ve all heard how difficult government itself makes it to launch good government digital services. While many of us may have have wanted to help, few thought they could. Fewer knew how.
But then the U.S. Digital Service was formed, from the team that helped rescue healthcare.gov. It’s dedicated to tackling some of government’s most pressing problems, ones that directly affect millions of people’s lives. The formula is simple: take what helped turn around healthcare.gov and apply it to other high priority projects across government.
In this day and age, public policy must be backed by effective technology to succeed. The American people need our help and our government has asked us to serve, as doers and makers, creative thinkers, and specialized technologists dedicated to untangling, rewiring, and redesigning our government.
In January, I joined the U.S. Digital Service.
When I was approached, I have to admit that I was nervous to step back from the day-to-day buzz of WordPress because I’ve invested so much. But the community stepped up, in most cases not even knowing about my life change. That’s the beauty of open source, and the fantastic WordPress community in particular. WordPress continues to play an important role in my life. With Matt Mullenweg’s support and encouragement, I’m taking time away from Audrey, where I’ve worked since 2010. I’m still actively involved in the project, just not full time.
The U.S. Digital Service is the real deal. I’ve been astounded by the impact we’ve already made. We’ve recruited some of the best and brightest. Don’t just take my word for it — do what you can to learn more about this movement and come help us make government better. If you haven’t seen the video below yet, take a look. (A few of you have noticed me in the background.)
It’s my nature to look for the hardest problems to solve. I like to take on big challenges and spend every ounce of energy working to solve them. I believe in what we’re doing here. The stakes are high. No matter the challenge, I know what we’re doing will change millions of lives.
I thought I had made the most of my decade in D.C. I’ve witnessed a lot of history. I knew I’d have some great stories to tell my future kids and grandkids. I was there. I saw it. That was only the beginning.
I pay for 105 Mbps of downstream Internet from Comcast, and I get just 6 Mbps every evening.
I’ve been running speed tests for weeks now. It looks like this every time:
I put a sizable hole in my wallet every month for “Blast” internet. Comcast even upgraded “Blast” from 50 Mbps to 105 Mbps recently, but each evening, I might as well be using their 6 Mbps “Performance Starter.” When I actually want to use anything close to the speeds they charge me for, I can’t.
Please, Comcast, tell me how you’re going to blame Netflix for this one.
Please, Comcast, tell me again you can send a technician but only during business hours, when my Internet works fine.
Please, Comcast, tell me how you’re going to charge me more.
Please, Comcast, tell me how net neutrality would stifle “innovation” and discourage you from “investing” in infrastructure.
And please, Comcast, tell me how that would be any different from the status quo.
As a software vendor, there are many reasons to prefer responsible disclosure of security issues. But the most important reason is also less obvious: vulnerability reports need to be correct.
I’ve seen countless “full disclosure” reports that are wrong and invalid. Most of these could have been prevented by privately disclosing it to the vendor and allowing them the opportunity to respond.
Everyone sees WordPress in the headlines, over and over again, but no one ever notices the “this report is invalid” response. We’ve prevented countless invalid reports from being published simply because they were disclosed to us first. This is better for the software’s users, who are otherwise left to scramble every time they see a report. They are not an expert, and often, neither is the reporter.
There’s another angle here, though: sometimes, the vulnerability report is correct, but incomplete. This too can send everyone scrambling, starting with the vendor who was not given the opportunity to straighten things out.
When responsible disclosure works, it works really well. I offer Jetpack’s recent vulnerability as a recent case study. While this was discovered internally at Automattic, the effect is the same: they were able to quickly and thoroughly investigate the issues and follow through with a plan of action. During their investigation they learned the problem was far more severe than they originally identified, and that their initial proposed fix was incomplete.
There will always be individuals who want everything to be fully disclosed, and there are some great arguments for that. I’m not trying to sway you one way or the other. But if you’re trying to do the right thing — you’re doing full disclosure in the interest of users, possibly even providing a patch or steps to mitigate — working with the vendor is a good way to ensure you haven’t missed anything.
I’m not sure how many times now I’ve responded to a mailing list saying, “well, this isn’t a vulnerability,” or “your proposed patch is incomplete,” or “your patch makes it worse.” Or when I don’t respond to the mailing list because my thought is This is worse than the reporter realizes.
Security is nuanced.
Last week, a security researcher disclosed some issues with WordPress. They stated that WordPress issues a cookie in plain HTTP that identifies the user. Correct. They also stated that this cookie does not expire when the user logs out. Also correct.
She went on to state that the cookie has a lifetime of 3 years, that it can be used to mess with the account’s two-factor authentication settings, and change their email and other settings. She followed that up with “have notified them and waited 24hrs for response, none yet. guessing it’s a wontfix for now, since their SSL support is patchy.”
Yes, absolutely, SSL support in WordPress is patchy. (Coincidentally, fixing all of this was already slated for the next major release.) While you can force SSL for the dashboard, we don’t have the concept of forcing SSL for the front-end of the site. So, that “logged in” cookie is issued over plain HTTP. It’s trivial in a plugin to force that cookie to be secure, but of course most users aren’t going to do that. Of course, most users also aren’t using SSL (sadly).
WordPress also doesn’t have any concept of session management. The user is authenticated and a cookie is issued, but there’s no way for it to be automatically invalidated upon logout (without you changing your password). Changing this is a major architectural change we’ve been planning for some time. But this is also why cookies are designed with a limited expiration: just 48 hours, or 14 days if you click “Remember me.”
But the report was that it didn’t expire for three years, right? This is where it gets a bit weird. I’d love it if “Remember me” remembered you for 30, 90, or even 365 days, but WordPress will wait to make any changes until cookies can be invalidated. Some time ago, though, WordPress.com configured this cookie to last for three years.
Normally, this wouldn’t be that bad. You see, the “logged in” cookie is relatively harmless. It allows presentational things like the toolbar, edit links in your theme, and such. But you can’t use it to manage your account, change your email, or do anything particularly crazy. In fact, WordPress issues a separate, secure “auth” cookie used for the “wp-admin” dashboard. It’s like Amazon knowing who you are after six months of not being on the site, but asking you to log in when you start to check out.
On WordPress.com, however, a lot of settings can be managed outside of the dashboard, on their “new dashboard,” at wordpress.com/settings/. As you might have guessed by now, they were not requiring the “auth” cookie on this page, only the “logged in” cookie. That is the true critical vulnerability here. A number of decisions came together to make a latent issue a very real one. The issue wasn’t reported like this because the reporter isn’t familiar with the intricacies of user authentication internals in WordPress, nor should anyone expect them to. Rather, an assumption was made it was a design decision that would probably just be a “wontfix” due to “patchy” SSL support.
The disclosure was well-intentioned, but because it happened within just 24 hours, Automattic wasn’t able to react quickly enough to identify the actual issue and request that it not be disclosed until they got a fix in place.
I’m just trying to set the record straight on what happened, since I keep seeing confused tweets, blog posts, comments, and Facebook chatter. (Favorite Facebook comment, after I posted a brief explanation: “Did we just open all those nesting doll layers to discover the belly was empty?”) This situation probably could have been handled better by everyone involved, but that’s not really the point. The primary issue is now handled, and other issues are also being addressed. I don’t think this requires post-mortem blog posts with a side of FUD. I’m not looking for a debate on full disclosure versus responsible disclosure. And I certainly don’t think anyone should be questioning the researcher, who has spent years dedicating herself to making the Internet more secure.
In this case, WordPress.com the service was able to react quickly to mitigate this issue for all of its users. Of course, with software, holes can’t be closed so easily, and in this case, the situation was probably exacerbated by confusing WordPress.com the service with WordPress the software. That confusion is easy to understand, especially since some of these issues have roots in the core software.
Security is nuanced.I’ve not linked to any previous posts because I don’t want this to be a criticism of any researcher or writer, but if you’re looking for background: 1 2 3. Also, related work for WordPress 4.0 is happening here.
Update, April 29: I’m excited to share that both of these proposals were accepted. See you soon, Portland!
I submitted two proposals to Open Source Bridge, an annual conference in Portland, Oregon, for “open source citizens.” The call for papers is now closed, but they let anyone leave comments on proposals that are private to the conference organizers. If you have any feedback on these, or have seen me speak before, it would be awesome if you could leave a comment. Here they are:
Writing portable software is hard. Throw in thousands of bad and worse shared hosting configurations, a decade of technical debt, the need to cater to a sprawling ecosystem, and PHP — and you have WordPress. We’ve found breaking changes harm our community and unfairly punish our users, so we don’t make them. But that doesn’t mean we don’t innovate or evolve — we’re just forced to get really clever. And it works, with adoption continuing to soar.
WordPress shipped in October what is perhaps its most polarizing feature ever — automatic updates in the background of self-hosted web software, on by default and no easy way to turn it off. In most open source communities, this would be cause for open revolt. Learn how through trust, communication, and a steadfast commitment to its philosophies, the WordPress core team convinced a skeptical community to go along, even if it meant users giving up some control.
WordPress contributors Mel Choyce and Aaron Jorbin also both submitted proposals: My Journey into Open Source Design and Modernizing a Stagnant Toolbox.