rant – Page 3 – Tools of our Tools

Power corrupts, software ecosystems edition

I’ve written a lot of software in my day, but it turns out little of it has been for use of anyone but myself and others in the organizations for which I’ve worked.

Recently, my job afforded me a small taste of what it’s like to publish software. I wrote a small utility, an extension to a popular web browser to solve a problem with a popular web application. The extension was basically a “monkey patch” of sorts over the app in question.

Now, in order to get it up on the “web store”, there were some hoops to jump through, including submission to the company for final approval. In the process, I signed up for the mailing list that programmers use to help them deal with hiccups in the publishing process.

As it turned out, my hoop-jumping wasn’t too hard. Because I was only publishing to my own organization, this extension ultimately did not need to be reviewed by the Great And Powerful Company. But I’ve continued to follow the mailing list, because it has turned out to be fascinating.

Every day, a developer or two or three, who has toiled for months or years to create something they think is worthwhile, sends a despondent message to the list: “Please help! My app has been rejected and I don’t know why!” Various others afflicted try to provide advice for things they tried that worked or did not.

And the thing is, in many cases, nobody can help them. Because the decision was made without consultation with the developer. The developer has no access to the decision-maker whatsoever. No email, no phone call, no explanation. Was the app rejected because it violated the terms and conditions? Which ones?

The developers will have to guess, make some changes, and try their luck again. It’s got to be an infuriateing process, and a real experience of powerlessness.

This is how software is distributed today — through a small number of authorities. Google, Apple, Amazon, etc. If you want to play, you do it by their rules. Even on PCs and Macs there seems a strong push to move software distribution onto the company web stores. So far, it is still possible to put a random executable on your PC and run it — at least after clicking through a series of warnings. But will that be the case forever? We shall see.

The big companies have some good reasons for doing this. They can

assert quality control (of a sort. NB: plenty of crap apps in curated stores anyway)
help screen for security problems
screen out malware.

But they also have bad (that is, consumer-unfriendly) reasons to do this, like

monetizing other people’s work to a degree only possible in a monopoly situation
keeping out products that compete with their own
blocking apps that circumvent company-imposed limitations (like blocking frameworks and interpreters that might allow people to develop for the framework rather than the specific target OS)

All of those reasons are on top of the inevitable friction associated with dealing with a large, careless, monolithic organization and its bureaucrats, who might find it easier to reject your puny app than to take the time to understand what it’s doing and why it has merit.

Most sad to me is that the amazing freedom that computing used to have is being restricted. Most users would never use that freedom, but it was nice to have. If you could find a program, you could run it. If you could not find it, you could write it. And that is being chipped away at.

Apple Open Letter… eh

[ Updated below, but I’m leaving the text here as I originally wrote it. ]

By now, just about everyone has seen the open letter from Apple about device encryption and privacy. A lot of people are impressed that such a company with so much to lose would stand up for their customers. Eh, maybe.

I have to somewhat conflicting thoughts on the whole matter:

If Apple had designed security on the iPhone properly, it would not even be possible for them to do what the government is asking. In essence, the government plan is for Apple to develop a new version of iOS that they can “upgrade” the phone to, which would bypass (or make it easier to bypass) the security on the device. Of course, it should not be possible to upgrade the OS of a phone without the consent of a verified users, so this is a bug they baked in from the beginning — for their benefit, of course, not the government’s.

Essentially, though they have not yet written the “app” that takes advantage of this backdoor, they have already created it in a sense. The letter is therefore deceptive as written.

The US government can get a warrant to search anything. Anything. Any. Thing. This is has it has been since the beginning of government. They can’t go out and do so without a warrant. They can’t (well, shouldn’t) be able to pursue wholesale data mining of every single person, but they can get a warrant to break any locked box and see what’s inside.

Why should data be different?

I think the most common argument around this subject is that the government cannot be trusted with such power. That is, yes, the government may have a reasonably right to access encrypted data in certain circumstances (like decrypting known terrorist’s phones!) but the tools that allow that also give them the power to access data under less clear-cut circumstances as well.

The argument then falls into a slippery slope domain — a domain in which I’m generally unimpressed. In fact, I would dismiss it entirely if the US government hadn’t already engaged in important widespread abuse of similar powers.

Nevertheless, I think the argument that the government should not have backdoors to people’s data is one of practical controls rather than fundamental rights to be free from search.

I have recommendations to address both thoughts:

Apple, like all manufacturers, should implement security properly, so that neither they nor any other entity possess a secret backdoor.
Phone’s should have a known backdoor, a one-time password algorithm seeded at the time of manufacture, and stored and managed by a third party, such as the EFF. Any attempts to access this password, whether granted or denied, would be logged and viewable as a public record.

I don’t have a plan for sealed and secret warrants.

[ Update 2/17 11:30 CA time ]

So, the Internet has gone further and explained a bit more about what Apple is talking about and what the government has asked for. It seems that basically, the government wants to be able to to brute-force the device, and wants Apple to make a few changes to make that possible:

that the device won’t self-wipe after too many incorrect passwords
that the device will not enforce extra time-delay between attempts
that the the attempts can be conducted electronically, via the port, rather than manually by the touch screen

I guess this is somehow different than Apple being able to hack their own devices, but to me, it’s still basically the same situation. They can update the OS and remove security features. That the final attack is brute force rather than a backdoor is hardly relevant.

So I’m standing behind my assessment that the Apple security is borked by design.

Technical Support that isn’t

I’ve been doing a little progr^H^H^H^H^Hsoftware engineering lately, and with it, I’ve been interacting with libraries and APIs from third parties. Using APIs can be fun, because it lets your simple program leverage somebody else’s clever work. On the other hand, I really hate learning complex APIs because the knowledge is a) too often hard-won through extended suffering and b) utterly disposable. You will not be able to use what you’ve learned next week, much less, next year.

So, when I’m learning a new API, I read the docs, but I admit to trying to avoid reading them too closely or completely, and I try not to commit any of it to memory. I’m after the bare minimum to get my job done.

That said, I sometimes get stuck and have to look closer, and a few times recently, I’ve even pulled the trigger on the last resort: writing for support. Here’s the thing: I do this when I have read the docs and am seriously stuck and/or strongly suspect that the API is broken in some way.

As it happens, I have several years’ experience as a corporate and field applications engineer (that’s old-skool Silicon Valley speak for person-who-helps-make-it-work), so I like to think I know how to approach support folks; I know how I would like to be approached.

I always present them with a single question, focused down to the most basic elements, preferably in a form that they can use to reproduce the issue themselves.

But three out of three times recently when I’ve done this in the past month (NB: a lot of web APIs are, in fact, quite broken), I have run into a support person who replied before considering my example problems or even simply running. Most annoying, they sent me the dreaded “Have you looked at the documentation?”

All of those are support sins, but I find the last the most galling. For those of you whose job it is to help others use your product, let me make this very humble suggestion: always, always, ALWAYS point the user to the precise bit of documentation that answers the question asked. (Oh, and if your docs website does not allow that, it is broken, too. Fix it.)

This has three handy benefits:

It helps the user with their problem immediately. Who woodanodeit?
It chastens users who are chastenable (like me), by pointing out how silly and lazy they were to write for help before carefully examining the docs.
It forces you, the support engineer, to look at the documentation yourself, with a particular question in mind, and gives you the opportunity to consider whether the doc’s ability to answer this question might be improvable.

On the other hand, sending a friendly email suggesting that the user “look at the documentation” makes you look like an ass.

Culture of Jankery

The New York Times has a new article on Nest, describing how a software glitch allowed units to discharge completely and become non-functional. We’re all used to semi-functional gadgets and Internet services, but when it comes to thermostats we expect a higher standard of performance. After all, when thermostats go wrong, people can get sick and pipes can freeze. Or take a look at the problems of Nest Protect, a famously buggy smoke detector. Nest is an important case, because these are supposed to be the closest thing we have to grownups in IoT right now!

Having worked for an Internet of Things company, I have more than a little sympathy for Nest. It’s hard to make reliable connected things. In fact, it might be impossible — at least using today’s prevailing techniques and tools, and subject to today’s prevailing expectations for features, development cost, and time to market.

First, it should go without saying that a connected thermostat is millions or even billions of times as complex as the old, bimetallic strips that it is often replacing. You are literally replacing a single moving part that doesn’t even wear out with a complex arrangement of chips, sensors, batteries, and relays, and then you are layering on software: an operating system, communications protocols, encryption, a user interface, etc. Possibility that this witch’s brew can be more reliable than a mechanical thermostat: approximately zero.

But there is also something else at work that lessens my sympathy: culture. IoT is coming from the Internet tech world’s attempt to reach into physical devices. The results can be exciting, but we should stop for a moment to consider the culture of the Internet. This is a the culture of “go fast and break things.” Are these the people you want building devices that have physical implications in your life?

My personal experience with Internet-based services is that they, work most of the time. But they change on their own schedule. Features and APIs come and go. Sometimes your Internet connection goes out. Sometimes your device becomes unresponsive for no obvious reason, or needs to be rebooted. Sometimes websites go down for maintenance at an inconvenient time. Even when the app is working normally, experience can vary. Sometimes it’s fast, sometimes slow. Keypresses disappear into the ether, etc.

My experience building Internet-based services is even more sobering. Your modern, complex web or mobile app is made up of agglomeration of sub-services, all interacting asynchronously through REST APIs behind the scenes. Sometimes, those sub-services use other sub-services in their implementation, and you don’t even have a way of knowing what ones. Each of those links can fail for many reasons, and you must code very defensively to gracefully handle such failures. Or you can do what most apps do — punt. That’s fine for chat, but you’ll be sorely disappointed if your sprinkler kills your garden, or even if your alarm clock failures to wake you up before an important meeting.

And let’s not even talk of security, a full-blown disaster in the making. I’ll let James Mickens cover that territory.

Anyhoo, I still hold hope for IoT, but success is far from certain.

The great unequalizer?

This post is sloppily going to try to tie together two threads that have been in my newsfeed for years.

The first thread is about rising inequality. It is the notion, as Thomas Piketty puts it that r > g, or returns to capital are greater than the growth rate of the economy, so that ultimately wealth concentrates. I think there is some good evidence that wealth is concentrating now (stagnating middle class wages for decades) but I am certainly not economist enough to judge. So let’s just take this as a supposition for the moment. (NB: Also, haven’t read the book.)

There are many proposed mechanisms for this concentration, but one of them is that the wealthy, with both more at stake and more resources to wield, access power more successfully than most people. That is, they adjust the rules of the game constantly in their favor. (Here’s a four year old study that showed that in the Chicago area, more than 1/2 of those with wealth over $7.5M had personally contacted their congressional representatives. Have you ever gotten your Senator on the line?)

The second thread is about what technology does or does not accomplish. Is tech the great equalizer, bringing increased utility to everyone by lowering the cost of everything? Or is its role more complex?

The other day in the comments of Mark Thoma’s blog, I came across an old monograph by EW Dijkstra that described some of the belief of early computer scientists:

I have fond memories of a project of the early 70’s that postulated that we did not need programs at all! All we needed was “intelligence amplification”. If they have been able to design something that could “amplify” at all, they have probably discovered it would amplify stupidity as well…

If you think of tech as an amplifier of sorts, then one can see that there is little reason to think that it always makes life better. An amplifier can amplify intelligence as well as stupidity, but it can also amplify greed and avarice, could it not?

Combining these threads we get to my thesis, that technology, rather than lifting all boats and making us richer, can be exploited by those who own it and control its development and deployment can use it disproportionally to their benefit, resulting in a permanent wealthy class. That is, though many techno-utopians see computers as a means to allow everyone a leisure-filled life, a la Star Trek, the reality is that there is no particular reason to think that that benefits of technology and computers will accrue to the population at large. Perhaps there are good reasons to think they won’t.

In short, if the wealthy can wield government to their benefit, won’t they similarly do so with tech?

There is plenty of evidence contrary to this thesis. Tech has given us many things we could never have afforded before, like near-infinite music collections, step-by-step vehicle navigation, and near-free and instant communications (including transmission of cat pictures). In that sense, we are indeed all much richer for it. And in the past, to the degree that tech eliminated jobs, it always seemed that new demand arose as a result, creating even more work. Steam engine, electrification, etc.

But recent decades do seem a different pattern, and I can’t help but see a lot of tech’s gifts as bric-a-brac, trivial as compared to the basics of education and economic security, where it seems that so far, tech has contributed surprisingly little. Or, maybe that should not be surprising?

Simpler times, news edition

The other evening, I was relaxing in my special coffin filled with semiconductors salvaged from 1980’s-era consumer electronics, when I was thinking about how tired I am of hearing about a certain self-funded presidential candidate, or guns, or terrorism … and my mind wondered to simpler times. Not simpler times without fascists and an easily manipulated populace, but simpler times where you could more easily avoid pointless and dumb news, while still getting normal news.

It wasn’t long ago that I read news, or at least “social media” on Usenet, a system for posting on message boards that predates the web and even the Internet. My favorite “news reader” (software for reading Usenet) was called trn. I learned all it’s clever single-key commands and mastered a feature common to most serious news readers: the kill file.

Kill files are conceptually simple. They contain a list of rules, usually specified as regular expressions, that determine which posts on the message board you will see. Usenet was the wild west, and it always had a lot of garbage on it, so this was a useful feature. Someone is being rude, or making ridiculous, illogical arguments? <plonk> Into the kill file goes their name. Enough hearing about terrorism? <plonk> All such discussions disappear.

Serious users of Usenet maintained carefully curated kill files, and the result was generally a pleasurable reading experience.

Of course, technology moves on. Most people don’t use text-based news readers anymore, and Facebook is the de-facto replacement for Usenet. And in fact, Facebook is doing curation of our news feed – we just don’t know what it is they’re doing.

All of which brings me to musing about why Facebook doesn’t support kill files, or any sophisticated system for controlling the content you see. We live in more advanced times, so we should have more advanced software, right?

More advanced, almost certainly, but better for you? Maybe not. trn ran on your computer, and the authors (its open source) had no pecuniary interest in your behavior. Facebook, of course, is a media company, not a software company, and in any case, you are not the customer. The actual customers do not want you to have kill files, so you don’t.

Though I enjoy a good Facebook bash more than most people, I must also admit that Usenet died under a pile of its own garbage content. It was an open system and, after, a gajillion automated spam posts, even aggressive kill files could not keep up. Most users abandoned it. Perhaps if there had been someone with a pecuniary interest in making it “work,” things would have been different. Also, if it could had better support for cat pictures.

Non Vox populi

I liked Vox.com when it came out. The card format is cool, and the detailed yet bare-bones explainers suit my approach to many aspects of news: tell me what I need to know to understand this situation.

At first, I found the decision not to host comments interesting, but not alarming. After all, everyone knows that the Internet comments section is a bubbling cesspool, right?

But I’ve been reading Vox articles now for awhile, and I’ve noticed in too many cases, when they were just blowing it: incorrect or out-of-context facts, telling one half of an argument, or missing a crucial detail. And these are the kinds of things where a letter to the editor, or a stream of informed comments, can really make an article much more useful. I notice this particularly when Vox writes about energy, a topic I have studied in depth.

Here’s an example of the sort of thing I’m talking about. In “Ignore the haters: electric cars really are greener,” they cite a new Union of Concerned Scientists report at length. But they never mention that UCS is primarily an advocacy organization, not a research one. Or that, for example, Argonne National Labs has been publishing similar research for years with similar, but with slightly more muted results. Or even that the summary in the UCS report compares EVs against normal gasoline cars, which is hardly a like-vs-like comparison, given that gasoline vehicles execute a range of missions that EVs currently cannot. As it turns out, a PHEV or even a regular hybrid does in fact outperform an EV on CO2/mile in many parts of the country, and the data in the UCS report show it. And there are additional embedded assumptions, like that the electric grid will continue to get greener. That’s probably true, but maybe not, the greening of the grid could accelerate or it could start hitting hurdles that slow it down. At the same time gasoline cars could get better or worse. Hybrids might become the norm, lower carbon fuels could become mainstream, etc. Finally, EVs cost a lot more than gas cars. For the same money, could you reduce your carbon intensity more effectively than by buying an EV? (Answer: yes.) In the end, it’s hardly journalistic to lump everyone who has questions about the superiority of EV’s as a hater.

Getting back to Vox, it’s not just the bias that I don’t like. After all, bias is a part of journalism as organic chemistry is part of life. There’s no ombudsman, there’s no straightforward place to look for corrections. (They integrate corrections directly into cards, usually by changing the text without any notation.) The whole site is a Read Only Memory. In Ezra Klein’s own words on leaving the WP to found Vox: “we were held back, not just by the technology, but by the culture of journalism.”

Indeed. So, this is the improved technology and improved culture? It’s seriously starting to turn me off. Anybody else?

Garbage can strikes again

When I was in policy school, we learned about something called the “Garbage Can Model of Organizational Choice,” which for some reason has stuck with me. I don’t want to boil it down too much, but in it, Cohen, March, and Olson (and later, Kingdon) theorize that people are constantly coming up with “solutions” that more or less end up in a theoretical trash bin. Except, nobody ever empties the trash. Instead, it lingers. At the same time, the random stochastic process known as life generates a constant stream of problems. Every once in awhile, a “problem” comes along that fits a “solution” waiting in the trash can, and if there’s an actor who favors that solution who has been paying attention and waiting patiently, he trots it out and starts flogging hard.

In light of the Paris attacks, we’ve been seeing this from the security establishment in a big way. They like tools that let them see and watch everything, and they do not like anything that gets in their way. So, for example, banning encryption that they cannot defeat is a solution that sits in the trash can perpetually. That’s why it’s unsurprising that the ex-CIA director is calling for Edward Snowden’s hanging or Dianne Feinstein and other senators are railing against Silicon Valley for offering its users strong encryption.

It’s all about having an established agenda and seizing an opportunity when it comes along. Politics as usual, move along, these droids are not particularly interesting.

But there is actually something a bit interesting going on here. The actual facts and circumstances right now do not support the panopticon theory of governance favored by intelligence and law & order types. The terrorists in this case did not use encryption. They sent each other SMS and other messages completely in the clear. If you look in the Internet, you will find article after article debunking the notion that controls on encryption would have made a difference in these attacks at all.

In fact, given the circumstances of this particular case, it looks like the intelligence agencies already had all the tools they needed to stop this attack. They just didn’t. This, if anything, should be the actual story of the day!

Okay, so this is perhaps also not interesting to the jaded news junky. Maybe it’s a bit further down in the playbook, but we’ve all seen people who should be on the defensive go on the offensive in a big, loud way. But I still find it disturbing that the facts are not steering the debate at all. If you enjoy making fun of fact-free conservatives, then this is not the circus for you, either, as powerful Dems are behind this crap.

Various media outlets, even mainstream ones, are calling out the bullshit, but the bullshit continues.

Same as it ever was, or new, disturbing political discourse untethered to reality. You decide.

Oh, and just as an aside: you can’t stop the bad guys from using strong encryption. So what are you actually calling for?

Un-American Things

Barack Obama and Ted Cruz are currently having a bit of a one-sided insult match in response to the president suggesting that rejecting Syrian refugees, or only letting in refugees in who meed certain religious criteria, is un-American.

You won’t be surprised to hear that I think The President is right, of course. Our highest ideals are of opportunity and openness, and I think we all want to live in a country that is the destination for those in need to rebuild lives shattered through forces beyond their control.

But the president is also right in another way that I think is interesting. This country does not have a culture of risk-aversion. Or at least it doesn’t regarding most new things. I mean, let’s grant for the moment that letting in Syrian refugees means we are opening ourselves to some non-zero incremental risk of violence. Why shouldn’t we take that risk? We’re risk takers.

This is not a country that adopts the precautionary principle to food and environmental regulation. We don’t stop Uber and Airbnb before they get started because they might be unsafe. Nobody (federally) says, “sure, you can have a gun, after you show us you can handle it safely.” You want to use some new chemical you just invented in your industrial process? Have at it (generally), until we know it’s dangerous. So it goes. Nuclear power, moon exploration, homesteading the West. In the cases where we do have regulation, I think you’ll find 100% of the time that it came after something bad happened regarding the very thing being regulated.

And I think that’s more or less a fine, and certainly, very American philosophy. We’ve had some very bad outcomes here and there (leaded gas), but on average, the risks have worked out in our favor and we get more benefit than harm. In the case of Syrian refugees its a question of compromising our ideals to gain a little safety. Totally un-American.

Throwaway knowledge

I was recently tasked with writing an pretty useful extension for Chrome that would enhance Google Calendar so that room numbers on our campus would show links that would take you to campus’s internal map tool. Google Maps does not understand this campus, so the normal map link provided is not helpful.

This task took me the better part of a day and a half, and the whole time I was gripped by this awful feeling that in order to solve this simple problem, I had to learn a bunch of random stuff that would be mostly useless as soon as I was done.

For example, I needed to learn how Chrome extensions work. For that, I needed to familiarize myself with the Google Chrome API — at least enough to get this job done. I can say for sure that even in the small amount of time I spent on that task, I could tell that this API is not stable. They change it as often as they feel like, adding this, removing that, and most ominously “deprecating” some other things. Depracation is the worse. It means “we’re not taking this function way today, but we are taking it away, probably when you least expect it.” And, in any case, how many Chrome extensions is the average programmer going to write?

Furthermore, getting into Google Calendar enough to insert my links was an exercise in pure disposable hackery. I had to reverse engineer enough of Calendar to figure out where to scan for locations and where to insert links. And I needed to understand how Calendar works well enough to know when it is going to change up the document model and set event handlers for that.

This script works today, but it’s obviously going to break, probably very soon, because Google can and will change the internal guts of Calendar whenever they please. Unlike the extension API mentioned above, they are under no obligation, not even an twinge of guilt, to hold their internal implementation of Calendar to some fixed standard.

All this points to some rather sad facts about the future of coding for the web. You’ll absolutely have to work through the supported APIs, and when they change, that’s your problem, and if they are not offered or are incomplete, that’s also your problem, and if they go away, also your problem. Compare that, for example, to a piece of software on your PC. Maybe you wrote an ancient MSDOS .bat file that does something with the input and output of an old program you liked. If the company that made the program makes a new version that breaks your script, you could upgrade to it when you want to — or never, depending on what was convenient for you.

I’ve already been bitten by this. I made an alarm clock that interfaces with Google Calendar using a published API. It is a nice alarm clock with a mechanical chime handmade by hippies from Woodstock, NY. It worked, just fine for years, until, one day, it stopped working. Google had deprecated, and then dropped the API the clock was using. There was a new API. I had to go to my years-old code and rewrite it (to use a substantially more complicated API, by the way).

I guess that’s life, but people who make alarm clocks for a living may be surprised that users want them to provide active support and software upgrades forever. Or maybe we’ll just throw out our clocks after a year or so, like a phone.

But this is a mere annoyance compared to my main concern: unstable platforms discourage the development of knowledge and expertise. Why learn anything well if the entire API, or hell, the only supported programming language, or even the entire theoretical framework for working with the API (does anybody seriously think REST with PUT, GET, and POST is going to last forever?) is going to change next Wednesday? Perhaps that’s why in my interviews with Google nobody ever seemed to care one whit about any of my knowledge of experience.

I, for one, welcome the coming generations of ADD-afflicted software engineers and am excited to see the wagonloads of new “wheels” they’ll invent.

Yippee!