Varney Kemokai finds a new way to encourage his Liberian math students.
Seven years ago, Steve Jobs introduced the original iPhone. It was a watershed moment for our industry, when an array of just-mature technologies was brought together to produce a radically new and better computing experience. In many ways, I see Jobs' introduction as a spiritual successor to Doug Englebart’s Mother Of All Demos, which introduced the world to mice, bitmapped displays, window systems, hypertext, and much more besides. Amazingly, Englebart’s famous demo is now 45 years old.
What other people, landmarks, and forgotten but essential lore can help us understand how we’ve arrived here, today? What can help us gain a broader perspective on where we might go tomorrow? These questions led me to put together a hacker history reading list:
- As We May Think, Vannevar Bush’s milestone post-war article arguing for a revolution in information accessibility and management.
- The Idea Factory, Jon Gertner’s history of influential Bell Labs
- The Man Behind The Microchip, the story of Robert Noyce and Fairchild Semiconductor. We probably don’t appreciate today just how much Fairchild (and Noyce) set the tone for entrepreneurship in the Valley.
- The Curse Of Xanadu, a look at our industry’s first true vaporware, and at the tragic genius of Ted Nelson, of one of its countercultural heroes. (See also Nelson’s famous and expensive-to-acquire Computer Lib/Dream Machines, which declared that “You can and must understand computers NOW”.)
- Soul Of A New Machine, Tracy Kidder’s Pulitzer Prize winner about a team of engineers at Data General working to breathe life into a new minicomputer.
- Commodore: A Company on the Edge, Brian Bangall’s examination of the complex early PC market, and of one company’s epic rise and fall.
- Where Wizards Stay Up Late, a fascinating history of the ARPANET.
- Hackers and Fire In The Valley, both of which tell the story of the PC revolution. Hackers focuses more on personas, whereas Fire weaves a more coherent timeline. (Fire is also one of the few books I know of that delves into detail on Gary Kildall and CP/M.)
- What The Dormouse Said, an entertaining book about sixties counterculture and its unexpected intersections with the early computer industry. Also, The Whole Earth Catalog, one of the influential countercultural artifacts of that era.
- Core Memory, a beautiful photo book of vintage computers with interesting historical blurbs. It sits on the coffeetable at my office.
Back when the App Store was young and the gold rush was new, I worried that we’d forgotten our roots. Since then, I’ve learned to just sit back and let the world take its distributed, stochastic course. I simply want my own path through the industry to keep its history well in mind.
This week it’s been popcorn and fireworks. Some of the NoSQL community’s sharper minds have taken Redis to task, and rightly so, for having poorly defined (even undefined) behavior. Strangely, the Redis team appears to be in deep denial about this fact. Worse, they seem to willfully ignore the fundamental underpinnings of distributed systems, like the CAP theorem.
Bottom line for me: today, key parts of Redis are busted, or at least hard to reason about. Until its developers see the light, I’ll stay away.
From the getting-old department.
Fifteen (!) years ago, Georg, Abi, and I penned an absurdist techno musical about Iphigenia’s sacrifice at Aulis. It intertwined Aeschylus, Euripides, stomping trance, pre-millennium tension, crack clowns, dancing bears, and several other tropes — like candy ravers — commonly found in the Greek classics.
Luckily, our university had some other kindred spirits who understood our palette as — ahem — precisely as we did. We got the lucky chance to produce Atreus Dawn, with a genuine budget, on a genuine stage, in Providence, RI. It looked a little like this:
There are a few things I remember fondly. The stark geometry of the set and lighting, coupled with the spirited Greek chorus and relentless direction, propelled the show through its dark terrain. But some of my favorite moments were just plain inexplicable, like when two-year-old Orestes sang an (intentionally atrocious) Barbie Girl number about his future kingship while the chorus transformed the stage into a rave hall.
We pressed far too many CDs, so I also remember standing with Georg near the Alamo sculpture in New York, trying to pawn off our wares on unsuspecting passerby. Who was the Manhattanite that, when confronted with our free techno-musical-on-a-platter, bellowed “I don’t want any of your Jesus crap!” as he stormed away? In a fit of reverse kleptomania, we also snuck a dozen or so CDs onto the shelves of the nearby Virgin Megastore.
What’s left today are some goofy photos, good memories, and, of course, the music. We’ve placed the full instrumental recording and the never-quite-completed-to-our-satisfaction full cast recording under a creative commons license. I’d say “enjoy,” but I’ve heard the music, so instead I’ll just wish you Godspeed.
Ivory uses samples. Each key of the piano is painstakingly recorded hundreds of times at different dynamic levels and with different pedaling. When you “play” Ivory, you replay the samples.
Pianoteq is modeled from first principles. It is based on the mathematics of keys, dampers, hammers, strings, and soundboards. When you “play” Pianoteq, you solve a differential equation that describes the physics of an ideal piano.
Neither approach is perfect; both lie somewhere on the upslope of the uncanny valley. Ivory’s samples can’t capture the full quality of pedaling and sympathetic resonance. And I often catch Ivory repeating samples at unexpected times; nobody wants deja vu when tickling the ivories.
Pianoteq can’t yet capture the dirt and nuance of real hammers on real strings. But the latest version has made such great strides that it has won me over. The underlying hammer/string model is, to my ears, substantially improved. Pianoteq feels alive under my hands and plays closer to the real thing than anything else I’ve tried.
Beyond this, I simply love the idea that we can master the physics that govern the piano and channel them into an artistic and technical achievement of first rank. Here’s the principal equation for audio evolution, as described in Pianoteq’s original patent application:
I almost don’t care that this is a standard exciter/resonator model, or that it’s left as an exercise to the reader to produce the tables behind the key coefficients, or that I haven’t studied equations of this sort in over a decade and am out of my mathematical depth.
I’ll just let its form wash over me. It’s kind of beautiful, no?
Two years ago, if you’d asked me whether I wanted to build a VPN service, I would have laughed you out of the coffee shop. VPNs were by no means top of my mind!
At the time, I was an itinerant freelancer working from Seattle’s many fine caffeine houses. I performed sensitive work for my clients over untrusted (and often wide-open) wireless networks. I knew I needed a VPN but, when I shopped around, I found products that fell roughly into two camps: those that had a poor user experience, and those that were just plain sketchy. The state of the art was to download OpenVPN and a corresponding configuration file, or to manually configure third-party apps. I didn’t want more nerdingulation in my life; I knew I wouldn’t use a VPN if it wasn’t hassle-free.
At around the same time, Peter, Nick, and I wanted to start a new project together. We’d previously worked on a short-lived but failed project that proved 20% unfortunate, 80% fun. New idea in hand, it wasn’t long before we were off to the races. We quickly shipped Cloak’s MVP and sat back to let the service grow organically. With limited but promising early data, we decided to take credit cards and make a full-time go of it. Cloak 1.0 launched in January at Macworld 2013 and we’ve been cranking ever since.
All this is to say: Cloak is the very definition of a leap before you look business. We built Cloak for ourselves first and for business second. Sure, we felt that Cloak was a substantially better offering on a couple key axes. But with hindsight it’s clear that we also had no idea what the VPN market would look like or where the roller coaster would lead. It’s unsurprising, then, that several aspects of our business continue to vex. To be sure, I love the grind: every worthwhile creative or entrepreneurial endeavor spends time in the muck. This doesn’t reduce its complexity or its stress!
As a rule, users have deep misconceptions about VPNs. Well before we built Cloak, we knew there would be an education barrier. We were still surprised by its height. VPN services solve an extremely narrow set of security problems; it’s difficult to communicate the merits of their subtle, incremental improvements. Worst of all, some (nameless) competitors appear to actively mislead their customers into believing VPNs are something they’re not. We’re asked with alarming regularity whether Cloak can protect from the NSA (no), provide anonymity (no), or make it safe to access bank websites from Starbucks (it’s already safe). Taking money from customers who don’t even know why they’re using your product is a moral minefield. When we hear from deeply confused customers, we typically refund their most recent month of service and gently nudge them in a new direction.
We also entered the market with several of our own misconceptions. Cloak was designed to be a great privacy and security service; with features like OverCloak, Cloak is essentially overbuilt for any other purpose. But it’s clear now that privacy is only important to a minority of our users. The majority use VPNs to circumvent frustrating network blocks and geographic content restrictions. As shipped, Cloak 1.0 was woefully under-equipped to serve those customers. That’s why we quickly moved to add Transporter to the mix. This single feature addition radically altered our core business; in many ways, we’re still catching up. Our next round of work substantially improves both messaging and design, making it clear that we seek to satisfy both customer segments with a single, unified product.
Despite our many fumbles along the way, we’ve been lucky enough to find great customers and delight them. We’ve had the good fortune to turn Cloak into a profitable, growing business. In the short-term, we’re hard at work on Cloak 2, which addresses nearly all of our top customer requests. But as we look more broadly at the universe of privacy and security solutions, VPNs feel like a shrinking piece of the pie. These days, we’re asking ourselves how we might solve much larger and more pressing problems. What will it take to really go for the privacy jugular?
“I’ve got a problem,” says App Developer. “My software sells well enough, but income is hard to predict. I’m thinking about switching to a subscription model.”
“Now you’ve got four problems,” I reply.
Managed properly, subscriptions can smooth a business' income and improve its predictability. But it’s a delicate balancing act. Every subscription business, whether cutting-edge SaaS or humdrum periodical, must confront the four horsemen of the subscription apocalypse: churn, average revenue per user (ARPU), cost of customer acquisition (COCA), and cost of goods sold (COGS). These metrics demand a watchful eye; any change can send a carefully calibrated business spiraling into oblivion.
The web is chockablock with great writing about the Zen of subscription metrics. But churn deserves special mention. Of the horsemen, it looms largest in early stage startups. At a high level, churn is best seen as a proxy for customer (un)happiness. When a startup is still discovering its product/market fit, happiness can change on a dime. Any slight uptick in churn can overwhelm a businesses' positive metrics, quickly quashing growth.
It’s worth teasing apart happiness. In markets where non-consumption is not (or not much of) a competitor, churn and happiness go hand-in-hand. When a customer leaves AT&T, they’re almost certainly heading to Verizon, Sprint, or T-Mobile… and they’re almost certainly unhappy. On the other hand, when non-consumption is a viable alternative, customers may leave because they just don’t need a service right now. Even in their absence, these customers might be perfectly happy.
The flip side to churn is customer lifetime value (CLV). When average revenue per user is fixed, lifetime value is strictly determined by churn. As churn decreases, customers become more valuable on average. When this happens, businesses become free to spend more on customer acquisition, pursuing leads and strategies that would not previously have been profitable1. Even when average revenue grows, it tends to grow slowly; churn remains the dominant factor in nearly any CLV computation.
Because churn is such a critical metric, larger companies manage it with in-house customer success teams. What is a penniless young startup to do? Why, build a customer success “team,” of course — even if it’s just one employee. For a tiny startup, churn management is bound to be time-consuming and non-scalable. Just remember that this cost is balanced against the high-magnitude, high-probability outcome of churn-dominated doom. The good news is that, for early stage startups, it’s easy to understand churn: simply ask your customers why they left2. The feedback you receive will guide you.
As successful subscription businesses grow, churn tends to converge to a predictable rate. Established SaaS startups might see 3% churn on average. Even in this “steady” state, churn is a relentless enemy, forcing businesses to continually find new customers to replace those they will inevitably lose. Tomasz Tunguz has written an excellent piece on the churn mitigation strategies used by maturing subscription businesses.
 I'm speaking as someone who has bootstrapped his subscription business to profitability. The trend today in SaaS is to find a pot of gold and use it to grow unprofitably until it's time to "flip the switch." I understand this game abstractly, but I have no taste for it. Perhaps this is why I'm not a particularly good entrepreneur!
 Cloak presents departing customers with a super-simple (and completely optional) exit survey. Customers — happy or otherwise — seem to like the opportunity to speak their mind. Beyond this, I've learned that sending personal emails to departing customers is a wonderful way to learn more and to let them know that we care.
Last week, LinkedIn announced a major new service called Intro. In response, the Internet community spontaneously burst into flames:
LinkedIn has a new iOS app called Intro. Here’s why you should treat it like a radioactive wasp hive. bishopfox.com/linkedin-intro/— Eric A. Meyer (@meyerweb) October 25, 2013
On the surface, Intro is rather clever. It dips into LinkedIn’s trove of professional profiles and inserts miniature bios at the top of inbound emails. Intro’s bios are interactive, making it a snap to learn how a sender’s professional network overlaps with your own:
Intro is a great feature. Its implementation, on the other hand, has made Mr. Internet quite cranky. Apple’s Mail app can’t be extended by third parties. LinkedIn flanks this problem by extending emails instead. To do so, Intro inserts itself between you and your email provider, rewriting your emails before they reach your inbox. Depending on one’s perspective, this approach is either clever or crazy. In the crazy column, it grants LinkedIn full and unencrypted access to your most personal communications. In the world of online security, such men-in-the-middle are bright red flags. They’re potential points of weakness and tempting targets for attack. Adding middlemen to the mix is usually the wrong way to go; the benefits must measurably outweigh the costs.
There are other concerns. Historically, LinkedIn has a poor track record managing security-critical infrastructure. In addition, Intro opens up new avenues for phishing and other mayhem. Finally, using Intro means your email is only available when both LinkedIn and your underlying mail provider are up and running.
Many developers have also sounded the alarm about Intro’s use of configuration profiles to alter iPhone mail settings. It’s worth teasing this apart a bit, since even in the iOS community there appears to be some confusion1.
Introduced with iOS 4 and Apple’s push into the mobile enterprise, configuration profiles are signed bags of system-wide settings. They can contain all sorts of useful (or troubling) settings, ranging from VPN configurations, to email accounts, to root certificates. It’s possible to directly inspect the contents of profiles before installing them2 but, for most users, the inspection dialog might as well be Greek.
There are three direct ways to install configuration profiles: via the web, via email attachments, or via connection to a PC. Native apps cannot directly install profiles, although they can direct users to profile download pages in Mobile Safari. This mostly leaves profile installation outside of Apple’s review and control. (As it happens, LinkedIn Intro is a web, not native, app, and is thus entirely outside Apple’s purview.)
There’s also an indirect way to install configuration profiles called Over-The-Air Profile Delivery. OTA delivery is typically used by larger companies whose employees wish to bring their own devices to work. Devices must first be enrolled in a management service. Enrollment is achieved via a complex multi-step process, with plenty of obtuse warning dialogs proffered by iOS along the way. Once enrolled, devices can recieve arbitrary settings updates from their management services at any time.
It’s worth stating that LinkedIn Intro does not use mobile device management (MDM) profiles3; it does not use OTA delivery. As a result, it cannot push arbitrary changes to your device at any time. The confusion in the iOS community may stem from the fact that, when installed, Intro does issue a device enrollment challenge. Typically, device enrollment challenges are the first step in the larger MDM enrollment dance. However, Intro installation stops short of fully enrolling the device. Rather, the enrollment challenge is simply a smart security precaution4 along the way to configuring a new
+Intro email account. The one disadvantage of this approach is that it is not possible to inspect the settings that are ultimately installed until after the fact.
Configuration profiles are complex beasts. Apple probably needs to do more to help typical end-users understand what it is they’re doing when they install profiles… and, perhaps, to gently discourage them from doing so. That said, profiles (and Apple’s Laissez-faire attitude toward them) are essential to iOS’s continued success in the enterprise. They can’t and won’t simply go away.
(Bogey)men in the middle
It’s worth remembering that not all men-in-the-middle are inherently evil. My app Cloak, an easy-to-use VPN service for OS X and iOS, is effectively one big man-in-the-middle. When you use Cloak, literally every byte you send and receive on the Internet passes through our servers. The benefit is simple: if you’re using a network you don’t trust, like Wi-Fi at a coffee shop or airport, you’re putting yourself at risk. By encrypting your data before it leaves your laptop, Cloak can protect you from a wide range of common attacks, like those made possible by Firesheep. The catch? Once your data reaches our servers, we have to decrypt it and send it onward to its original destination. If we were nefarious (we’re not), we could take a peek along the way. On the whole, I’m convinced that Cloak’s benefits outweigh its costs. But it’s undeniably in-the-middle. It must be weighed and measured as such.
Men-in-the-middle come in all shapes and sizes; it’s no surprise that Cloak and Intro have very different security properties. For example, Intro temporarily strips away the encryption of all email transfer. Cloak, on the other hand, never decrypts independently encrypted data: it can’t! Since email transfer is typically independently encrypted with SSL, Cloak can never see your email. The same goes for your interactions with independently secured websites like, for example, your bank.
As always with complex systems like Intro, the question is whether the rewards eclipse the risks. Even knowing Intro’s risks, I can see how customers — completely sane and thoroughly informed — might still be excited to use it. After all, is Intro truly worse than Gmail itself, which has full access to your email and uses it to serve you ads?
I just wrote a long-form article in the Cloak Security Blog describing what we know, and what we suspect we know, about western governments' electronic surveillance programs:
In the past few months, the three of us here at Cloak have watched with rising concern as the size and shape of Edward Snowden’s disclosures has ratcheted into focus. Until today, we haven’t said much, mostly because the full capabilities of government intelligence organizations such as the NSA and the GCHQ are simply not known.
Writing the “story so far” forced me to re-visit primary sources, principally in The Guardian and ProPublica, and to piece together the motivating logic behind our intelligence agencies' efforts. It’s unsurprisingly trivial:
Agencies seek to: (1) collect all data and, when possible, directly collect its unencrypted variant, (2) decrypt any encrypted data, and (3) provide analysts with the ability to store, index, and process the data
Are Snowden’s revelations a surprise? I don’t think it’s cynical to say “no.” Intelligence agencies have lived in “dangerously murky constitutional, legal, and ethical terrain” since their earliest days. It was ever thus.
What’s different today are the fundamental animating economics:
In a physical world, we have fairly reliable intuitions about the significant expense and human effort involved in someone compromising our privacy, whether it’s breaking into our office or eavesdropping on a conversation. In a world where most of our data wanders unselfconsciously through unknown computer networks, our intuitions betray us. For all that we talk of massive intelligence budgets, the per-capita cost of gathering data is plummeting.
This is, I think, the deeper story. It’s also, perhaps, the way forward. As a public, we must continually seek ways to increase the expense of circumventing our privacy. We can do this via technological means, of course, although it’s impossible to predict where such an arms race — against our own governments, no less — might lead. Better still might be to pursue a broad platform of political measures to more clearly define the public’s rights and the government’s responsibilities in the modern digital age.
I use my iBooks sample queue as a form of future cultural memory. In the past couple years, I’ve collected nearly 75 samples. Who knows? I might read them someday.
I recently discovered that iBooks samples disappear when an iDevice is restored from backup. This was not a happy discovery. It precipitated much command-line nerdery in an attempt to recover.
Luckily, there’s a straightforward (albeit nerdy) solution.
First, extract a recent iTunes backup. I used Super Crazy Awesome’s iOS Backup Extractor — it works, and it might not even contain malware. Once you’ve identified the backup you’d like to use, navigate to
com.apple.iBooks and extract its contents.
Now pop open
Terminal.app. Find the
iBooks_vXXX.sqlite file in the extracted directory structure and open it with
sqlite3. You can get the authors and titles of all sample books with this simple SQL query:
select ZBOOKAUTHOR, ZBOOKTITLE from ZBKBOOKINFO where ZSAMPLECONTENT=1;
That’s all it takes. Future cultural memory: restored.
Are your integration tests moving at a snail’s pace? Is test suite performance getting you down?
Good news: I’m here to tell you about
httreplay, a tiny new Python library that makes it a snap to record and replay HTTP requests.
How easy is it, you ask? This easy:
from httreplay import replay with replay('recording.json'): response = requests.get('http://example.com/') # ... issue as many requests as you like ... # ... repeat requests won't hit the network ...
Surely there must be a catch, you object? No ma'am.
httreplay works with HTTP and HTTPS. It patches all your favorite libraries, like
requests >= 1.2.3, and
urllib3 >= 1.6.0. What’s more, it’s trivial to install: just
pip install httreplay and start manipulating web requests like the champion you are.
Perhaps your needs are a little more involved? Never fear:
httreplay slices and dices, too. Need to filter out sensitive or inconsequential information from your URLs, request bodies, or request headers?
httreplay gives you all the hooks you need to get the job done:
from httreplay import replay, filter_query_params_key with replay('r.json', url_key=filter_query_params_key(['apiKey'])): response = requests.get('https://example.com/?apiKey=SEKRET')
But wait, there’s more! Act now and we’ll throw in mercifully readable documentation, including an example Django test base class, that will get you up and running in no time.
Best of all,
httreplay is available for the low, low price of $0. That’s right: nothing, nada. It’s MIT licensed and available on GitHub today!
A wave of childhood nostalgia hit me as I entered, of all places, the conference room. Five new paintings adorned the walls:
I used to have the robot with the dark red jewel-eyes when I was a kid! No idea who the artist is yet, but I’ll update this post when I find out.
We played our first game of content improv last night. When an audience shouts out a string of random words, sketch comedians don’t stare back blankly: they leap into action. They find connections; they make them entertaining. Last night, we spent time forming random connections between bits of pop culture and the topic at hand. What the punk movement portends for the future of digital security? Sure, why not. What online criminals can learn from Moonrise Kingdom? Yup. Beards and block ciphers? Check.
Out of this absurdity came a few surprising ideas and, ultimately, a fun new post. It’s not the next great American blog post, mind you, but it strikes balance between sweet and meat. Best of all: it was written in record time!
Content blogging is a grind. I post something new to the Cloak security blog every week, rain or shine. But I often find myself stuck along the way. Any process that clears out the creative cobwebs is worth mentioning; doubly so if it’s repeatable. There’s no magic to the improv; it’s simply a fun way to force us out of our mental cul-de-sacs and onto broader boulevards.
Big data is what happened when the cost of storing information became less than the cost of throwing it away. – George Dyson
My university had impressively old libraries filled with impressively older books. I’d wander through the stacks and try to spot the volume with the dustiest spine. If a book looked particularly unloved, I’d allow myself to open to its back flap and inspect the last stamped date of circulation. If it was old enough, I’d quickly thumb through the pages, cleaning interior dust as I went. Once in a long while, I’d find the time to read a page or two before I put the book back on its shelf — back into its information purgatory.
The Sciences Library was already fifteen stories tall, but I always imagined they could lift off its brutalist top and add unbounded new floors to house the growing collection. The architects had their work cut out for them, of course, as they’d probably need to grow the skyscraper exponentially fast. Over time, as I wandered the new floors above the clouds, I’d see fewer students — until one day I’d see none at all. After all, we could build the books but we couldn’t build ourselves fast enough to keep dusting off their pages, to say nothing of reading them. This realization was lovely if bittersweet: so many dusty books; so many pages so long forgotten. Without the hope of rediscovery, information purgatory looked indistinguishable from far crueler entropy.
Today, it’s bits, not pages. We can happily grow our library without bound. This time, there’s no need to break the endowment, and our structural engineers have the problem well in hand. Yet the same curves I imagined for the real apply just as well to the virtual: top-line information growth, an exponential over time; middle-line physical limits on our consumption, a linear function of our population; bottom-line limits on our ability to cogitate what we consume, a linear function of population at its hopeful best. Is the story again bittersweet: so many bits, soon to be so long forgotten?
We can never again visit all the bits by hand, but we now have tools that vastly amplify our reach. Today, search engines are seen as a powerful convenience; a means to find a thing we want. If the trends continue, perhaps they become something far greater: perhaps they become a light on our shared humanity. A century hence, what is a cultural anthropologist to do? Why, spin up a custom algorithm that explores a floor of the library long since unvisited, racing brilliantly amongst the stacks and dusting off a few forgotten bits along the way. Our understanding of ourselves will be inexorably linked to automated exploration of the bits we’ve left behind. We have the tools, but the algorithmic bestiary has only begun: a dizzying array of mechanical critters exploring our heritage. This, then, is George Dyson’s “big data”: a strange new land where information purgatory is hopeful and alive for perhaps the very first time.
Cloak turned 1.0 today!
This is our first public, non-beta, no-kidding-around release. We even signed an office lease in Fremont to show just how not-kidding we are.
We’re heading down to Macworld Expo in SFO this week to spread the word. And probably drink some beers.