Planet Bike Plays Nice With its Customers

Back in issue four of Make: magazine, Mister Jalopy published his initial "Maker's Bill of Rights," at the end of a wonderful article about being able to open, fix, explore, upgrade, and just in general tinker with the objects we buy. I wholeheartedly agree with the article, a mix of frustration (at being unable to order a simple replacement part) and a dreamy-eyed description of precisely how manufacturers could design and support their products. The article is full of quotable snippets, but I think the title is as good a motto as any: "If You Can't Open It, You Don't Own It."

Planet Bike is a bicycle accessory company, and an awesome one at that. Their products are well-made, and they "believe in the positive power of the bicycle," to the point of donating 25% of their profits to grassroots bicycle advocacy groups. Their packaging comes with their own version of the "three R's;"

• Ride (your bike)
• Rebuild (your stuff)
• Recycle (this packaging)

The second bullet caught my eye, and there was a URL printed underneath, so I visited it. Why don't you go ahead and do that now? That's right, Planet Bike has a catalog of all their small parts, and they'll even ship them for free to encourage people to fix their stuff, instead of replacing it. Bravo Planet Bike!

I want to re-emphasize how awesome that is. Some companies are often accused of making parts hard to replace, so that their customers have to buy the entire product again when it breaks. Not so, Planet Bike! They want you to make your stuff last longer. They want you to fix their product instead of buying a new (profit-generating) one. They want it so bad that they will pay the cost of shipping the parts you need!

The Maker's Bill of Rights is a great idea, and has its place. The problem with a bill of rights, however, is that nobody actually thinks of it as so. It's less glamorous to call it what it really will be until there's a large shift in consumer mentality; the Maker's Wishlist. I would propose a Maker's Award of Recognition, to be presented to companies actively working with their customers, as opposed to against them.

I also nominate Planet Bike for one.

How Python's .pyc Files can Cause Trouble

Just a quick story on this one. I was running into a problem with MoinMoin, and found that there was a quick and easy workaround (a two-line patch). After thinking it through, I went ahead and applied it to the server that was hosting the wiki of interest. Yes, I was applying a patch to a running, production server without testing it. Depending on your point of view, I'm either ballsy or stupid (or I looked at possible outcomes, realized that I couldn't cause any permanent damage, and that undoing the patch was no trouble, but that's the boring answer). Save the .py file and go back to my browser to try out the action that was failing before the patch.

And it still failed, in the same way. That wasn't right, in fact, the program state that led to the failure couldn't possibly be reached after the patch. I looked more closely at the relevant files, and found the problem. Background info: Python compiles each .py file into a .pyc bytecode file, and as a start-up time optimization, will execute that .pyc file if it is newer than the relevant .py file. In this case, it shouldn't be an issue, as I had just changed the .py file, and Python should re-compile the .pyc.

Actually, Python was doing what it should, it would look at request.pyc, and then request.py, and notice that request.pyc was younger. The modified time for request.py hadn't changed at all, actually. It turns out that request.py was a symlink that pointed to the real request.py (which is the one I modified, and did have a proper modified time), and the symlink hadn't been modified, so Python didn't think the actual code had either.

I deleted request.pyc and it all worked fine. This is why I insist on knowing how my tools work; knowing how and why Python creates the .pyc files, and how symlinks work, allowed me to get this patch running. Nothing groundbreaking here, earth was not shattered, but when so many people seem content to have the magic hidden from them, I thought I'd share my latest anecdotal evidence against that and for knowing how things work.

Canada's Internet: It's like... a highway. With trucks.

Ted Stevens, some time ago, became internet famous for letting us all know that the internet is "not a big truck. It's a series of tubes!" In Canada, the Globe and Mail would seem to disagree:

"[Traffic shaping through protocol-based throttling] is similar to allocating certain lanes on a highway to slow moving trucks to ease the flow of traffic in other lanes."

I'm glad we've got that cleared up.

On a more serious note, this is about a CRTC ruling that was just released, favouring Bell over CAIP. There are many other problems with that ruling and the tone it sets, but I don't think I have the energy, time, and will to go through that right now. Those interested in actually reading the CRTC decision will find it here.

UI: Computers-Based Agents,

I read a paper titled The Anti-Mac Interface a while back, and it stuck with me for a number of reasons. I strongly recommend reading it now, if you are at all interested in user interface design, especially user interfaces designed for people who know what they are doing. I'll warn you up front, I'm no fan of how Apple does their UI design these days (I'm displeased with many UIs now, seeing as they seem to insist on getting in my way, claiming that they want to help me), so the paper's title caught my eye. The gist of it is that the authors decided to systematically violate Apple's UI design guidelines to see what kind of UI they would end up with, and it turns out they got something that worked great for people already comfortable with computers.

This makes great sense in retrospect, if you ignore all the guidelines that ask you to treat your user as a total buffoon, the UI gets out of the way and lets the user actually get work done. One of the reasons I like to give for using Linux (and mostly command line programs) is that I don't have to fight it. I've used OSX and Vista briefly, and XP extensively, and I definitely feel like I am fighting an uphill battle against them all the time (the former two much more than the latter, but that may be a matter of experience).

One paradigm that caught my mind in the paper was computer-based agents and the idea of "delegation instead of direct manipulation." I envision myself telling my computer 'go find all my photos from last summer, and get back to me when you've tracked them all down and ordered them' instead of having to go in and select date ranges manually, across a smattering of directories. The interesting part (for me) is the idea of an agent that goes away and takes care of things, instead of the UI assuming I need to see everything happen, lest I get confused by all the shiny lights. (Don't start thinking about semantic interpretation or whatever, I'm not interested in requiring that my computer speak English. A find command is semantic enough for this task)

A bit of background info; on computers we often have bottlenecks, parts of an algorithm (basically, a set of instructions or steps to accomplish a task) that limit how fast the whole thing can run. Often, these can be split into, say, CPU-bound (we have to wait for the calculations to happen), memory-bound (CPU stays idle while waiting for data from RAM), or disk-bound (waiting on data from the horribly slow hard drive). Today, I realized that in UIs, we have another bottleneck, completely independent of computer performance. An operation can be user-bound.

What this means is that the fastest a task can be accomplished is limited by the UI's user. This might mean reading an essay, where even dial-up users can download text faster than they can read it. Another example would be watching videos: no matter how fast you can transfer them, decompress them, and convert them into bits of colour and sound, the number of people who can functionally watch a video any faster than normal playing speed is extremely small. Both those tasks are user-bound, as are many tasks that require user input or decision-making.

For now, I'm going to ignore user-bound tasks. Tying the two brain-threads I've put out there together, how would the anti-mac UI handle tasks that take long enough that the user experiences noticeable lack of responsiveness? When we send agents away to do something, we may want to work on something else while we wait, but also know when our agent comes back, smiling and proud, shouting 'all done!' Computers do this all the time, using a process called interrupts, and it's exactly what I thought of first. As soon as your agent is done, it pops up in your face and lets you know of such.

No thank you, I don't want my computer to remind me of some annoying jerk, interrupting my train of thought to throw some completely unrelated conversational turd at me. So now I think I want a queue, and as soon as something is complete, I see it show up in the 'complete' queue. This would be very useable with a 'in progress' queue as well, and some way of categorizing tasks, so that I can see all the complete tasks that are related to each other. Oh yeah, now we're talking; a small display at the edge of my screen that I can glimpse at whenever I find a natural mental break in whatever I'm doing. Much better, and I don't have to worry about the mentally jarring context-switch until I want to. I also don't need to be checking a half-dozen programs and progress bars to see where they are at either!

That was my big relevation for today; user-bound tasks, and that I would like dispatchable agents who would line up all polite like once they are done, silently waiting on me to call upon them to tell me what they have for me. If I were artistic, you'd get a mock-up here, but I'm not so you won't. Unfortunately, this type of UI element requires a much more tight-knit computing environment than available to me right now, so I'm filing this away for when I have way too much time on my hands.

*** I should probably note that I'm no UI pro, nor have I researched this in depth, and I'm not even going to claim that I'm the first person to think this up. It's just what I came up with while eating supper tonight, and it appeared novel enough to me to be worth sharing. If somebody knows of work done in this direction, please do share.

Carleton Campus Card Security Problems

Oh boy, two security posts, back-to-back! First off, here's a copy of an e-mail I was sent from Carleton:

There has been a breach of Carleton University's Campus Card system.

The university immediately contacted the students affected, deactivated their accounts and re-issued new accounts.

The university continues to recommend that all students frequently change their Connect passwords to ensure sensitive information is protected.

Given that Campus Cards can provide access to some buildings if they are copied, the university is immediately increasing security at Frontenac and Lanark residences and the Nesbitt biology building.

Please note: It is not possible for anyone to enter residences rooms or suites. However, the university recommends students always remain vigilant and if you observe anything that causes you concern, please contact Campus Safety at 4444.

To change your Connect password visit the MyCarleton website. When selecting a new password, we recommend that you choose one that cannot be easily guessed. Never respond to email requests asking you to provide your password, even if the email appears to come from Carleton.

Finally, if you suspect that someone has attempted to gain unauthorized access to your computer, please call the CCS Service Desk immediately (Ext. 3700)

Sincerely,
University Communications
media@carleton.ca

Pretty slim on the details, so I fired off a quick web search, and pulled up this CBC article on the matter, which gives a bit more info and some cause for worry. A few important points to note are that Carleton stores way too much info on the Campus Cards, was told of this problem on August 29th, but didn't tell the students who weren't identified as attacked by "Kasper Holmberg" (obviously a pseudonym), and Carleton is being disgustingly slim on details (I assume because they hope for security through obscurity). Here we go, blow-by-blow, with another look at security problems that shouldn't be.

Data on the Card

First off, what exactly is stored on the cards? Apparently, it "contains data such as the student's identification number, computer and e-mail login name and password, and library card number," as a bare minimum. While I have wanted to for a while, I've not actually swiped my card through a reader that would allow me to read the data myself, so it's quite possible there's more to it. The big problem that jumps out at me is that it stores both a login name and a password! There is no reason, ever, anywhere, that anybody should store actual passwords, especially not on an easily lost/stolen device. (For the record, computers encrypt passwords using a one-way hash, so that even if the data is stolen, the password cannot be figured out easily)
Upon second glance, I would think the card does not store the computer account password, for the same reason as below, namely; there is no opportunity to write it to the card after the password is changed.

The Campus Card is used for identification, library loans, and physical access in many places throughout the school, but is also a sort of debit card, where you don't need a PIN. You can pay money to have it added to your card, and then have it swiped (ideally by a real live person who can check that it's the right person using it) to use that money for food, amongst other things. No, the actual balance is not stored on the card, as that would require a write to the strip after each purchase, and the debit is only done after the swipe. At least that part is done right, and I would hope that cloning cards without actually having a working original would be near impossible, but now I'm not sure. I would like to see someone check how much (and which) data can be wrong on a card and still allow a Campus Card payment. How about the same question, but applied to library loans, or building access?

Initial Carleton Reaction

Initially, Carleton quietly contacted the affected students, and told them to change their passwords, but apparently wouldn't say why. Those of us who weren't affected had no clue anything was amiss. Oh no, Carleton, we wouldn't want to let people know that there might be a problem, would we? I absolutely hate, hate, HATE the all-too-common belief that for some reason people shouldn't know how insecure the systems they are using or being included in are. If Carleton was trying to save face, it failed, and we were exposed to severe insecurities without knowing it. Carleton also, hopefully, will lose even more face now. ("Hopefully," you ask? Well, they may be able to spin this in their favour, so they may not lose face, and I do hope they get embarassed into not making a similar mistake in the future.)

Another common argument about not disclosing this type of problem is that it just weakens security. This is also wrong, and termed "security by obscurity." Basically, the attacker already knows it's a problem, and if one found it, others can and will, and at least one of those is going to be nefarious enough to abuse it and/or tell many other shady characters about the problem. All security by obscurity does is keep the victims and potential victims in the dark about the risk they run in using what they likely assume is a secure system.

Carleton's Later Reaction

Reportedly, after notifying Carleton about the problem and (I assume because of) not seeing any advisory to the general public, Holmberg contacted the victims he had snagged, but they were still not told what the real problem was. No later than 5:31PM today, CBC News broke the story online, and Carleton sent out the terse e-mail that starts off this post at 7:45PM. Even at that, the information delivered by Carleton to the students was extremely sparse. On the matter of Holmberg's disclosure, Carleton's spokesman is quoted as saying "This is a very odd way to draw attention to the security of a system."

I have heard nothing about Carleton doing anything to fix the problems, other than "increasing security" at the buildings affected. I assume this means they are posting more security staff for the moment, which makes fine sense, but I don't think there's much need nor room for more security, when students will already let strangers in if they work it right, and student cards can more easily (and cheaply) be revoked than security keys.

My Thoughts and Notes

It would seem that the attack consisted purely of dropping a keylogger into the print stations we have in some computer labs at school. These are computers hooked up to printers, where you swipe your card and then log in to release your print job. It is important to note that you do not log in to your user account, but instead a third party program that is already running on the system. This would allow a keylogger dropped onto the computer to record everybody's login, and disables the built-in protections against such attacks that Microsoft has included in Windows. The other obvious vector would be installing a hardware keylogger between the keyboard/card reader (it's one piece of hardware) and the print station itself.

I have not seen what is stored on my card, but here is what I hope I would find: A unique identifier (a combination of student number and library account number, which are not the same number, is fine), followed by a cryptographic signature so that, given a student's unique ID, an attacker would not be able to compute the rest of the data. That is all, and as much security you can realistically have on a card without puting a chip on it. Everything else should be stored server-side.

It would make so much more sense to me if print jobs are paid for from the student account that is logged in to print them, as opposed to needing to type passwords into a second computer. I don't see why it would be any harder than the current system either, it is how the DOE account printing works. I don't see much problem with using campus cards as access keys to buildings, as described earlier, but I would bet that those systems are being un-implemented anyway, as a knee-jerk reaction. The other problem I see so far is that a cloned card can be used to make purchases without any type of authentication. This is very easily fixed by implementing a PIN system, just like debit cards do.

As for Christopher Walter's statement that "This is a very odd way to draw attention to the security of a system." No, no it's not at all. A bit of history for Mr. Walters, from the annals of computer security. For a while, people would only send information about security problems to the company who's product was vulnerable. They hoped this would help the general populace, but in the end they just watched companies ignore the problems. To remedy this problem, some security researchers started posting full info about the vulnerabilities to shame the companies into patching them, as well as to inform the users of those vulnerable programs that they were at risk. Nowadays, most researchers inform a company first, and the fear of the problem going public without any visible response from the company makes them fix it fast, after which the vulnerability is revealed, allowing the researchers to take the credit they are due.

While Carleton may not have understood that was how things were happening, what Holmberg did was essentially standard practice. He informed them of the flaw, waited for them to fix it, and when they didn't, he informed the affected users. I will give Carleton the benefit of the doubt and assume that Holmberg didn't explain that this was how he planned to handle the issue, but I nonetheless would rather have heard from Carleton first about the issue, and what they plan to do to fix it.

Dear Thomson (formerly SpeedTouch): Get More Monkeys

The title for this post is an allusion to the thought-experiment of having an infinite number of monkeys, at an infinite number of typewriters, eventually type out the collected works of Shakespeare. It looks like SpeedTouch took to programming their modems in a similar fashion.

While setting up my modem (a SpeedTouch ST516) with my new Teksavvy account, I had to enter an account name and password for both the admin account for the modem, and my actual service provider. Nothing out of the ordinary here, and while I guess it would be nice to have an encrypted connection, it would be pretty fair to ask the user to make sure they are the only device on the network during this step. It's also pretty fair to assume that, if an attacker is on your home network and eavesdropping on your modem setup, you're pretty hosed anyway.

I don't like that style of thinking too much myself, as security should be set up with maximum paranoia. That's not the point here though. The logins and passwords were entered in a form, and afterwards sent as parameters in the next GET URL. In plaintext.

Let me illustrate that, in case the full weight hasn't hit. Assume I make an account called "admin" with the password "supersecret" and then use my ISP account "patrick" and password "moresecrets". My browser lets the modem know that's what I want by visiting the following link:
http://speedtouch.lan/cgi/wizard/?(1,4,0,1,0,0)&&user.tpl&user.ini&0.35&PPP_over_Ethernet_(PPPoE)&admin&supersecret&supersecret&patrick&moresecrets&moresecrets&&&&&&&&&&&&&
(not linkified because there's no reason for you to click through)

That should have made a few eyes bug out there. Passwords passed in the clear are extremely sketchy to begin with, but an aditional problem exists here, with browser history. By searching through the history of whichever browser was used to configure the modem, an attacker can pull up the passwords used. This is a small problem when the administrator was ie. counting on using the modem as a content filter, but is much worse when we factor in the human condition. Most people tend to use the same passwords all over the place, as it's hard to memorize a whole pile of passwords.

It's very reasonable, therefore, to assume that my password on another site would be "supersecret" or "moresecrets", or something similar. Those clues are available to anyone who can borrow my computer for just a moment, or have access to my browser history. I make the point about obly needing access to the browser history because some very smart people are working on accessing the browser history from areas they shouldn't really be able to.

On the whole, this isn't catastrophic. There isn't going to be widespread panic due to this problem, no huge worms or giant password heists. To exploit this vector, an attacker needs to be pretty deep in the first place, and for the most part will gain nothing new. On the other hand, security is a game of paranoia, and an area where the saying "a chain is only as strong as its weakest link" holds very true. This problem exposes a pretty weak link in a home user's "security chain", and could lead to a more advanced attack down the road.

The worst part of this is what it reveals about SpeedTouch and their products. This is a stupid, stupid, stupid way to attempt to even pretend you have any security, akin to asking everyone their name at a security check, but not following up to make sure they give a real name. I'm not bothering to look any deeper at the security available on this modem, but as far as I'm concerned, it offers precisely none. If the programmers can't be counted on to handle that password bit properly, they surely can't be expected to get system-wide security right.

If I were running a SpeedTouch machine in a security critical situation, I would for sure have tossed it now. I would strongly recommend avoiding their products in general, as even if some junior-now-left-the-company programmer made this gaffe, it should never, in no way, have made it through to production. To Thomson, the present owners of SpeedTouch, I would recommend hiring more monkeys, so that, hopefully, they can produce a higher-quality product in the same amount of time. Or you could just hire some programmers who know what they're doing.

The Incident

A week prior, while talking to a friend about biking in the city, I made what turned out to be a mildly prophetic remark. I said that it wasn't really a matter about if I get hit, but when. I almost only get around by bike nowadays, very rarely taking a bus or a ride in a car, so I cover a fair bit of distance on city streets, and hence have alot of interaction with cars. This demands a very alert mindset, so I assume that none of the drivers see me, and that some of them are trying to hurt me. It's not quite that bad, but thinking it is keeps me (mostly) safe. Even so, every 10-15 kilometers, on average, I have to pull a heavily defensive maneuver. Until last Friday, I could proudly say I hadn't been injured riding in traffic.

On Friday, riding downhill at about 9:15 PM (headlight and taillight on, thankyouverymuch), I was headed towards an intersection, where I had a green light. A car was waiting to turn left from the opposite side of the intersection, but was obviously waiting for me (and presumably the cyclist I had just passed) to clear through, so I bombed down the hill. To put a guess on my speed, bombing ususally gets me up in the 40-45 km/h range. As I was about to hit the intersection, a second car across the intersection pulled up beside the one that was waiting to turn left (as if to turn right or go through the intersection), and, just as I was entering the intersection at full tilt, whipped left to cross through the intersection right in front of me! The jerk didn't even bother signalling his horrible turn!

He braked. I braked harder. As I passed in front of him, my rear wheel lifted, and as everyone can probably predict, I flew over the handlebars. I cleared a fair bit of the intersection, with the bike following me, and landed mostly on my chin, with my right hand, arm, and shoulder taking some damage as well. As I got up to clear my bike from the intersection, the car that caused this with his numbskulled left turn drove off! Yeah, didn't even ask if I was okay, he just bolted!

So the driver who caused the problem ran away, leaving me to deal with whatever injuries or damage to the bike (none, other than a broken headlight, thankfully) that were incurred on their account. Later, the police tell me that because there was no physical contact (so not technically a collision), no actual crime was comitted, and the driver had no legal responsibility to stick around, even though he was acting like a less-than-stellar member of the community (apparently "asshole" is pretty strong language for a man in uniform to use). Wonderful. If there had been a collision, I obviously had the right-of-way (had even been given the right-of-way by the car waiting in the left-turning lane), and this asshole would also be guilty of fleeing the scene of a collision, which is not taken lightly.

I learnt a lesson that day. It cost me four stitches in the chin, a tetanus shot, and a Friday night sitting in the ER instead of at the birthday party I was on my way to. If I'm in the right, avoid a collision, and get hurt in the process, it's tough shit for me. If I don't avoid the collision, I still get hurt and risk damaging the bike, but the driver also has to deal with some damage (which is almost guaranteed to cost more than the damage to the type of bike I ride) and stick around to be charged. Doesn't that sound wonderful?

After the whole incident, I'm still riding in the city. I'm no less aggressive in my riding, and I'm not going to act any more afraid of cars than before. I'm not giving up on something I love because one asshole got lucky and managed to hurt me. Now, I just expect one notch higher of assholery out of the average driver on the street, and I'm going to work more on dodging instead of braking.

And if I'm going to get hurt next time, I'll just let the car hit me anyway.