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.
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 governmentservices — 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.
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.
I am thinking about spending some quality time with Scala. What would you recommend, resource-wise, for a Java expert (I taught it for two years) with a reasonable amount of functional programming experience? I've looked over a bunch of the references on the Scala website, and they make good sense; what I'm particularly looking for are resources of the sort that make lightbulbs go off in one's head.
Because the rent-a-coder websites become clogged with bullshit requests like this and this.
Protip: if you're so incompetent that you have to outsource your homework assignments to an Indian codemonkey for $50 a pop, maybe CS is not the major for you.
Despite some early frustration, this week has turned out really good after all. A number of people mysteriously crawled out of the woodwork on a day when I was feeling pretty lousy (this means you, cloakedwraith and enochsmiles), reminding me that I have good friends and that the world is a saner place than I have a tendency to give it credit for. (Yes, that was intentionally vague; it's something that I could in theory bitch about, but I've done my venting in private, and no longer feel the need to. That, in and of itself, is a great feeling.)
I've been decaffeinating over the last week. I hadn't intended to, but I've been deliberately cutting back on sugary drinks, which de facto means less caffeine unless I make coffee or tea. I like both of those, but making them requires a bit more concentration than I can usually marshal when I'm fixated on some work thing or another, and I like carbonated things far more than anyone ought to, so normally I just go to the fridge for a coke. However, in the wake of this last shopping trip, I've been going to the fridge for a sparkling water, which is probably better for me anyway, but doesn't provide that crucial headrush. Thus, by Wednesday I was miserably headachey, and spent the entire day curled up in bed hacking. Most of it was noodling around in the guts of PostgreSQL, but by late evening I decided to bite the bullet and knock out the last of the obvious bugs in Nemesis.
Which is now done, for definitions of "done" which include "going back and adding in more specific exception-handling routines and fixing the ID10T errors that my boss found today when I demoed it for him." It's interesting having a boss who's really smart but who also knows how to think like one of the people about whom Distributing Clue to Users was written. Within half an hour, he'd come up with ten different ways someone could break the software in ways I'd never intended, though I'm proud to say that I had already trapped quite a few of the bad inputs he'd come up with. :) So that'll be a few hours of shoring up the walls next week, and then we hand it over to other people in the office for alpha testing. Anyone want to help me test a site-directed mutagenesis primer generator?
Still, Andy is now very happy with me, and is even more happy with today's Nifty Advisor-Related Development. Hwanjo, my advisor, has been wanting to put together a soft-query-driven interface on GenBank1, sort of a killer app for bioinfo, but for some reason he wanted to do it as a browser plugin. For IE, no less, despite my protests that Firefox is much more readily extensible and that I would rather stab myself in the throat with a pencil than learn ActiveX. This afternoon, I finally convinced him that putting together a client-side interface to a 300GB database is just silly, particularly when one of his students (*raises hand*) has already put together a web-based frontend for annotation and data mining which is eventually supposed to be generalisable anyway. Since it had originally stalled out due to my not having had the necessary mad skillz to put together a reasonable (read: runs in some order of time that won't drive users around the bend and doesn't require huge amounts of precomputation) classification backend at the time, CHARUN is now back from the dead. This discovery immediately prompted Andy to start humming "Bela Lugosi's Dead," which suggests to me that (1) apparently every project I work on at IDT will have its own cheesy goth theme song, and (2) there are much worse things than having a boss whose musical taste overlaps yours.
After all this, I knocked off work around six and went home to await the arrival of my sysadmin, who lives in Des Moines but was coming into town for the weekend. Noises had been made about a Return of the Bride of the Nephew of Bad Movie Night, but since Nate (aka the guy who'd wanted to do the resurrecting) managed to fail to pass this on to other people and ended up with stuff he needed to do tonight, it ended up being just me and $sysadmin. Happily unencumbered by other people's schedules -- he'd been thinking about going to a party tonight, but decided to bow out after receiving notice from another friend that his ex-girlfriend would be in attendance -- we enjoyed a sumptuous repast of sushi and mochi ice cream, then headed downtown to see if we could land a pool table at College Street Billiards. Alas, the last free table in the place became nonfree moments after we walked in, so we decided to try the movie night thing after all. $sysadmin rose to the occasion with a copy of the 2002 Adam Sandler flick Mr. Deeds.
Which, beyond all my expectations, managed to not suck. I have always associated Adam Sandler movies with gratuitous fart/potty/embarrass-the-characters humour, but this one was, dare I say, quite charming. It's based on a 1936 Frank Capra film, Mr. Deeds Goes to Town, which stars Gary "Please don't remind anyone that I also played Howard Roark" Cooper. I've never seen the original, but the remake was sufficiently amusing and sweet-natured that now I want to find and watch it -- unlike the "oh God, this is so terrible I need to see the original to wash the bad taste out of my brain" reaction I had expected to have. I wouldn't say it's worth buying, but if you happen across it on cable, it's not a bad way to let an hour and a half go by.
$sysadmin and I also hatched clever schemes involving convincing IDT to set up colo servers across the country for the Grand Unified Database Project that Andy has in mind. Will it go anywhere? Well ... I've heard worse ideas, let's just put it at that.
And now I have a sleepy cat on my lap, and tentative plans to go see saoirse_kore tomorrow. Yay! I still wish I could have been at PyCon, but there'll be time for that next year.
1 The first time I typed that, I wrote "GenGank" instead. *snicker*
Relax! - We Humans Can Live Forever And Become Equal To Gods - I got the Key to our Physical Immortality - Staying Absolutely Healthy All The Time, for Infinite Health = Immortality (8,500 years…
Comments
What do?