Matthew Green Explains the Juniper Backdoor

I hadn’t heard of the ScreenOS backdoor vulnerabilites, which are CVE-2015-7755 and CVE-2015-7756, until last night when I ran into some tweets about Matthew Green’s exposition on what they are and why they are so crazy:

To sum up, some hacker or group of hackers noticed an existing backdoor in the Juniper software, which may have been intentional or unintentional — you be the judge! They then piggybacked on top of it to build a backdoor of their own, something they were able to do because all of the hard work had already been done for them. The end result was a period in which someone — maybe a foreign government — was able to decrypt Juniper traffic in the U.S. and around the world.

And all because Juniper had already paved the road.

Some of his tweets on the situation explain it in even better terms IMO:

And—back to the article—on why this is important to talk about:

For the past several months I’ve been running around with various groups of technologists, doing everything I can to convince important people that the sky is falling. Or rather, that the sky will fall if they act on some of the very bad, terrible ideas that are currently bouncing around Washington — namely, that our encryption systems should come equipped with “backdoors” intended to allow law enforcement and national security agencies to access our communications.

One of the most serious concerns we raise during these meetings is the possibility that encryption backdoors could be subverted. Specifically, that a backdoor intended for law enforcement could somehow become a backdoor for people who we don’t trust to read our messages. Normally when we talk about this, we’re concerned about failures in storage of things like escrow keys. What this Juniper vulnerability illustrates is that the danger is much broader and more serious than that.

At this point, there’s no two bones about it. We need to be using encryption everywhere. And the encryption we use needs to be open source.

More VIP Open Source

At VIP, we are currently hard at work designing new platform services for our clients we think will help us take their sites to the next level of WordPress awesome. And today, my colleagues open sourced two of the tools we are using internally.

(Both of them are use on this very site, actually—because my blog has been running on our new platform as a test for some time now.)

The first is VIP Jetpack, which is a series of forced module activations and testing preparation we use with the Jetpack plugin suite for VIP Go. (Yes, this site and other sites on VIP Go always use Jetpack. No, it’s not a performance hog.)

The second is VIP Support, which we use to access client administration pages when troubleshooting a site. This ensures that we don’t always have admin access to client sites, but that we can assist when something goes wrong.

This project is so exciting for me, because we have a dedication to developing as much as we can in the open, a test-driven development process, and a peer review-heavy culture. I’m not actually generating any of the code you see in these repos, but that doesn’t mean I’m not proud of what we are accomplishing and how we are doing it.

By the way, the source used to power this site on that same platform is available here; I’m working on things in the open as well even though I don’t have much time to work on them. :)

Going GitHub

I have a handful of half-baked code ideas sitting around; often I have more ideas than I have time and/or skills to implement.

What’s different about today is that I’m finding that when I get one of these ideas, the first thing I’m doing is setting up a GitHub repo for what I want to do. (Consequently, I have two completely empty GitHub repos to my name, and one that’s a fork I haven’t worked on yet.)

The interesting thing about this is that it doesn’t ever cross my mind that I shouldn’t be sharing the code I end up making. There’s no benefit I can find to hiding what I’m doing or not learning publicly. It’s possible that someone could come across my projects and tell me that I’m doing things super-wrong, but even if that happens, at least I’ll know that I’m doing something in a less than optimal way.

And I don’t think that is going to happen, anyway. Being open is the only way to be, because no matter what I think I’m going to do, I’m pretty sure there is someone else somewhere who has wanted to do the same thing, or might be interested in the ideas I’ve had.

And when that happens, there’s a chance, no matter how small, that someone will come along and contribute to the projects. When that happens, it provides me with a chance to learn from someone who probably knows more and better than I do.

Android OEM Licensing Terms

Ron Amadeo for Ars Technica:

The agreement places a company-wide ban on Android forks, saying OEMs are forbidden from taking “any actions that may cause or result in the fragmentation of Android” and specifically disallows distributing or encouraging a third party to distribute “a software development kit derived from Android.” Google has full control over the countries its apps are released in and distribution methods used to distribute the apps. This allows Google to restrict its apps to the Play Store and will keep them out of competing stores like Amazon and Samsung. Google also stipulates that the Google apps must be distributed free of charge, and they cannot be modified, reverse engineered, or used to make a derivative work, and ads are not allowed to be placed in, on, or around Google’s apps.

But Android is “open.”


You’re in darkness—
A flash of light cracks through—
Your eyelids open, but you still see only BLACK.

The back of your skull aches, ringing like a churchbell.

Need to… need to get back…But back where?

You’re lying on your side, but strangely in motion.

If this is a hangover, it’s the worst hangover of your life.

I just finished playing a neat little self-contained text adventure called Trunked. It’s definitely a callback to the days of Infocom games, but the difference here is that this one’s entirely generated using HTML. It’s a quick play, so I’d urge you to give it a shot and see what you make of it. I died three times before reaching (an/the?) ending.

More interesting than the game itself is the toolset that was used to create it, which is called Twine and is available for Windows, OS X, and a command-line version that uses Python.

The final output is HTML, and Javascript, and is open-sourced under the GPL (github link). Fancy yourself a game designer? The tools are there, and they are free. :)

(And if you want something that’s a slightly more complicated and graphical open source game creation engine, take a look at LÖVE, a toolset for creating games using Lua.)


An announcement from the Chromium team:

WebKit is a lightweight yet powerful rendering engine that emerged out of KHTML in 2001. Its flexibility, performance and thoughtful design made it the obvious choice for Chromium’s rendering engine back when we started. Thanks to the hard work by all in the community, WebKit has thrived and kept pace with the web platform’s growing capabilities since then.

However, Chromium uses a different multi-process architecture than other WebKit-based browsers, and supporting multiple architectures over the years has led to increasing complexity for both the WebKit and Chromium projects. This has slowed down the collective pace of innovation – so today, we are introducing Blink, a new open source rendering engine based on WebKit.

Opera is also switching to Blink instead of WebKit. This is a curious move, and I’ll assume that it’s because someone wanted control over a project that they weren’t getting through WebKit’s gated commit process.

Regardless of what you think about the move (and I think I heard a noise like the sound of millions of designers rolling their eyes this afternoon), at least they are going about it the right way: forking on existing open source project and creating a new open source project of their own.

Who knows? Maybe this will spur some additional innovation with existing rendering engines to keep up with whatever improvements the Blink team makes.

And staying with open source means that if Google capriciously decides to change renderers again, it’s highly likely that Blink and Chromium won’t just die on the vine—though it appears that Chromium’s licensing is significantly more complex than WebKit’s.

Losing Google Reader

Google announced last night that they are sunsetting Google Reader on July 1:

There are two simple reasons for this: usage of Google Reader has declined, and as a company we’re pouring all of our energy into fewer products. We think that kind of focus will make for a better user experience.

By which they mean “we started cutting features from Google Reader, so fewer people enjoyed using it and ended up stopping,” and “no one was developing it anymore.” I’m also curious to see where this “better user experience” will appear. Certainly not for Google Reader. :)

Anyone who has been paying attention has seen this coming; Reader has been neglected for some time and in some cases has had features removed from it over the last couple of years. It was clearly not receiving much love. I haven’t used it in well over a year, which was sad because I lost the use of Reeder across all my devices, which I have gladly purchased three times over on all my devices.

A lot of the chatter has been about available alternatives. The big ones that I’ve seen kicked around are NewsBlur, The Old Reader, Feedly, and Fever. I’ll tell you why I use Fever and why I think that—for now—it’s the best alternative.

When it comes to the content I create, I’m really big on ownership. I have my own domain, I run on open source solution for blogging that relies on a deeper open source stack to run, and I act as my own gatekeeper. I have argued in the past that you should do the same and that the blog is still the atomic nucleus of individually-generated content on the internet.

That’s why I’m using Fever. If there were an open source alternative that were just as easy to set up and configure, offered a robust API, had at least some of the same features, and ran on the same stack as my WordPress installations, I would switch in a heartbeat. But for now, Fever is it. Here’s the bulleted list of things I like about it, for those of you who are in to that sort of thing:

  • Easy to set up (LAMP stack).
  • Includes a bookmarklet that leverages autodiscovery to help me add feeds without fuss.
  • Has an API that now works with Reeder for iPhone to sync subscriptions (wish the iPad and iOS apps would catch up to this).
  • Has great keyboard shortcuts, including one that sends the selected article to Instapaper (my primary information flow relies on this).
  • Can be cron’d so subscriptions get updated on a schedule I like (I prefer hourly and will turn that down if I feel like it’s ruining my life).
  • Has the “What’s Hot” list, which I don’t use as often as I should, but aggregates the links that appear in all my feeds to show me what they are linking to—and helps me discover new things in the process.
  • Allows me to hide read/unread counts.
  • Allows me to add feeds just for the purpose of the aggregation feature so I can add news sources without feeling that I need to read everything they post (I prefer to aggregate things friends are talking about, anyway).
  • Includes a referrer anonymizing solution for when I go to stories that are in my reader.

And here’s the list of things I don’t like about it, in case you want to know that:

  • Not open source. (Though I don’t mind giving Shaun money. He’s a pretty cool dude.)
  • Non-cron syncing takes a long time, but that’s probably more to do with my feeds addiction.
  • Mobile browser view sucks, and it’s awful on iPad (this is the main thing that would get me to switch away). Reeder’s API syncing is what brought me back to Fever after I tried it once and dropped it to go back to Google Reader for a time.

All of the other alternatives I have listed above are hosted services. They aren’t under my control. Out of all of them, I find NewsBlur the most compelling and the option that appears to have the greatest chance of success as a Google Reader alternative.

NewsBlur is available as an open source DIY project, but the instructions for it are more work than most humans are willing to undertake to set up something on their own, and I’ll bet that a lot of hosts wouldn’t support it based on its requirements. I’d love for someone to tell me there’s an easy way to set it up on Webfaction, because my wife is now looking for a Reader alternative and something that supports more than one of us at a time would be great.

The most important thing I can say is that if you are/were a Google Reader user, please take a look at the alternatives that are available and use one. RSS is still out there, and you should use it: it’s a robust, open solution to aggregating content. If everyone stops using it, there’s always the danger that it will stop being supported by even more services and eventually disappear completely.

If that happens, then the alternatives won’t matter.