You Had One Job: Some advice for anyone performing due diligence.
There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult.
- Sir C. A. R. Hoare
On the heels of I-guess-it-was-Wednesday-I-don't-keep-my-thumb-on-the-pulse-of-this-shit's news that "single-tap zero-character communication tool" Yo had raised over $1M in seed capital comes today's news that Yo leaks users' phone numbers and is riddled with other holes.
This should surprise approximately nobody, and yet it apparently does. By and large, people have come to grudgingly expect data breaches at their mobile providers, their banks, the restaurants and stores where they shop, even their government services - these things are complicated - but surely an app that does just one thing can get that one thing right, right?
The problem is not the one thing. The problem is everything else.
Hoare also famously observed that "One of the most important properties of a program is whether or not it carries out its intended function," and later in the same paper (emphasis mine), "The most important property of a program is whether it carries out the intentions of its user." The distinction here is subtle, but important. When a user installs a program, the user intends that the program carry out its intended function, and also intends that the program not carry out any unintended functions1. The fact that your program can carry out its intended function is not enough if your program also carries out other functions that are actively detrimental to your users, like leaking their phone numbers without their consent.
Time will tell how much of Yo's seed round will leach away into the legal system (or to the FTC, as Parker Higgins points out) as a result of its negligence, and I hope that investors, entrepreneurs-in-residence, entrepreneurs generally, and users pay attention to that figure. If this number is low, that's good news for unscrupulous investors and bad news for privacy (and civic engagement, and so on). Although it generally seems to be the case that the market does not give much of a fuck about data breaches, I would really like to see that seed round evaporate away into damages, because honestly whoever signed off on due diligence for this funding round was either criminally ignorant or criminally negligent.
An important lesson here, for users as well as due diligence, is that permissions don't tell the whole story, particularly when viewed in isolation. (You'll have to click on "view details", there doesn't seem to be a direct link.) "Find accounts on the device" sounds like an innocuous enough capability on its own - but as Glympse's explanation of how their Android app uses the permissions it requests points out, "find accounts" is also required for push notifications. Because that obviously makes sense. (I am not actually an Android developer, but from a little searching it looks like Yo's permissions map exactly to those that push requires.)
I know exactly nothing about how Yo actually manages user accounts, but I will bet anyone alive an Airbus A380 stuffed full of dollars that of Yo's supposed ~50,000 users, of the tiny fraction of those who actually looked at the permissions before they installed the app, the only ones who knew that "find accounts" enables push were Android developers themselves. Of course, it makes complete sense that an app whose intended purpose - or, well, declared purpose, anyway - is to send a single, fixed string literal from one mobile device to another would use push notifications for that (what else are you going to do, long polling?), but did anyone actually check that the code could only send that fixed string literal?
If I decompile the Yo .apk, am I going to find something that looks remarkably like:
static final String yo = "Yo";
[...]
void pushMessage(User user, String message) {
somePushFramework.push(user, message);
}
[...]
pushMessage(user, yo);
The users can't check that, unless they're willing to learn how to use a Dalvik decompiler, and while I aspire to the eternally bright outlook where users heroically take the initiative to learn what their tools are really doing, I live in a world where I have had to make sure that unnecessary abstractions like this do not make it into production code. Except in this case it wasn't "there exists a function that can be hijacked to send an arbitrary message," it was "there exists a function that can be hijacked to set an arbitrary environment variable to an arbitrary value." If that doesn't keep you awake at night, you probably shouldn't be writing software. Or funding it. If you are funding it, though, you should really have someone looking at the code who is kept awake at night by bad architecture.
How Yo got from enabling push notifications to leaking phone numbers I genuinely do not know. If I had to guess broadly, I'd go with thoughtless endpoint API design, which is a rant all by itself, and yet another argument for careful architectural review. I don't have much insight into how funders make decisions, but I have picked up a fair amount of understanding over the years about how software defies people's expectations of banality, and if you are not looking at how the software you are thinking about funding might unintentionally carry out something other than the intentions of its user, then you are not thinking about one of the ways in which you are exposing yourself to liability.
Edit: Like I said, I don't follow this shit obsessively, so I completely missed Marc Andreessen almost getting the point but missing it spectacularly at the last second:
2/Yo is an instance of "one-bit communication" -- a message with no content other than the fact that it exists. Yes or no. Yo or no yo.
- Marc Andreessen (@pmarca) June 19, 2014
No, Marc. Those Georgia Tech kids proved by construction that Yo, in the instantiation that attracted it ~50,000 users and over a million dollars, communicates way more than a single bit. That a seasoned investor would see the potential for one-bit apps (which there most certainly is, and he gets that), but not temper that vision by at least acknowledging the potential for a gap between intention and implementation, is troubling. That any investors went so far as to throw seven figures at this project, apparently without investigating that gap, is insanity.
1There is an argument to be made here about undefined behaviour in programming language semantics and why it shouldn't ever be allowed, since technically speaking, a diabolical C compiler writer who decides that the semantics of attempting to modify a string literal or divide an integer by zero should be rm -rf / is not wrong, but that particular framing of said argument is pretty hyperbolic.
- Sir C. A. R. Hoare
On the heels of I-guess-it-was-Wednesday-I-don't-keep-my-thumb-on-the-pulse-of-this-shit's news that "single-tap zero-character communication tool" Yo had raised over $1M in seed capital comes today's news that Yo leaks users' phone numbers and is riddled with other holes.
This should surprise approximately nobody, and yet it apparently does. By and large, people have come to grudgingly expect data breaches at their mobile providers, their banks, the restaurants and stores where they shop, even their government services - these things are complicated - but surely an app that does just one thing can get that one thing right, right?
The problem is not the one thing. The problem is everything else.
Hoare also famously observed that "One of the most important properties of a program is whether or not it carries out its intended function," and later in the same paper (emphasis mine), "The most important property of a program is whether it carries out the intentions of its user." The distinction here is subtle, but important. When a user installs a program, the user intends that the program carry out its intended function, and also intends that the program not carry out any unintended functions1. The fact that your program can carry out its intended function is not enough if your program also carries out other functions that are actively detrimental to your users, like leaking their phone numbers without their consent.
Time will tell how much of Yo's seed round will leach away into the legal system (or to the FTC, as Parker Higgins points out) as a result of its negligence, and I hope that investors, entrepreneurs-in-residence, entrepreneurs generally, and users pay attention to that figure. If this number is low, that's good news for unscrupulous investors and bad news for privacy (and civic engagement, and so on). Although it generally seems to be the case that the market does not give much of a fuck about data breaches, I would really like to see that seed round evaporate away into damages, because honestly whoever signed off on due diligence for this funding round was either criminally ignorant or criminally negligent.
An important lesson here, for users as well as due diligence, is that permissions don't tell the whole story, particularly when viewed in isolation. (You'll have to click on "view details", there doesn't seem to be a direct link.) "Find accounts on the device" sounds like an innocuous enough capability on its own - but as Glympse's explanation of how their Android app uses the permissions it requests points out, "find accounts" is also required for push notifications. Because that obviously makes sense. (I am not actually an Android developer, but from a little searching it looks like Yo's permissions map exactly to those that push requires.)
I know exactly nothing about how Yo actually manages user accounts, but I will bet anyone alive an Airbus A380 stuffed full of dollars that of Yo's supposed ~50,000 users, of the tiny fraction of those who actually looked at the permissions before they installed the app, the only ones who knew that "find accounts" enables push were Android developers themselves. Of course, it makes complete sense that an app whose intended purpose - or, well, declared purpose, anyway - is to send a single, fixed string literal from one mobile device to another would use push notifications for that (what else are you going to do, long polling?), but did anyone actually check that the code could only send that fixed string literal?
If I decompile the Yo .apk, am I going to find something that looks remarkably like:
static final String yo = "Yo";
[...]
void pushMessage(User user, String message) {
somePushFramework.push(user, message);
}
[...]
pushMessage(user, yo);
The users can't check that, unless they're willing to learn how to use a Dalvik decompiler, and while I aspire to the eternally bright outlook where users heroically take the initiative to learn what their tools are really doing, I live in a world where I have had to make sure that unnecessary abstractions like this do not make it into production code. Except in this case it wasn't "there exists a function that can be hijacked to send an arbitrary message," it was "there exists a function that can be hijacked to set an arbitrary environment variable to an arbitrary value." If that doesn't keep you awake at night, you probably shouldn't be writing software. Or funding it. If you are funding it, though, you should really have someone looking at the code who is kept awake at night by bad architecture.
How Yo got from enabling push notifications to leaking phone numbers I genuinely do not know. If I had to guess broadly, I'd go with thoughtless endpoint API design, which is a rant all by itself, and yet another argument for careful architectural review. I don't have much insight into how funders make decisions, but I have picked up a fair amount of understanding over the years about how software defies people's expectations of banality, and if you are not looking at how the software you are thinking about funding might unintentionally carry out something other than the intentions of its user, then you are not thinking about one of the ways in which you are exposing yourself to liability.
Edit: Like I said, I don't follow this shit obsessively, so I completely missed Marc Andreessen almost getting the point but missing it spectacularly at the last second:
2/Yo is an instance of "one-bit communication" -- a message with no content other than the fact that it exists. Yes or no. Yo or no yo.
- Marc Andreessen (@pmarca) June 19, 2014
No, Marc. Those Georgia Tech kids proved by construction that Yo, in the instantiation that attracted it ~50,000 users and over a million dollars, communicates way more than a single bit. That a seasoned investor would see the potential for one-bit apps (which there most certainly is, and he gets that), but not temper that vision by at least acknowledging the potential for a gap between intention and implementation, is troubling. That any investors went so far as to throw seven figures at this project, apparently without investigating that gap, is insanity.
1There is an argument to be made here about undefined behaviour in programming language semantics and why it shouldn't ever be allowed, since technically speaking, a diabolical C compiler writer who decides that the semantics of attempting to modify a string literal or divide an integer by zero should be rm -rf / is not wrong, but that particular framing of said argument is pretty hyperbolic.