Alternately phrased: one malicious shitheel can destroy the work of hundreds of good people, but only if the system permits it.

One thing that I think gets glossed over in the (otherwise) excellent write-up above is that Stefanovitch’s original reckoning was correct. The project didn’t actually have one antagonist, but two. I’ll give you a hint as to the other:

I recently made my first contributions to TextSecure. For those not familiar, it’s a handle little secure messaging app that manages both SMS messages and secure push notifications. It’s one of the best examples of usable security out there for mobile, so I’m stoked to finally be able to contribute to it.

One of the many cool things about the project is that they’ve set up BitHub, an automated donations/payout service for open source projects. The service is remarkably simple in interface, allowing for donations to a pool of funds and paying out automatically for every commit. In my case, as soon as my commit landed, the equivalent of roughly 12USD landed in my BitCoin wallet. The process was transparent and painless for me.

Looking through the git history for the project, I noticed a bunch of commits that included the line:

// FREEBIE

While I couldn’t find any explicit documentation of it anywhere in the BitHub docs, it turns out that this does, as you’d expect, “donate” the commit in question. I tagged my second commit to TextSecure with FREEBIE, and sure enough, no payout resulted.

This whole mechanism is interesting for a few reasons, almost all of them having to do with usability and the API.

See, paying for open source contributions isn’t a radically new concept. There have been various attempts to make it work for years, and most of them end up looking or actually being small companies built up around various projects. Some particular projects have bug bounty systems. Others are covered by third-party bug bounty systems.

But a per-project-funded, per-commit-paying, automated donation and payout system, the API for which is almost entirely included in the existing git infrastructure is new. And what’s more, having used it now, I’m convinced it’s as close as we’ve come so far to the Correct way of doing payouts for open source contributions. Its transparency and seamless integration make it trivially usable. It can be configured to pay out or not by default, with overrides being as simple as appropriately tagging your commit. The bitcoin-based payout is so easy and quick that it’s damned near magic.

I haven’t looked into setup or configuration much, so I don’t know how much of a headache it is from an operational point of view. (I don’t know precisely where, e.g., it looked to discover the right BitCoin address, though I suspect it’s just doing a committer email lookup on CoinBase. I’m not sure what the payout mechanism would look like if I didn’t already have a CoinBase account setup or if can be setup to query identity services like OneName) But from a user’s point of view it was so easy and invisible that it would be easy to miss right up until the BTC landed in one’s wallet.

It’s this usability that makes something like BitHub a potential game changer. A zero friction way for developers to get a little payout for fixing something on a project creates a powerful new incentive for them to get over the learning curve. There’s a huge psychological difference between needing to learn a new codebase just to fix a bug or two, and learning a codebase that actively pays contributors. Especially when the actual payout mechanism involves no special setup for the dev.

In short, BitHub’s git integration, transparency, and near total lack of friction make it the best open source payment solution I’ve seen. And that’s not just a nice thing, it’s an important thing. Getting paid drives commits. Friction drives complacency. BitHub finally nails the best of both worlds for open source payments.

“Napoleon made the point when discussing the outcome of actions between his own cavalry and the Mameluke horsemen of Asia Minor. These horsemen were so good that two of them would defeat three of his cavalrymen in a minor skirmish. But in a major battle, 1,000 of his cavalry would defeat 1,500 Mamelukes. On the small scale, horsemanship was the predominant factor, but on the large scale victory would be won by the controlled and disciplined application of force. Wellington made much the same point regarding actions between his cavalry and their French opponents.

On both scales of operation skilled horsemanship and cooperative action were ingredient factors, but the balance of importance between them changed with scale. Similarly, in intelligence personal skill may be the paramount factor on the small scale, but the ability to coordinate the skills of many individuals may be predominant in large-scale operations.” – RV Jones

Heartbleed was a big friggin’ deal. And, unlike many vulnerabilities, it actually got a lot of press coverage. The press coverage was almost universally awful, but Sturgeon’s Law and the nature of modern journalism means that it couldn’t be any other way. But the high visibility and the much-discussed fact that Heartbleed had been in the code base for many years lead some to speculate that the NSA either knew of or were behind Heartbleed.

But I can almost guarantee that, whether or not they knew of it, they weren’t behind it. See, Heartbleed was too random and unreliable to be an effective tool of espionage. Anyone trying to gather targeted data from a single target or to reliably gather data on an entire population wouldn’t have any use for something that provided random chunks of server memory. They might get what they want, but it’s unlikely.

No, Heartbleed is of much more use to criminals who win no matter how much sensitive data they collect. The more the better, but they don’t care whose it is, or about ensuring that they get all of it.

Allow me an analogy. Let’s talk about fishing.

Criminals are poachers. They’re the ones that go to protected rivers and leave out baited lines at night. They collect whatever they happen to catch before morning and hope they don’t get caught. They don’t care what fish they catch, just that they get some and get away. Heartbleed is perfect for that. You’re guaranteed, with enough time and enough connections, to get some sensitive data you can use to turn a quick buck.

The NSA serves one of two roles: Captain Ahab or a commercial trawler. They either want to nail one particular fish, or want to gather up as many fish as possible. In either case, randomly distributed lines don’t do them much good. They’re not going to catch nearly enough fish and they’re probably going to miss the one or two they care about. Heartbleed doesn’t really serve their purposes.

I know, I know, it can’t be that important. It doesn’t have a sexy name or a fancy website or a cool logo or nuffin’. Bummer. But it allows for reliable, undetectable SSL interception to anyone with a man-in-the-middle position between two affected computers.

And essentially every computer that uses OpenSSL was effected until today.

To continue the analogy, CVE-2014-0224 is dragnet that allows whoever operates it to catch all the fish in a particular river. So it’s good for getting information on an entire population. And if you’re sure that the particular fish you care about will swim through that one river, then it serves the Captain Ahab use case as well.

Of course, OpenSSL isn’t the only game in town, just the biggest. There are other SSL implementations. The real litmus test will be to see if other, similar bugs are found in, e.g., GnuTLS. So far none have, that I’m aware of.

Now I should include a caveat here, that I’m not saying the NSA is behind or was aware of CVE-2014-0224. I actually think it’s highly unlikely to be their handy work, and any assertion that they did or didn’t know about it is functionally unfalsifiable and therefore not worth considering.

My point, rather, is that if the NSA does, indeed, have backdoors in major security software, this is likely the sort of thing they are: subtle bugs that they can exploit to reliably and silently neutralize the security. They have no use for the random, the detectable, or the high profile.

The NSA has no use for Heartbleed, but would kill for something like CVE-2014-0224.

As you may have heard, there’s a new security vulnerability currently effecting the Internet. It’s a damn big deal, so I wanted to write a quick overview, aimed at non-tech people, to explain what the exploit is, who can be effected, and what the potential impact will be.

Overview

Heartbleed is an exploit that effects secure websites on the Internet. Many sites that use a technology called SSL to keep customer information private and to prevent attackers from intercepting or stealing customer data. Heartbleed is a bug in the most common version of SSL, a library called OpenSSL. It allows attackers to read the memory of the effected website, potentially stealing information about other users who are using the website at the same time. Randall Munroe provides an excellent analogy to help you understand how the attack works in this XKCD comic.

The technical details are beside the point for this post, and are well covered elsewhere, but you can think of it like a hidden window that allows anyone to see what’s going on inside a website’s server, including any data it might be processing at the time.

How bad is it really?

Literally the worst security exploit the Internet has ever seen.

And worse than most people, even a lot of tech folks, realize. This exploit allows an attacker to steal information about the computer that runs a web site and also about every other user using the website at the same time. It also potentially opens up other, more targeted attacks against individual users or specific sites. It is currently undetectable and therefore largely untraceable. It is trivial to pull off. It potentially effects millions of sites.

There is a common assessment matrix, DREAD, used to assess the threat posed by a particular security vulnerability. DREAD is an mnemonic representing Damage, Reproducibility , Exploitability, Affected Users, and Discoverability. Heartbleed is the highest possible rating in all five categories and, for a few of them, is the worst bug to ever effect the web.

What can I do to stay safe?

Assume that any information you send to a website can be seen by an attacker unless and until you get confirmation from the owner of the website that the exploit is fixed. At this point a majority of sites appear to be patched and, thus, safe to use, but you shouldn’t assume that a site is safe until you confirm with the owner. When in doubt, call their customer service or tech support lines and inquire directly about Heartbleed.

DO NOT send any information you wouldn’t want to be known by the entire world to a website unless you have confirmed that the website is fixed.

Please note, this exploit effects sites that use HTTPS to secure traffic (that little lock icon you seen in the address bar of some browsers). It so severely damages the security of these websites that it makes them WORSE than normal, non-secure sites.

I used an effected website before it was patched. How fucked am I?

Unfortunately, it’s impossible to tell. It could be that no one was using the exploit at the time you were using the site. Or that they didn’t happen to read memory containing your private information. Or the server may not have had any of your information in memory at the time the attacker was using the exploit. You might be fine.

Or you might be completely hosed. The attacker might have every piece of information you’ve ever given that website, including SSN, credit card details, addresses, the contents of your middle school diary, etc.

It’s literally impossible to tell, which is part of what makes Heartbleed so insidious.

What now?

As I mentioned, a fix is available for Heartbleed and most site owners are working as fast as they can to patch their systems. Some, however, don’t really understand just how urgent this exploit is. If you don’t know if a website is safe, assume it isn’t until you hear from the site owner that they’ve fixed their systems. Don’t hesitate to call their tech support or customer service numbers. Once a website is once again safe to use, it might be a good idea to change your password.

I have more questions!

There’s tons of good info on the web about the bug. Unfortunately a lot of it is intended for a highly technical audience. If you have questions that you can’t find answers for via Google, feel free to post them to the comments and I’ll try to post non-tech answers to them to the best of my ability.

Update #1 – 2014.4.11

BDaddy in comments makes the excellent point that one way to limit damage from bugs like this is to use a different password for every website. That way, if an attacker manages to get your password for one website, they can’t use it to access your accounts on other websites. There are a number of tools and services that can help with this. I personally like LastPass, but there are a number of other solutions as well.

Additionally, I forgot to mention that it’s probably a good idea to change your passwords for websites that you use after you’ve determined that they’re patched against Heartbleed. I’ve updated the “What now?” section accordingly.

So a few times when doing HTTP work on Android, I’ve run into StrictMode Violations (SMVs hereafter) for closeable resources not being closed/finalized. An example stacktrace (yanked from this bug) looks something like this:

E/StrictMode(23606): A resource was acquired at attached stack trace but never released. See java.io.Closeable for information on avoiding resource leaks.
E/StrictMode(23606): java.lang.Throwable: Explicit termination method 'close' not called
E/StrictMode(23606): at dalvik.system.CloseGuard.open(CloseGuard.java:187)
E/StrictMode(23606): at org.apache.harmony.xnet.provider.jsse.OpenSSLSocketImpl.startHandshake(OpenSSLSocketImpl.java:371)
E/StrictMode(23606): at org.apache.harmony.xnet.provider.jsse.OpenSSLSocketImpl.getSession(OpenSSLSocketImpl.java:866)
E/StrictMode(23606): at org.apache.http.conn.ssl.AbstractVerifier.verify(AbstractVerifier.java:92)
E/StrictMode(23606): at org.apache.http.conn.ssl.SSLSocketFactory.createSocket(SSLSocketFactory.java:381)
E/StrictMode(23606): at org.apache.http.impl.conn.DefaultClientConnectionOperator.openConnection(DefaultClientConnectionOperator.java:164)
E/StrictMode(23606): at org.apache.http.impl.conn.AbstractPoolEntry.open(AbstractPoolEntry.java:164)
E/StrictMode(23606): at org.apache.http.impl.conn.AbstractPooledConnAdapter.open(AbstractPooledConnAdapter.java:119)
E/StrictMode(23606): at org.apache.http.impl.client.DefaultRequestDirector.execute(DefaultRequestDirector.java:360)
E/StrictMode(23606): at org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:555)
E/StrictMode(23606): at org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:487)
E/StrictMode(23606): at org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:465)
E/StrictMode(23606): at org.mozilla.gecko.Favicons$LoadFaviconTask.downloadFavicon(Favicons.java:288)
E/StrictMode(23606): at org.mozilla.gecko.Favicons$LoadFaviconTask.doInBackground(Favicons.java:350)
E/StrictMode(23606): at org.mozilla.gecko.Favicons$LoadFaviconTask.doInBackground(Favicons.java:227)
E/StrictMode(23606): at android.os.AsyncTask$2.call(AsyncTask.java:252)
E/StrictMode(23606): at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:305)
E/StrictMode(23606): at java.util.concurrent.FutureTask.run(FutureTask.java:137)
E/StrictMode(23606): at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1081)
E/StrictMode(23606): at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:574)
E/StrictMode(23606): at java.lang.Thread.run(Thread.java:1020)

Unfortunately I can’t post exact stack traces that I’ve run into, since these issues were in the context of work.

The basic reason for many of these SMVs on Android is that Android, by default, uses HTTP keep-alive, meaning that some of the underlying resources (e.g. sockets) are kept open. I think that the strictmode violations are caused when the connection objection leaves scope, the garbage collector eventually cleans up the resources and, in so doing, finalizes some weak references and triggers the SMV. Whatever the exact underlying cause is, the proximate fix is to override Android’s default keep-alive behavior for any connections that don’t require it. This can be done by setting a request property on the connection before you connect, like so:

I recently, after several months of miscellaneous frustration with my old laptop, sprung for a new MSI GT70-0NE. (PR Sheet; Amazon detail page). Despite some disappointing service from Amazon (first time in 8 years) which got it to me a few days later than I expected1, I’m completely thrilled with my decision.

First off, I won’t be saying much about the hardware specs, because this thing is a straight up beast. If machine were any more beastly, it’d be living in a Cretan labyrinth. Once I got it set up and drivers installed2, everything I threw at it ran at full video settings with nary a dropped frame. I’ve also had none of the cooling issues that some other folks reported, even under high load. Then again, when I’m gaming or doing intensive work, I usually have the machine on a fan-cooled laptop stand, so it’s possible that helps as well.

The fit and finish of the machine are superb. Looking at the form factor and physical design online it looked a bit gimicky, but in person its stealth-fighter lines and variable-color backlit keyboard actually look pretty sweet. The keyboard itself, by Steelseries, feels great. The keys have a pleasing slightly sticky friction and, with a few minor exceptions3 that I’m quickly getting used to, the layout is great. The screen is clear and has excellent viewing angles. The audio from the speakers alone is remarkably good for a laptop, but that’s kind of damning with faint praise. Your external speakers or nice headphones are still going to give you a much better listening experience.

The machine came with Windows 8 installed, and remarkably little non-Microsoft bloatware. There was the obligatory Norton Security bullshit to uninstall4, which has gotten slightly more annoying to do on Win 8. But other than that, the MSI-branded apps that were installed all seem at least nominally useful. There’s a WiFi network monitor that I probably won’t look at again, but which was at least interesting to poke at, and a slick app for customizing the coloration and pattern of the LED-backlit keyboard.

A little over 24 hours in to owning, the MSI GT70-0NE is an awesome machine, and I’m thrilled with my purchase. It’s definitely premium kit, but if you’re someone like me that spends the majority of their waking hours on computers, you’ll definitely appreciate the killer hardware, top-quality interface components, and excellent fit and finish, all with a minimum of cruft or headaches. Highly recommended.

1 If you ever want to see the most pathetic frustration, tell a nerd his new toy will arrive on Saturday, then make him wait until Monday. To say that I’m spoiled by fast shipping rates would be a charitable understatement. “Had to wait two extra days for a laptop” isn’t even a first world problem, it’s a zeroth world problem.

2 I did run into one minor issue where the first-time setup for the drivers failed to correctly install the WiFi driver, leaving me unable to connect to any networks. Uninstalling and re-installing the driver fixed the issue completely, however.

3 This is the most minor of all minor grievances, but the right shift key is too short and abuts the up-arrow, resulting so far in frequent frustrating mistakes whilst editing text.

4 Norton has managed to suck even more on Windows 8. It won’t actually let you close the pesterware dialog, only letting you select “remind me later”. What it really needs is a “Fuck off, uninstall yourself, and never darken my door again” option, but then I imagine that’s a bit long to fit on a standard dialog button.

If you wonder where your humble host has been these past few weeks, I submit for your consideration the shiny new look and feel of Amazon Silk. Thanks to all of my colleagues on the Amazon Silk team. The new version is a huge step forward and I know for a fact that everyone busted their asses to get it done.

I’m on the team that owns the UI look-and-feel and a lot of the user-facing features, so this is a pretty big release for us. I’m damned proud of the browser we delivered and I hope our customers enjoy the new hotness.

“The latest version of Silk has made several improvements, starting with a new tutorial that gives users a better look at the features when launching the browser for the first time. Once the tutorial is completed, you’ll now be greeted by a new start page with a listing of most-visited pages and an empty address bar so you can quickly get to browsing.

Other improvements include a better tab layout to make navigation easier, a new slide-in panel navigation bar as well as an improved “Readability view” that strips out the excess parts of a page to make it easier to get through long articles on web pages. As a whole, the Silk browser seems to have received a much-needed facelift that should impress Kindle Fire users.” – Andrew Martonik, Android Central

Along with the update, we’ve also put out a Developer’s Guide for any web devs curious about Silk and some of its unique features.

Magic Blue Smoke

House Rules:

1.) Carry out your own dead.
2.) No opium smoking in the elevators.
3.) In Competitions, during gunfire or while bombs are falling, players may take cover without penalty for ceasing play.
4.) A player whose stroke is affected by the simultaneous explosion of a bomb may play another ball from the same place.
4a.) Penalty one stroke.
5.) Pilsner should be in Roman type, and begin with a capital.
6.) Keep Calm and Kill It with Fire.
7.) Spammers will be fed to the Crabipede.