Yesterday Tim Lee and Ashkan Soltani reported a surprising and alarming revelation: some webcams can be activated without their accompanying light being turned on. This means it’s conceivable that criminals or government agents could compromise your computer and take surreptitious pictures of you. It’s a frightening prospect.

It’s also one that I had more or less deemed impossible based on what I know about electrical engineering. I owe Tim and Ashkan my thanks for teaching me something new.

But I think it’s worth delving into exactly what makes this attack possible. The paper their story focuses on concerns one particular attack on one particular type of webcam. Left unanswered is whether vulnerabilities like this one are commonplace. Examining how this attack works can provide some reassurance about engineers’ good intentions, but leaves plenty of reasons to worry about their insufficiency.

You can find the paper detailing the attack here (thanks, guan!).

Before we walk through how the attack works, let’s establish our cast of characters — one that’s slightly simplified relative to the specifics of this attack, but which will suffice for our purposes.

First, there’s your computer. It looks like a computer, and behaves in a computerlike fashion.

Second, there’s the webcam microcontroller. This is also a computer! But it’s a much tinier, lousier computer — one that fits on a single microchip. Still, it can run programs, and it can talk to your computer. And we’re not going to ask it to do very much: mostly it’s just supposed to manage the other components in the webcam and report their outputs back to the computer when asked.

Third, there’s the image sensor. It’s digital and electronic, certainly, and it even speaks binary code and executes commands, but it doesn’t run arbitrary programs. It does have internal states and settings, though — it’s not a completely passive, memoryless device like a lightbulb or motor.

Here’s the key diagram from the paper:

On the bottom is the microcontroller. On the top is the image sensor. There is a connection between the two of them labeled “standby”. When operating normally, the image sensor will go into standby mode whenever the microcontroller sends a voltage to this connection.

On the right side of the diagram is the LED. Its input side is connected directly to the system’s power source (V_cc), and its output side is connected to the “standby” line. A circuit can only do work when energy flows through it, so when both sides of the LED are set to the same voltage — when the standby line is “high” — no current will flow and the LED will remain dark. When the voltage on this connection is low, the image sensor will emerge from standby mode; current will flow from V_cc, through the LED and out the “standby” line; and light will be generated.

This is a pretty good system! The LED’s function is tied directly to something that enables or disables the image sensor. This arrangement can’t be undone without cutting wires. Really, that “standby” line looks a lot like a power switch.

But it isn’t. The image sensor was designed to be a flexible component that might be used in many different configurations, not just the iSight. This is the norm in electronics, with a few exceptions like the custom chips that Apple designs for its iPhones. In this case, the image sensor can be configured in different ways by sending it different setup commands from the microcontroller. One can imagine modes for “low light” or “video” or “grayscale”, but there are also numerous esoteric settings that are only useful to engineers. In the case of this particular image sensor, it’s possible to tell it to ignore any signals it sees on its “standby” pin.

This probably sounds pretty outrageous, but it’s not hard to imagine configurations in which this capability could be useful. When prototyping a circuit, minimizing the number of features and connections that must be used can make the process faster and simpler. In some applications the image sensor might be on all the time, making a usable “standby” line irrelevant (or, if not properly grounded and shielded, even a source of buggy behavior).

Alternately, it might seem outrageous that the engineer designing the webcam system overlooked this capability in the image sensor. This is a stronger argument. But this is an easy mistake to make.

Here’s the datasheet for the image sensor. At 61 pages it’s not especially long (microprocessor datasheets can be thousands of pages), but I think you’ll agree that it’s not the easiest thing to read. What you probably can’t see is that datasheets are often riddled with errors. They are usually written by engineers, which produces a terrible product but is better than the alternative. As you might imagine, the result is more or less impervious to editing and verification by humans. Datasheets for very popular or venerable chips can be very good, but for complicated, new or little-used products, they can contain serious problems. Partially for this reason, datasheets often contain information about “reference implementations”: partially or wholly built systems that show how the component is supposed to be used with a minimum of complicating details, and which engineers are implicitly encouraged to follow without question.

None of this excuses the webcam engineer’s failure to foresee this security hole. But you can imagine how it happened. Having someone manipulate this completely undocumented hardware system, reprogramming a microcontroller to, in turn, reprogram an image sensor to use a counterintuitive operational mode that (for all I know) might be completely idiosyncratic to this image sensor chip? It’s tough to get too angry over someone’s decision to spend their time on other problems.

Is this comforting? Sort of. It’s an awfully specific vulnerability. It’s pretty easy to see how to design around it (use the LED to test for power to the image sensor, not the state of its standby line; harden the microcontroller’s programming; the paper’s authors discuss a number of possible remedies and the occasional tradeoffs they entail). It’s clear that the engineer was trying to tie the LED’s activity as closely and irrevocably to the image sensor’s operation as he could, which is the right idea. We have no specific reason to think that similar bugs are present in other webcams that use different chips or have more careful authors.

Still. This is a reminder that the systems we use are wildly complex, executing code in many more places than just the CPU. And it’s increasingly clear that many of those places have never been scrutinized for vulnerabilities. It’s cheering to see security researchers uncover these problems, but criminals and governments have vastly greater resources and incentives to pursue this work, and have had plenty of time to do so. Some masking tape might not be a bad idea.

I often find myself defending Sam Biddle’s brand of Silicon Valley nihilism to Matt, so I’m sort of surprised to see us switching sides: today Matt joins Sam in deriding President Obama’s calls to teach schoolkids to program. He’s not alone! I think Matt’s specific objection doesn’t get us very far — some students’ failure to attain basic skills doesn’t really tell us all that much about what should be included in a general curriculum, just as the continued existence of murder doesn’t tell us much about the wisdom of enforcing speed limits.

But it is worth spelling out the case for teaching people to code. It’s not because we expect them to become programmers. We don’t expect every student in English class to write a novel or every student in Trigonometry to wind up manipulating triangles for a living. We certainly don’t expect every kid in music or art class to carry those skills beyond the classroom, or even to achieve proficiency within it.

Rather, we teach those skills because they are varyingly enriching and instructive windows onto reality and culture. They help kids navigate the world. In a few cases they’ll wind up being of practical value or make for a fulfilling hobby. But mostly they’re about building competent and intelligent human beings.

Coding qualifies. I still distinctly remember programming my grandparents’ VCR for them — a cliche of childhood technical affinity, yes. But also an instructive experience! Why was the schedule set with a 24-hour clock scheme? Why were the on-screen fonts the same across different brands of VCR? What the heck was the difference between SP, LP and SLP? The answers involve the nature of modulo arithmetic, the electronic industry supply chain and electrical engineering practices, and some pretty fundamental concepts from information theory. Some of these revealed themselves quickly; others came decades later. Gaining that simple, unimportant technical skill gave me a window into how engineers’ minds work and how the constraints imposed by physical reality shape the systems they build.

Without realizing it, the simple daily use of technology imparts lessons about data normalization, computability and signal processing. Stitching these hunches together with a light classroom introduction to the procedural nature of Turing-style computation is not a bad idea. It’s also not a trivial idea — some people think this perspective has enough explanatory power to describe the entire universe.

Nor is it of merely intellectual interest (though I’ll happily admit that I do find it deeply intellectually rewarding). In the same way that the economic perspective has largely triumphed over other dialectic forms in our culture, our physical environments grow ever more engineered. And engineering grows ever more digital in nature. Understanding how those processes work at a fundamental level is an increasingly necessary precondition to deciphering our deeply unnatural world.

Do you want to be able to quickly use a new product? Or organize a spreadsheet so that it will be useful later on? Do you want to know why your partner missed that SMS, or why the football broadcast looks blocky? Do you want to know what to fear, and when you’re being lied to, and how?

Learning to code “hello world” won’t guarantee you those answers any more than it’ll guarantee you a job at Facebook. But it isn’t a bad place to start.

Broadcast sports is finally, finally embracing the digital age. My Apple TV has separate apps for the NHL, NBA and MLB, for instance. Sadly, these are still subject to blackout restrictions, preventing me from being able to purchase Capitals games. Irritating!

As it happens, I have a pay-as-you-go account with IPredator, a Swedish VPN service. For a few bucks a month, they provide the ability to use a high-bandwidth encrypted link that terminates your internet traffic in Sweden. I mostly use this for Bittorrent (though pretty rarely, believe it or not). But I figured it might let me get around blackout rules, too.

Unfortunately, the Apple TV isn’t able to use VPN software. So we need something to handle that operation instead, making the Apple TV think that it’s on a perfectly normal network — albeit one in Sweden.

This had been on my to-do list for a while, but I finally got around to tackling it today. The results are pretty good! Sadly, it appears that hockey-crazy Sweden has blackout rules of its own — presumably the NHL has a distribution deal with some broadcaster there that makes it necessary to confound people like myself who want to pay to watch hockey but don’t care to pay for a complete cable TV package. Bah.

But the system is working — a laptop substituted for the Apple TV is convinced it’s sitting in Stockholm, and my Apple TV Netflix experience is substantially different (title availability is wildly altered). And the NBA League Pass stuff looks like it might be working fine (I don’t have an account, but will be bugging Matt to try his out shortly).

So I’ll go ahead and record what I did here before I forget it. Perhaps before too long I’ll switch to a VPN that terminates in a (non-Washington) US city and see if that doesn’t solve my problems.

1. Buy a Raspberry Pi Model B (the one with the on-board ethernet jack). Get the basic Raspbian distro up and running.
2. Add a USB ethernet adapter — one with Linux support. Note that I haven’t tried the one at that link, but it claims to be Linux-friendly. I’ve been using an overpriced Apple adapter.
3. The USB ethernet port is eth1, and will be what you plug your Apple TV/whatever into. The on-board Raspberry Pi ethernet port is eth0, and should be connected to your router.
4. Follow LadyAda’s instructions for making your Raspberry Pi into a wifi access point — except skip everything that has to do with hostapd or iptables. Also, replace references to “wlan0″ with “eth1″. After rebooting, you should now be able to plug a computer into the USB adapter via ethernet and receive an IP address that begins with 192.168.42. If you can’t, something is wrong.
5. Configure OpenVPN for IPredator using their Debian setup instructions. When running, this creates a virtual network adapter called tun0 — it’s quite similar to eth0 or eth1 (the ethernet cards) except it’s a software abstraction. Also, configure this to start up automatically — the IPredator instructions gloss over this. It shouldn’t take more than a “sudo update-rc.d openvpn enable”.
6. Use the following iptables configuration to make the Raspberry Pi act as a router that sends incoming traffic to tun0:
   

   # Generated by iptables-save v1.4.14 on Sun Dec 1 13:49:10 2013
   *nat
   :PREROUTING ACCEPT [329:25039]
   :INPUT ACCEPT [194:13371]
   :OUTPUT ACCEPT [0:0]
   :POSTROUTING ACCEPT [0:0]
   -A POSTROUTING -o tun0 -j MASQUERADE
   COMMIT
   # Completed on Sun Dec 1 13:49:10 2013
   # Generated by iptables-save v1.4.14 on Sun Dec 1 13:49:10 2013
   *filter
   :INPUT ACCEPT [1384:725715]
   :FORWARD ACCEPT [877:601931]
   :OUTPUT ACCEPT [1102:200985]
   -A FORWARD -i eth1 -j ACCEPT
   COMMIT
   # Completed on Sun Dec 1 13:49:10 2013

   You can grab the gist here. Save this into /etc/iptables.up.rules then create a file called /etc/network/if-pre-up.d/iptables that contains the following:

   #!/bin/bash
   /sbin/iptables-restore < /etc/iptables.up.rules

   Give it a good “sudo chmod +x /etc/network/if-pre-up.d/iptables” to make it executable and, if all has gone well, you’re done! You now have a Raspberry Pi that lets network traffic go in one end and emerge in Sweden. Kinda neat.

I like to make a new Halloween decoration every year. One year it was corpsing a skeleton; another year I built a coffin; another time I made some big glowing papier mache spiders.

This year I decided I wanted some skulls. Goat skulls, ideally — dollar for dollar, I don’t think there’s a creepier skull out there. Probably it’s all the Doom 2 I played as a kid.

I posted an ad on Craigslist appealing to hunters and farmers for help with (ahem) a “theatrical production.” Eight days later I received a response. “Kyle” worked at Crazy K Goat Ranch, and he seemed to have a lot of skulls; we made plans to meet a few days later. I brought along Dave and Kriston to ensure that the encounter’s net flow of skulls went in the direction I expected.

It only took a moment to verify that Kyle was probably the K in “Crazy K”. He was certainly a strange guy. He seemed to live with his parents, and I’m not at all sure that the goat farming is a full-time occupation for him. But he was very nice to us, particularly since I happened to be wearing a Capitals t-shirt — Kyle was, too, and turned out to be a bit of an Alex Ovechkin super-fan.

$20 per skull is a steal, and we concluded our business quickly. Kyle sold me the skulls of a bunch of goats, an alpaca, a llama, and a pig that had (until recently) been giving him trouble. There is apparently some kind of solution he soaks them in to remove the soft tissue — it’s intensely unpleasant, I’m sure.

Anyway: I had some skulls.

A good start! But I wanted to do a little more. And hey: I’ve achieved pretty good results with creepy glowing eye sockets before. Let’s do some more of that.

The basics are pretty simple. The idea of an LED throwie is at least seven years old now (can that be right?) but it works as well as ever. Let’s pause for a brief interlude about sticking them all over the cube at Astor Place:

Nice.

Well, the gist is the same as always: the LED and the CR2032 battery are a lovely match. The CR2032′s 3 volts are enough to light up most LEDs. Better still, its internal resistance will prevent the LED from burning out immediately, even when used without a resistor. You can wedge a CR2032 between an LED’s leads and it will light up quite happily for hours! And hey, it turns out that these batteries aren’t even that terrible for the environment.

You can get all of these components very cheaply on eBay. Here are fifty red LEDs for $3; here are 20 CR2032s for a little more than $4. If you want to get fancy (and I did) you can get CR2032 holders for about fifty cents a pop.

Wiring the necessary circuit is dead-simple. I have a distinct memory of getting a small light bulb to illuminate from a battery in second grade; it was the first thing they taught us about electricity. This is no more complex, except that you might need to flip the LED around if you get the polarity wrong the first time. So, no need to belabor that. Also: it turns out hot glue guns work well on bone.

But for a few of the more frightening skulls I went a little further and added a circuit that turns the lights on only when the surrounding environment is dark. It’s a pretty useful technique for working with analog signals of any kind (I’ve also used it to trigger a light-sensor to activate a music box upon opening, for instance), so let’s go ahead and run through it.

We’ll need three things to make this happen. First, some way of sensing light — that much is obvious. Second, a way to define what our threshold for “dark enough” is. Third, a way to compare the two values and switch the LED circuit on.

Let’s start with the last one. I used an LM393 comparator, a common chip that looks like this:

It, too, can be found on eBay for pennies per unit.

The LM393 is very simple. It takes a reference voltage. It takes a comparison voltage. If the latter goes above the former, the chip will make an electrical connection between its output pin and ground, potentially completing a circuit and doing useful work.

The LM393 also looks like this:

That’s the schematic from its data sheet, mapping the chip’s 8 pins to their functions. Pins are numbered in counter-clockwise order, starting to the left of the chip’s top side, which is marked by a little notch or off-center circle (or, in the above photo, both). As you can see, there are actually two comparators built into the LM393; we’re only using one. For our purposes they’re electrically distinct, except for a shared ground and supply voltage (V+ in the diagram, though it’s more commonly called V_cc). The LM393 can run off anything from 2 to 36 volts.

So how do we arrange the reference and comparison voltages? It’s really simple, actually: we use a voltage divider. Picture it like this:

V_in is our supply voltage — let’s say 10 volts. The horizontal triangular thingy at the bottom is ground. R₁ and R₂ are resistors connected to one another. At the top, it’s always gonna be 10 volts. At the bottom, it’ll always be zero. That’s axiomatically true. But what about in between the resistors, at V_out?

That depends on the values of R₁ and R₂ — or, really, the ratio between them. If they’re both 100 ohms, or 2500 ohms, or 5 million ohms, V_out will be 5 volts. If R₁ is 25 ohms and R₂ is 75 ohms, V_out will be 7.5 volts. If you flipped them, it would be 2.5 volts. It’s all pretty linear and straightforward (the Wikipedia voltage divider article will walk you through the math, if you’d like). Make sense?

So! Let’s set things up. Keep the battery out of the holder until you’re done, but pretend it’s in there — now we have a 3 volt V+ and a ground. Connect ‘em to the relevant pins on the LM393. Now take two resistors — doesn’t really matter what value, as long as they’re the same, but they should be a decently high value to avoid voltage drain — and connect them in series, bridging V+ and ground BUT, crucially, making a pit-stop in the middle at pin 5 (“non-inverting input B”). That pin will now be getting a reference voltage of 1.5 volts. If the voltage on pin 6 (“inverting input B”) goes above this value, pin 7 will be connected to ground. If not, not.

But what gets connected to pin 6? Well, seems like we need something that changes its value based on light. Easy enough! A photoresistor is just what it sounds like and is, again, cheap on eBay. They look like this:

That squiggle in the middle is made of a material that lowers its resistance as light hits it. Otherwise, this thing behaves just like a regular resistor. That means we can build a voltage divider with it, just like the one we connected to pin 5. What should we use for the other resistor in the voltage divider circuit, though?

We could just use a regular old resistor. But we’d have to be pretty careful about picking it, and it would lock us in to one particular level of darkness as our threshold value. That’s not a great idea, particularly since human senses respond to energy changes adaptively and logarithmically, while sensors do not.

It will be much better to use a variable resistor — a potentiometer. Back to eBay! These guys come in many different forms, but for this we can get away with a the teeny tiny ones that you adjust with a screwdriver (sometimes called “trim pots” or “trimmers”).

Picking the appropriate range for the potentiometer is important. We want something that will let us flirt with the half-of-V+ comparison voltage we already defined via the divider we built out of those first two resistors. In this case, that means getting out a multimeter and figuring out the range of your photoresistor. Test it in darkness; test it in daylight. Try to find a trim pot that can approximate this range of resistances, or at least one that can be adjusted to somewhere around the photoresistor’s value in slightly-too-bright-for-goat-skull-glowing conditions.

Now make a voltage divider with these two — it’ll be the same deal as before, just connected to a different pin. The photoresistor lives on the side of the circuit closer to ground. The trim pot lives on the side closer to V+. The junction between the two goes to pin 6.

Finally, connect the ground side of the LED leads to pin 7. This is the final schematic:

I did all of this in “deadbug” style:

Now wait until it’s dark in the room and adjust the trim pot until the lights juuuust turn on. Voila!

When it’s brighter, the circuit should turn off. You’ll want to fiddle with the placement of the photoresistor — I gave mine a little wire lead and ran it out to the edge of the skull. It doesn’t need to be in direct light, but obviously it does need to experience some change in lighting conditions, and the bigger those changes are the easier it will be to select and adjust your trim pot.

The batteries will experience some drain even when the LEDs are off, but the LM393 is designed to consume very little juice. The voltage dividers take a little bit of power, but hopefully you picked elements with adequately large resistive values. If your in-light resistor networks both amount to 10K ohms apiece, your total system will consume about 1 milliamp at rest. Not bad! At that load, a fresh CR2032 should last for about 200 hours (less if the LEDs are activated, of course).

The LM393 makes for a fun little project — a nice way to build a night-light, or clean up an input signal to an Arduino, or just have something to mess around with on a breadboard. If you flip the two input pins, it’ll become a light detector rather than a darkness detector. It’s useful for almost any variable-voltage measurement of the analog world. I originally bought these components for a project designed to use a thermistor to tell me when a cup of coffee was a pleasant temperature for drinking.

So, somewhat far afield from skulls. But the nice thing about this application is that there’s really no precedent for anyone getting upset about mixing electricity and illicitly-obtained body parts.

Well, that was great. It’s been a few years since I’d been able to throw a proper Halloween party — the Fickeweens of yore formed the start of a proud tradition, but without a venue my various skeletons’, giant spiders’ and fog machines’ annual appearance was relegated to a fun-but-sadly-professional office open house.

But Annie and Ezra bought a new place this year and heroically stepped in to fill the void. And we had a great time! I put a bunch of the pictures here; the best are probably the ones I collected from Instagram. Sorry, people who still believe in copyright! Let me know if you’d like me to pull anything down; my interest is just in making sure this stuff gets saved. And if I missed anything that you think I should have here, let me know about that, too.

The quality of costumes was very, very high — I was particularly thrilled by Josh’s obscure Hellboy reference. But there were a ton of great efforts present.

In a departure from my streak of dressing up as supervillains with romantic problems (which, to be fair, is most of them), I went as Mr. Fantastic. I wanted to concentrate on the party, and this was relatively easy to pull off — just (yet another set of) Under Armour and a layer of white duct tape on top of part of my Omni-Man costume.

People did get a kick out of the electroluminescent panel I used for the logo on my chest, though. Like everything else that is good in this world, you can buy this material from Chinese vendors on eBay — it comes in various sizes and colors. Attached to an inverter — which requires a meager 2 AA batteries — it’ll change from a pink to a cool white glow. Pretty neat! You can cut the material down, too, but bear in mind the delicate nature of the foil that makes the electrical connections. Adhesives and solder won’t work — you’re going to need to clamp your connections. I found that paper binder clips did a good job. Conductive paint or glue might work, but I didn’t have any on hand.

An even more important Halloween costume innovation: the duct tape smartphone pocket. Man, what a quality of life improvement. Highly recommended! Add a little adhesive velcro if you really want to class things up.

I made one for myself and one for Steph, too — she put together a great version of Debrie-from-Arrested-Development-as-Sue-Storm, making for what I think was a quite successful (if slightly textually complicated) couples costume.

Anyway! More on this year’s specific decorative efforts in a separate post. For now: many thanks to everyone who came out; to Annie and Ezra for opening their house to this stupid hobby of mine (and buying everyone beer!); and to Steph for putting up with my weird obsessiveness these past few weeks.

I should perhaps confess that on September 11 last, once I had experienced all the usual mammalian gamut of emotions, from rage to nausea, I also discovered that another sensation was contending for mastery. On examination, and to my own surprise and pleasure, it turned out be exhilaration. Here was the most frightful enemy–theocratic barbarism–in plain view… I realized that if the battle went on until the last day of my life, I would never get bored in prosecuting it to the utmost.

Christopher Hitchens made that ugly little confession. Today, safely on the other side of the government’s two week shutdown, I’m feeling a similar shame.

The embarrassing truth is that for those who work in and around politics, the shutdown was great. It was something to gossip about, write about, get indignant about. It was exciting! And it was good for business.

For the press, acknowledging this is easy enough: that discipline has had a lot of practice at explaining its responsibility to document travesties without averting them. Here’s Robert Costa making the transition from “guy who works with Jonah Goldberg” to “conservative press corp dean / less creepy reincarnation of Bob Novak.” He’s far from the only writer lamenting-the-shutdown-but-not-really:

Sigh. I miss the crisis already.— Josh Barro (@jbarro) October 16, 2013

Real talk: These wild demands from Congressional Republicans were great for Web traffic. The standoff will be missed.— Matt Yglesias (@mattyglesias) October 16, 2013

The effect exists outside of the media. The shutdown was good to those of us who occuppy ourselves watchdogging the government. Here’s my friend Josh Tauberer, who runs GovTrack.us:

Web traffic to the vote pages finally peaking, ending 16 days of profit.— Joshua Tauberer (@JoshData) October 17, 2013

I can sympathize. Sunlight’s blog saw a modest 10% boost in traffic during the shutdown relative to the two weeks preceding it. But our iOS and Android mobile apps, which provide information about Congress, saw usage spikes of 186% and 195%, respectively. We don’t sell ads, but our funders care about those numbers. And I’ve probably fielded more press calls in the last two weeks than the preceding six months (admittedly, many of these have been about healthcare.gov’s failures, not Congress’s, but I think that’s still in the neighborhood of profiting from human misery).

Perhaps unsurprisingly, the people most responsible for the shutdown have benefited from its effects, too. We’re still tallying the latest quarterly numbers, but anecdotal reports indicate that the crisis helped people like Ted Cruz raise a lot of money. Fundraising emails from both parties latched onto the shutdown as a moneymaker right from the start.

I spent the final days of the shutdown at a conference in San Francisco, where I gossipped with a fellow traveler about a shared acquaintance’s new-ish cable news show, and how a shutdown-prompted ratings boost had taken it safely off the bubble. And Twitter analytics tell me that I went from an average of 12.7 tweets per day to a manic 17.8 during the shutdown! Oh, the fun that I had!

This wasn’t true for many people who depend on a federal paycheck. Although my girlfriend was glad enough to have a nasty deadline moved by the shutdown, when I callously referred to “workers being paid for sitting around doing nothing” on an internal office listserv, I invited several deservedly angry replies from the spouses of feds. My friend Dave is a Capitol Hill staffer; for him this episode has meant incredibly-longer-than-usual work days and the possibility of a nonsensical pay cut (staffers are already badly underpaid).

And this is to say nothing of the cancer patients who had to delay treatment, or the people on SNAP and WIC who faced the very real prospect of going hungry because of Washington’s preening.

It’s not that I think we should be ashamed, exactly. I’m genuinely proud of the work that I and my colleagues did during the shutdown. People wanted the information we provided. We think it’s important, and we’d have been fools not to respond to a sudden surge of public interest in the mission we pursue every day. I think that every non-legislator mentioned above should be proud of the work they did, too. I was disgusted by this crisis, and I said so, but I couldn’t stop it–none of us could.

But it’s worth owning up to the fact that the incentives within the D.C. media-nonprofit-industrial complex are terrible. S&P says this escapade wasted $24 billion. We have to stop doing this. Removing these processes from the realm of human theatrics, gossip and competition will be a necessary component of that change. Mostly, that means getting rid of the debt ceiling and electing better legislators. But part of it might also be about having less fun.

Or not, whatever. This was a thrill for me, and my colleague Nicko was kind enough to make me a GIF, so I’m sticking the links here for posterity.

I need to add, though, that although I have worked on these issues first-hand and know a bit about them, my knowledge absolutely pales in comparison to that of my current and former colleagues Kaitlin Devine, Drew Vogel and Kevin Webb. They deserve credit for what I think is the best, deepest and most sustained work on federal spending data quality that’s been done by anybody. And none of us would know how to make that expertise relevant to the people who can fix these problems without Sunlight’s helpful, friendly and frighteningly smart policy team.

Additional not-that-flattering photos available here.

Ashkan tweeted that the new iPhone will have a Fitbit-style accelerometer, enabling (presumably) Fitbit-style applications:

IPhone5S now has M7 (fitbit style) sensor so app makers can track user's activities — i.e number of steps taken http://t.co/wIzIU5FRCv

— ashkan soltani (@ashk4n) September 10, 2013

Tell me if this is crazy:

* Software is a more competitive market than hardware.
* Standardizing accelerometer hardware (assuming Android device makers hop on board, too) will gut the market for devices like Nike Fuel, Fitbit, etc.
* There’ll be much stronger demand from consumers for data portability across services/interfaces/apps.
* All of this means thinner profit margins for fitness tracking firms.
* A smaller pie means less hype (this is the one I’m least sure about)

Maybe this isn’t bad news — it depends on your perspective and hopes for QS. More people will be using these pedometers, after all. It’s just that it’ll be clearer that they’re pedometers.

Eric asked me what I think of the Tessel! Well, sort of. Anyway I find myself delighted to have semi-informed thoughts about hobbyist microcontroller-y solutions. It’s a pleasant byproduct of all the time I’ve spent on silly electronics projects over the last decade, and makes me feel better about my own perpetually-dawning software senescence.

But so: the Tessel. Will it succeed? Is it worthwhile? You can read about it here but the important details are that it’s got wifi and a bunch of GPIOs and its development environment is built around Javascript — so much so that it can allegedly run many many node.js packages!

That’s all potentially interesting, but its odds of success can’t be understood outside of the environment it enters. So let’s talk about the two gorillas in the hobbyist space: Arduino and Raspberry Pi.

Raspberry Pi is a really cheap Linux computer with 256 MB of RAM. Like, $25 cheap. No onboard wifi — it’ll cost you another $10 to add ethernet (and double the RAM), or about the same for a USB wifi adapter. But it’s a pretty capable little system! There are some GPIOs, but not that many, and they’re not that robust, and there’s only one hardware PWM output, which is annoying if you know what that means. It’s also not open source. Still, it’s a genuine Linux system, which makes it able to harness an immensely powerful library of software. And its makers seem to have a sweetheart deal with Broadcom that enables their price point.

Arduino is a friendly microcontroller environment, and I should probably explain what that means. A microcontroller (uC) is a little computer — so little that it suffers really serious limitations. For instance, it’ll usually have less than 1MB of memory, and it’ll run thousands of times slower than your laptop CPU, and it’ll only be able to manipulate integers and have no video output or keyboard input. Pretty sad! On the other hand, it only costs a couple of bucks. And this list of capabilities isn’t too dissimilar to, say, the videogame systems you had growing up (if you’re as venerable as me, anyway).

The cheapness of uCs mean they can be singleminded. Your computer is doing a ton of things all the time. Its most fundamental pieces of software decide how to split up processor time between those things, like a library of fantastically complicated clockwork systems that need to be cranked forward, one at a time, by one very spritely curator. The curator has pretty good instincts about how to manage her charges, but sometimes she remembers it’s time to rebuild your search index or sync your system clock or check for Chrome updates or whatever, which means everything else might not get her attention right when you expected it would.

This is mostly fine, but it doesn’t work very well when you need extremely precise timing. Everything is so fast that it’s mostly still pretty precise (and you can pursue some ridiculous hacks to make it more precise still). But when you’re dealing with the real world, or finicky electrical systems, the need for very precise timing comes up more often than you’d think.

Microcontrollers are pretty good for this kind of thing. They can just sit there running one program because they’re so cheap. The curator’s attention is undivided; her behavior is predictable.

Arduino isn’t actually a chip, it’s a development and deployment environment wrapped around a particular family of chips made by Atmel. It makes it a hell of a lot easier to write code for those chips. Even that comes at a cost. My dumb Christmas lights require communication in 10 microsecond pulses (rather pokey as these things go). But if you look at the “Timing” section of this post you’ll see that to fake a 10-ish microsecond delay on Arduino you need to tell it to delayMicroseconds(3) or delayMicroseconds(4) depending on the Atmel chip. The Arduino environment introduces overhead — it’s a bit finicky. Still! The Arduino is much better about this stuff than the Raspberry Pi.

(In the real world, sophisticated processors deal with applications that require precise timing requirements by speaking to microcontroller-like chips that handle their responsibilities precisely, but which can also speak to the main processor in a relatively timing-insensitive manner. Your sound card — or, more likely, the part of your processor that used to be a distinct component called a sound card — is a good example. Some of my current projects use a Raspberry Pi to speak to an Arduino to speak to an LED controller chip, which is less silly than it probably sounds.)

So! Enough preamble. Where does the Tessel lie on this continuum?

I think it’s almost certainly going to be more Pi-like than Arduino-like. The fact that it’s Javascript-focused is notable (though it’s also worth noting that the BeagleBone — a Raspberry Pi precursor — also pushes a JS-first approach). It’s a testament to the shockingly widespread impact of the V8 engine on our technical culture — one of the many genuinely unselfish things that Google has given to the world.  We’ll have to remember this when they’re forcibly uploading our brains a few years from now.

Could the Tessel run a Javascript environment in some incredibly constrained manner that allows for precise, uC-like timing? Eh. Maybe? It seems pretty unlikely to me, particularly given all the general-purpose node.js packages that it claims to support. If you want a high level of precision, you need to know about and account for everything the system is doing. That means you can’t work at a particularly high level of abstraction, as the Arduino example above hopefully demonstrates. You probably need to write assembly or C, not an interpreted language like JS that passes through a black box of voodoo optimizations. This is particularly true for an environment like node.js that emphasizes asynchronous approaches with somewhat unpredictable timing (says the guy who’s never written any node.js code). And even if that sort of thing were easy to do in node, all those package authors would not have done it, since the Tessel didn’t exist when they did their work.

It seems most likely that the Tessel will be a stripped down *nix environment (the Tessel’s processor is a cheaper installment from the same ARM family that powers the BeagleBone). But it’ll only have 32 MB of RAM! You can run a tiny OS in that — I’ve done it plenty. But it’s going to suck in various ways. And I’m not really convinced it’s going to be cheaper than the much more capable $25 Raspberry Pi.

The Arduino, meanwhile, is waiting at your neighborhood Radioshack for $30, and Chinese clones can be easily had for $7 or less.

The Tessel, I think, aims to land between Arduino and the Pi. And that’s not crazy. Making this stuff more accessible is really worthwhile! Building a lovely little network-capable platform with handy modular sensors and helper libraries is worthwhile! Getting an Arduino online is terrible and expensive, and the Raspberry Pi’s universe of shields is still a bit underwhelming. There is good work yet to be done.

But both of those projects are hugely popular. You shouldn’t underestimate how important those network effects are. I spent a ton of time on BeagleBone, then gave up. Other than price, it is a much better platform than Raspberry Pi: it’s fully open, has more GPIOs and a better processor. But people got so excited about the Pi, thanks in large part to the enormous publicity it attracted. Seemingly overnight I could pick from a million awesome tutorials penned by brilliant people eager to figure stuff out for me. Same goes for Arduino.

Could Tessel carve out a new niche? Sure. I think it’d have to offer something new, though, and I’m not sure it does. The Tessel looks nice, but it’s probably not going to be cheap enough or offer enough additional utility over established platforms to become a huge success. You can run node.js on a Pi, after all.

Calvino books are Calvino books. They’re rewarding if approached in the right mindset. What distinguishes them is simply their framing, and this wasn’t my favorite. Drained of verbs, these descriptions of cities reflect thinking that is often profound, though also sometimes banal (yes, suburbs often seem alike). There’s a few too many setups involving superficial duality and an ensuing revelation of redemptive humanist imperfection.

So: pretty good. Cosmicomics and Mr. Palomar remain my favorites, though.