Category Archives: Technology

Visiting the Tech Model Railroad Club at MIT

Last night I experienced the privilege of visiting the Tech Model Railroad Club on MIT’s campus.  As an avid model railroader, computer science major, and great admirer of books like Hackers and Accidental Empires, I’ve heard of the TMRC for most of my life.  As a kid, my parents bought the 1986 edition of World Book, which underneath the entry “Model Railroads” included a picture of the TMRC layout, something I’ve never forgotten.

tmrc station

The first chapter of the book Hackers tells how some of the earliest computer science pioneers were involved in the TMRC .  A few of the notable members were Alan Kotok from DEC, Richard Greenblatt the coinventor of the MIT LISP machine (which is housed next door in the MIT Museum), John McCarthy who coined the term Artificial Intelligence and helped developed the LISP language, and Jack Dennis who was one of the founders of the Multics Project (the precursor to Unix).  These members along with others helped coin the term “Hacker”, and inscribed within the “Dictionary of the TMRC language” was the (now immortal to all computer scientists) phrase “Information wants to be free.”  These guys were budding computer scientists, brilliant minds, mischievous hackers, and they were serious about controlling model railroads.

The first chapter of Hackers describes the interplay between trains, their control, and what the TMRC meant to different students:

tmrc-overpass

“There were two factions of TMRC. Some members loved the idea of spending their time building and painting replicas of certain trains with historical and emotional value, or creating realistic scenery for the layout. This was the knife-and-paintbrush contingent, and it subscribed to railroad magazines and booked the club for trips on aging train lines. The other faction centered on the Signals and Power Subcommittee of the club, and it cared far more about what went on under the layout. This was The System, which worked something like a collaboration between Rube Goldberg and Wernher von Braun, and it was constantly being improved, revamped, perfected, and sometimes “gronked”—in club jargon, screwed up. S&P people were obsessed with the way The System worked, its increasing complexities, how any change you made would affect other parts, and how you could put those relationships between the parts to optimal use.”

tram system

For model railroaders, the TMRC is probably in the top 10 most famous layouts in the world along with names like John Allen’s Gorre & Daphetid, George Sellios’ Franklin & South Manchester, and famous club layouts like the San Diego Model Railroad Museum.  For techies, there is no other layout in the world of interest that’s anywhere in the TMRC’s league.

It shouldn’t surprise anyone that model railroading and computers have always been bedfellows – even today model railroading has led the way in developing standards around Digital Command Control, interfacing locomotives, signalling, and other controls to a computer, and the Java Model Railroad Interface has provided us the world’s first successful test case of the Gnu Public License (the GPL), the open source software license that Linux and much of open source code relies on!

card operating schemeWith all of this background, I probably undersold the importance of the whole thing to my college roommate and his wife who live in Boston.   When they asked me what I wanted to do during our afternoon together it struck them as a bit odd that I’d already emailed the club from Scotland, had the phone number, and was anxious to make sure we didn’t miss the window.

Walking into the layout room we were met by the wonderful MIT alumnus and club member John Purbrick. He proceeded to give us an hour long tour showing us the various control systems, buildings, car card operating scheme, points of interest on the layout, and description of future plans.

custom built throttleTMRC uses a home grown software system (written in Java with the fronted in Python, all running on Linux) to run the trains.  The layout is still using DC block control, and trains can be run via the main computer system, or engines can be assigned to one of the many hand-built walk around throttles.  All turnouts are computer controlled and electronically operated, none are hand thrown.  For each yard or town area, there’s a diagram of the track layout with numbers on the left and right hand sides.  By keying in the number 0 on the left, and the number 5 on the right for example, the turnouts are all automatically thrown to present a route between the two points.  It’s simple, elegant, and impressive for a home built system.  As Mr. Purbrick put it, “We use a home built system on this layout because here at MIT, we have some experience with software.” Trains are detected by the software using electrical resistance, so operators can see from the software whether a train is on a siding, train with engine, or no train at all.

The main level of the layout is mostly complete, but there are plans for additional levels, and the layout features several huge helixes.  All visible mainline track is Code 83, sidings are Code 70, and there is some Code 55, and all visible turnouts are hand built.  There’s also a tram system that runs on one part of the layout.  Rolling stock varies but includes locomotives from Atlas, Athearn, and Kato. The president of Kato has visited from Japan and brought with him a gift of a few locomotives and some passenger cars.

soda machine

The TMRC receives no financial support from MIT other than free use of the space.  Just like in the late 50s (and covered in the book Hackers), the TMRC is supported from the proceeds that are made by selling soda from a machine in the hallway, and they turn a tidy profit according to Purbrick. A hand scrawled note affixed to the machine explains where the profits go and encourages patrons to email soda suggestions to the club for inclusion on the menu.

These days there aren’t many members left, apparently.  Maybe a dozen or so, although anyone can join. There was only one other member there while we visited, and the club struggles to get enough people together for operating sessions. Apparently there are several other thriving clubs in the area, but I wondered if there wouldn’t be a population of students out there who might not know of the TMRC’s heritage, it’s incredibly complex computer control system, and its delightful layout?

playing tetris on a buildingAs we made our way out at the end of the tour, Mr. Purbrick told us that we couldn’t leave without seeing the Tetris building.  From the hallway looking through the windows onto the layout, there is a control box.  When activated, the iconic tetris music begins to play, and the windows of the skyscraper light up to represent tetris blocks, which descend.  You can play a game of tetris represented on the windows of a building modelled by the TMRC, all powered by custom software and hardware components.  The creator of Tetris himself has been by to see this particular implementation, and while it wasn’t quite finished, he is said to have given it his approval.

“It’s one of our better hacks,” said John Purbrick, and I couldn’t agree more.

HSBC Anti-Fraud Measures Vulnerable to Phishing Attacks

I’ve been an HSBC customer for roughly two years and have complained about these practices probably more than a dozen times without any real acknowledgement or change.

HSBC, like most banks in the UK, provides every customer a 2 factor security token to make sure that logging in requires something you know (your password) and something you have (your token’s time-limited code). So far so good. They even have a signing procedure for sending money (personal accounts only, strangely) that requires you to hash the transaction amount with your token, and put in the corresponding code as part of the transaction. A nice touch.

A Horrible Anti-Fraud Algorithm

Where HSBC has a glaring security hole is their fraud detection and prevention. As near as I can tell, the HSBC fraud algorithm is essentially “IF online transaction AND/OR foreign origination AND/OR amount is greater than [some nominal amount] THEN fraud”.

There’s no history taken into account, and they routinely ignore travel advisories called in ahead of time. So for example, if you signup to a monthly recurring charge for a software service outside of the UK (many of them) it doesn’t matter that the charge has occurred every month for a year, they’ll still pop an alert. This is particularly problematic for subscriptions billed annually, as it seems that their fraud team can perform a manual override on most things, but not on infrequent subscriptions.

An Outsourced Anti-Fraud Team

Foreign can often mean “somewhat far away” too. There’s no concept of accepting a card present, pin verified transaction as maybe worth the benefit of the doubt either, so I’ve had my card declined for sandwich shop purchases in towns less than fifty miles away from my home address.

A Dangerous Fraud Verification Process

But all of this could maybe be lived with, if not for the horrific fraud verification procedures employed by one of the largest banks in the world.

Here’s how it works:

  1. Their horrible fraud algorithm pops an alert. This can occur on a subscription charge, a pin verified card present charge, or a verified by visa online charge.
  2. You will receive a phone call from an unknown number (blocked).
  3. An Indian call centre rep will tell you they’re calling from HSBC and they’ll need to verify some important information before they speak to you. So far, this has been my birth date or post code (enough to get your full address in the UK). If you refuse to speak to them, your card is blocked. If you call them back, it will take roughly 25 minutes on hold being transferred around to clear the block.
  4. If you don’t answer the phone, they will leave a voicemail. Again, an Indian call centre rep will preface the voicemail with an urgent request for contact, then they will play a recorded message. Often there will be a problem here, and they’ll have to call back to get the recording playing right.

It’s important to note that the phone connection quality is invariably terrible. This means you can’t understand the person, and the recording is garbled as well.  I also don’t care if the representative is a native English speaker or not.  I do care that the cut-rate policies of HSBC mean they have chosen an outsourcing provider who can’t seem to get decent phone service, thus making the entire thing more vulnerable to phishing (it’s easy and cheap to sound just like HSBC or even worse, do a better job by having a nice fluent British accent  via a clear connection).

An Active Phishing Threat?

For the past two years I’ve been uncomfortable with this process. It leaves you open to phishing attacks, particularly spear fishing. It relies on data that could be publicly obtained fairly easily (birthdate and post code) and even if you can’t get this data, you can easily phish it by impersonating a representative then using that information to escalate privilege elsewhere.

A better solution would be to mimic the procedures in place at other banks. Chase for example has an app that will securely message you the details of a questionable transaction which you can approve or deny in a few seconds. They’ll also SMS you the details of the charge, which you can respond to. Lastly, if you don’t have a smart phone or can’t receive text messages, they’ll call you and use a challenge response procedure to verify yourself, or leave you a voicemail instructing you to call the number on the back of the card. The entire process is safe, easy, and quick not matter what mechanism you use (I use all three depending on the situation).

It appears that these weaknesses in HSBC’s procedures have now caught the attention of others. A couple of days ago I was called by someone who mumbled around that they were from HSBC, and asked me for information. I declined, like normal. I called the bank back like normal. Except this time, nobody from HSBC had called and no suspicious charges were flagged. Apparently someone had attempted to phish me! I wonder how long it will take HSBC to address this now that their customers are being actively targeted?

Lets review how we got here:

  1. A poor anti-fraud algorithm means false positives are common.
  2. A lot of alerts means you need a large customer service staff.
  3. You outsource this, you don’t automate it, and put in place procedures that are fraught with security problems.
  4. Your frustrated and desensitised customers lose respect for the process.
  5. Phishers take note, and begin to capitalise.

HSBC Customers, Be Careful!

Be careful out there! Never give any personal information to anyone calling you, no matter who they claim to be and no matter how annoying the procedure is.

We Need Viable Search Engine Competition, Now

It’s become clear to me that we desperately need a viable competitor (or two) in the search engine space. A somewhat related thought I’ve been having is the (probably inaccurate) sensation that bringing out a viable competitor to Google may not be nearly as hard as it has appeared for the last decade.

We need competitors now. Most websites see more than 80% of their search engine traffic arriving from just Google, and this is not a good long term recipe for a vibrant internet.

Inherent Conflict of Interest
Google’s revenue model of placing paid ads next to organic search results operates under the (publicly accepted) belief that there’s a secure “Chinese wall” between the paid and organic functions. It was even more secure, some argued, because ultimately the short-term conflict between receiving revenue for rankings (paid) vs. displaying the best rankings (organic) was not a long-term conflict. Better organic results were always in Google’s interest, because these competitive results maintained their dominance and user’s trust. And so we believed. To be fair, I feel that Google does a somewhat decent job in this area, but I continue to feel that the user experience of Adwords exhibits various dark patterns (more about this here) and Google’s corporate inertia seems to be focused on a walled garden approach with G+ and Android. Lets just say that I’m no longer going to blindly trust Google in the face of a worrying conflict of interest that’s central to their most valuable product. Declining empires under siege are the ones you have to be careful of, after all.

Vulnerabile to Manipulation
Is there anything worse than “SEO”? The very idea of this industry, filled with people whose sole job is to attempt to manipulate Google is bad enough, but the fact that “black hat” SEO can produce material gains is genuinely worrying. Having had to clean up a mess created by a black hat (who insisted he wasn’t) and now in the middle of another mess of toxic back links that may or may not be generated by a competitor, the whole thing is just annoying, wasteful, and embarrassing for Google. I get that they’re trying to clean this up with Penguin and Panda and the various versions therein.

Arbitrary and Corrupt
When RapGenius violated Google’s SEO guidelines, they were only caught due to a public revelation on Hacker News, then immediately penalised by a human (to compensate for where their algorithm failed), then they were permitted to communicate directly with google to discuss ways out of this mess. Not it appears they’ve been fast-tracked back into the listings, albeit at somewhat of a disadvantage.

All aspects of this rub me the wrong way –

  1. Google is making arbitrary rules on how sites should behave, because they have a monopoly. If they didn’t have a monopoly, they might not be able to make these arbitrary rules, and others might not follow them.
  2. Google needs these rules, because Google’s rankings are apparently trivial to game. Build a ton of links and make sure you don’t over-optimise your link text. That’ll do it for most key phrases, apparently, as long as you’re not completely obvious. There’s a clear incentive for “Bad Guys” to win using“Bad Ways”, that penalises good sites just trying to get on with business. Does anyone actually believe that the ridiculously obvious, poorly written link farms that Google catches periodically are the only examples out there? Smarter people doing a better job are gaming google all the time, and it appears to be getting worse.
  3. Google feels the right to at any time, and with zero due process, transparency, or appeal, to manually penalise sites who successfully ignore their rules yet exhibit a high ranking. This is not transparent, fair, or reliable. It is scary for legitimate businesses, and this kind of instability should not be the norm, but it is.
  4. The only organisations or individuals who can actually engage with Google over a penalisation or problem in any meaningful way are Silicon Valley favourites or companies backed by influential VCs, or [insert some other not-avaible-to-the-public recourse here]. This is the definition of corruption.

We Need A Competitive Alternative
Competition could provide a healthy response to many of these items. I don’t think regulation is the answer, but it may become one if these trends continue and intensify. A different revenue model could remove the conflict of interest, a better or different algorithm could be less prone to manipulation, and a search engine that prided itself on a transparent and efficient arbitration process for disputes with regards to rankings could win users trust. Of course, Google could also work on these problems themselves, but it seems like they’re more or less happy with the current state of affairs.

Is PageRank really the indomitable tech of our generation? Nobody can do better algorithmically, or integrate some kind of crowd sourced feedback, or measure browsing time and habits, or simply hand tune some of the most competitive key phrases? I’m sure I’m oversimplifying, but I wonder if we haven’t all been hypnotised by the complexity, much of which is marketing hype, and have missed the enormous opportunity that exists right in front of our noses. Does the next search engine have to be as big, involved in as many things, employ as many people, and fight on the same footing to be accomplish the goal of providing a counterpoint to Google?

Time will tell.

Missing the Point on Electric Cars

2013 Tesla Model S

I feel like a lot of people miss the point on electric cars.  I see all kinds of debates about whether they actually get 100mpg or if this is some kind of synthetic and propped up metric designed to delude eco hipsters into thinking they’re more green then they really are.

Who cares?

The point of an electric car isn’t that it’s greener (although it may be, and is nice if it is) and it isn’t about range (most people don’t drive far enough regularly enough to really need to worry about range), it’s about the fact that the fuel can be generated through a variety of different mechanisms.

Do you like nuclear power? Or wind? Or solar? Or wave energy? Then electric is the car for you.  If you believe we need to invest in a range of different energy generation schemes in order to burn less oil, then electric is the car for you.

To me, the flexibility on fuel source is the entire point.

Here’s How to Salt Your Own Passwords and Prevent a LinkedIN Style Password Problem

With all of the publicity surrounding LinkedIN, League of Legends, and possibly others, I thought I’d take a moment to explain how I manage passwords.  Yes, I quickly changed my password on LinkedIN, but using this method will add you just a bit more security if and when a provider screws up.  Remember, not every security incident involves a massive “post to everyone’s wall and make the evening news” style announcement!

I started this method after a screwup at Reddit a long time ago, which back in the day was storing plaintext passwords, and leaked them.  It has worked extremely well over the last six or so years.  For those who are unfamiliar with salting – it’s a method to increase randomness of passwords, and prevent rainbow attacks against password databases.  Technical readers may point out some more particulars about that statement, but the general statement should hold true.

Websites and other authenticators are supposed to salt passwords, but they can forget.  You can salt your own passwords by providing a hard to remember base password, then add some random characters to the beginning, after a fixed position, or end of the password.  This will make deriving your password more difficult, and will prevent (quick) account theft by an attacker taking your email and password and trying it at well known sites.

  1. Choose a decent password.  I recommend that people choose a nursery rhyme, favorite quote, saying, bit of religious text, or any kind of phrasing and choose the first letter or second letter of each word from that phrase.  This usually gets them a reasonably strong, easy to remember base password.  Capitalize a few of the letters and add a number at the beginning or end.
  2. Develop a salting mechanism. For every website that needs a password, develop a salting mechanism.  Have two rules of thumb as to how you derive a few additional characters based on the site itself.  Try to choose something relatively non-volatile.  For example – use the first four letters of the company’s name as it appears on their logo.  Or the last three letters of their domain name.  Or something else that may not change very often.  Then add these letters to your passphrase above at the beginning, middle or end of the phrase.  Why two rules?  So if your first rule doesn’t work due to some password scheme restrictions, you can use the second.
  3. You’re done. You now have an easy to remember passphrase that’s unique to that site (your base password + your derived salt).  Best of all, your password looks fairly random and even if your password from another site was stolen, it wouldn’t be susceptible to rainbow attacks, etc.

A few benefits of this approach:

  • You don’t need to rely on a “last pass” type application or system that stores all your passwords on a computer which may be hard to access sometimes.
  • It’s easy!
  • It’s free!
  • It really works – I’ve never had a problem with this, even with some of those sites that have weird password rules.
  • You now have a unique password to every system you access.
  • You can change the base password every year if you’d like, for even better security, and to weed out those accounts you forget about / never use.

There are no silver bullets to any of this.  Yes, this can still be attacked, but it’s certainly better than the “same password everywhere” or the “secure password for sites I care about and insecure one everywhere else” method.

I highly recommend you turn on Gmail’s 2 Factor security setting on your email account as well.  Particularly now that they’ve released an “offline” authenticator token generator which doesn’t need network access to work.

Stay safe out there!

Quick Tip for Display Port Problems with a MacBook Pro

I connect my MacBook Pro to an external display via a DisplayPort -> HDMI connector.  After a couple of months of problem free operation, all of a sudden my MacBook wouldn’t recognize the external monitor.  It would flash blue (clearly recognising something was connected) then not display the image.

After a lof of searching around and ordering a replacement cable, here’s what solved it:  Power off (as in disconnect from the wall) the monitor, then unplug the cable, then plug the cable back in, then reconnect power to the monitor, then turn the monitor back on.

Everything else I tried including resetting the PRAM didn’t work.  Hope this helps someone.

Whisky Web Day One Recap

Today myself and one of my coworkers attended the WhiskyWeb conference here in Edinburgh, Scotland.  This conference is in its first year, organised by a very small team, and was setup and organised from the ashes of a failed conference in just three months.  Located in the lovely Hub Conference Center (a converted cathedral) on the Royal Mile just steps from the Edinburgh Castle, it’s in a great location for those who have never been to Scotland before.  Most of the hundred or so attendees I met seemed to be from other countries and were really enjoying the city.

The conference technically started last night with a Pub Crawl that started at the bottom of the Royal Mile and worked its way up a series of pubs.  This was pretty well attended and all the speakers were in the crowd so it was a nice way to get introduced prior to the event.

Today the two tracks of talks were help in adjacent halls.  The ending keynote speaker even had a helium remote controlled shark swimming the air above the audience’s heads.  I’ve included some pictures.

Img_0487Img_0484Img_0492

Josh Holmes (@joshholmes) on Failure 

The opening keynote focused on failure, how to learn from it, and why it’s a good thing.  Josh is an American living in Dublin and we got to swap stories about motorcycles and Guiness and life without a car the night before.  I even got drafted to taking pictures of him with his own camera.  A nice short, inspiring, and positive talk to kick things off that was probably pretty foreign for most of the UK attendees.

Some of his main points:

  • You will fail.  It’s unavoidable.
  • A famous quote by former IBM CEO who had an employee make a 600k (in 1950s dollars) mistake.  Instead of firing him, he responded that he “Just spent 600k training him”.
  • Talked about a personal failure on a technical choice: SOAP vs. Remoting
  • “Losers always lose” – don’t give up and become a loser!
  • When times get tough, that’s the time to press on
  • Failure is always an option, so respect that.
  • Fail fast is a good concept, but doesn’t give you leave to be stupid (referencing a recent Michael Church blog post)
  • How to integrate failure into your life in a positive way:
    • TDD – fail before writing your code
    • Business Development – fail before writing your app or starting your company by doing research on your concept or idea.

A good way to start things off.

Rowan Merewood (@rowan_m) –  Estimation: “How to Dig Your Own Grave”

Next up was a talk on estimation and some common pitfalls.

Some Classic Estimation Mistakes

  • Sales creating estimates
  • One guy creating estimates
  • Creating estimates from detailed task lists
    • you know it will change
    • gives misplaced confidence
    • encourages micro management
  • Estimating a day as 8 hours

Moving on he talked about some strategies to get around some of these areas.  First he talked about how hours are too granular and suggested using half days as an example – “from the start of the day could you finish by lunchtime?” which can bring more clarity.

As a project’s length scales out, scale up the increments to 1, 3, 5, 7 days.  Anything over this and you’re not estimating anymore.  In response to the tendency of Agile folks not wanting to estimate or developers thinking estimates are useles: fine, stop calling yourself an engineer!

The last bit of the talk was spent talking about some conceptual models used to communicate estimation processes and risks to clients which were pretty interesting:

  • Good, Cheap, Fast – choose two
  • Triangle with points of Scope, Cost, Time – as you vary them, you vary the area which is the quality of the project
  • the MoSCoW model
  • the Kano model
    • Basic features don’t deliver high customer satisfaction
    • As performance improves, customer satisfaction goes up in a linear scale
    • “Exciter Features” generate a bigger satisfaction the more of them are added

Sebastian Marek (@proofek) – Ten Commandments for a Software Engineer

It took something like 15 minutes to get the powerpoint working on this talk, so I was annoyed before the talk even started, but Sebastian pulled it out and gave a great talk on software engineering principles important to him.

  1. Don’t disrupt legacy systems – extract, blackbox, hide behind an interface.
  2. Don’t reinvent the wheel.
  3. Commit often and make sure your messages are informative.
  4. Document early when the problem and your mind is still fresh.
  5. Don’t fear Q/A – use automated, unit, and functional tests along with a CI server
  6. Design for simplicitly.
  7. Don’t kill maintainability.
  8. Don’t repeat yourself – use copy/paste detection and other tools.
  9. Speak up early and often.
  10. Recognise and retain your top talent.

Brian Suda (@briansuda) on Data Visualisation

This was a very interesting (although I’m not sure how practical) talk that was a bit out of the norm for a technical conference.  Brian lived in the UK for awhile and is currently living in Iceland, authored a book on data visualisation, and spends his time seeing how we can help visualise various data sources.  His very graphically intense presentation was a very refreshing look at some unusual or creative ways to get data in front of users in more practical and memorable ways.

A few points:

  • 3D Charts are not advisable (proportion, view obscure)
  • Pay attention to your “data to ink ratio” (tufte, 1983)
  • reduce visualisation as much as possible e.g. simpler is better, remove unnecessary clutter
  • 2 schools of thought (simple, tufte and nigel holms more complex)
  • He showed several examples of PHP generated SVG visualisations which were really interesting, these are located here: github.com/briansuda

John Mertic (@mertic) – Lessons Learned from Testing Legacy Code

John is a member of the SugarCRM project, and described coming on board a few years ago when Sugar had zero unit tests and zero functional tests.  They’ve spent quite a bit of time changing this, and he discussed some tools to assist on finding bad code.

  • phpcpd – copy/paste detection
  • phpmd  – code quality report
  • phpdcd – dead code detection

He also made great points on the following items:

  • Don’t be surprised when you see crap
  • Better to focus on functional tests first
  • Build a culture of testing
  • Use CI or else tests are useless

Whisky Web Day Two

Tomorrow is a Hackathon located on the exact opposite end of the Royal Mile.  I probably won’t attend but all in all for £50, this conference was a bargain.