Investigating Browersify: The Development Tool That Lets You Write Modular Code For Use In Browser

Screen Shot 2014-06-16 at 3.55.31 PM

A while back, the engineering team adopted AngularJS as the front end JavaScript framework of choice. Not every project we work on requires a framework like Angular, but when we need one — it’s where we go. This post, however isn’t about Angular itself — or why we chose it — it’s about how we manage the multitude of files associated with using such a framework. Every FED (front end developer) knows that simply using a separate script tag to include all files does not scale very well. Most take to simple concatenation, allowing them to use one js file for their app code. This also works, but can get out of hand and also forces you to either pollute the window namespace or create your own namespace in order to access various components outside of their respective files.

Our development team decided that a more modular approach was appropriate to solving this problem, so we turned to Browserify. Browserify brings node.js style require statements to the browser. We can write code that looks like this:

// mainCtrl.js

   module.exports = [‘$scope’, function($scope){
      $scope.theThings = [ ‘thing1’, ‘thing2’, ‘thing3’ ];


// fooCtrl.js

   module.exports = [‘$scope’, function($scope){
      $ = ‘bar’;


// controllers.js

   var controllers = {
      MainCtrl: require( ‘./mainCtrl’),
      FooCtrl: require(‘./fooCtrl’)

   // a utility module to dynamically attach modules
   require( './moduleUtils' )
    .forModule( myApp.controllers' )
    .setType( 'controller' )
    .injectAll( controllers );

// finally in app.js

   angular.module(‘myApp’, [
      // …. and so on


Using a build system, we point Browserify to app.js and that’s it! Another benefit to using browserify is that many node modules are automatically compatible and can be used in the browser. At the end of the day, Browserify is the best tool for allowing us to handle code in different files and keeping it all modular.

Airmail: Major Security Vulnerability?


Internet security and cryptography have always been a huge interest of mine and are topics that are becoming increasingly more important for people to understand. To further my knowledge of the subject, I have recently been reading the absolutely brilliant Security Engineering by Ross Anderson, and have been particularly captivated by two particular attacks; man-in-the-middle attacks and the even more devastating phishing attack.

About a week ago, Andrew, a fellow engineer, approached me with an Android-based penetration suite which we decided to use to take a quick inventory of the security of our personal internet properties. While I personally have experience with elementary penetration testing (mostly through using the metasploit framework), I never thought I would be able to perform the more advanced man-in-the-middle-attack that has provoked my interest so thoroughly. To our surprise (and horror), we were able to perform this attack with a tap of a button. Shortly after initiating this attack, we discovered our own two email credentials appearing in plain on our devices. After performing a number of further tests (which I will expand on momentarily) we noticed a trend; it seemed like the Mac application, Airmail, was sending our credentials unencrypted over the network despite us both having SSL enabled within the client.

Before I go into more detail about how we tested this theory and how one could reproduce this, it might be appropriate for me to explain some basic concepts.

Man-in-the-middle Attacks

A man-in-the-middle attack is when a device (phone, computer, or router) spoofs your own personal device into thinking that it is the true party you are attempting to communicate with. The graphic below might help illustrate this concept:


In this example, Alice is attempting to communicate information with Bob (in the vulnerability we are reporting on, we were ‘Alice’ and the email server was ‘Bob’). In a man-in-the-middle attack, however, a third party (in this example, Mallory) intercepts both Alice and Bob’s internet traffic and tricks them into thinking they are talking directly to one another, but in reality, all traffic is going through Mallory who is able to view any unencrypted data.


A key point about a man-in-the-middle attack is that theoretically, only unencrypted information is at risk. Cryptographers have developed a number of extremely effective methods of encryption to prevent this problem; The most popular and widely used being SSL. When you visit a website and see the green “lock” button (assuming you are using Chrome), that indicates your traffic is being encrypted using the SSL protocol. Without going into too many details, SSL, when enabled on your email client, will communicate with the server using an encrypted channel. Even if someone intercepts this traffic, they would have to decrypt the information (an operation that requires a massive amount of time and computational power, or access to either user’s secret key) to be able to read the contents of any data sent between the two original parties. SSL additionally uses a third party to independently verify the integrity of both communicating parties. In essence, SSL is the main defense one can use to prevent any potential man-in-the-middle attacks from obtaining sensitive information.

Our Observations

The problem Andrew and I identified was that Airmail was sending our credentials without encryption, despite the fact that we selected the “SSL” option in the application’s settings and both email providers we used supported SSL. We are still not sure if this is a legitimate vulnerability or if there are other factors at play. In addition, we have notified developers at Airmail and are working with them to investigate this issue further. That being said, we wanted to walk through the steps we used to reproduce the problem in hopes that more knowledgeable members of the tech community will be able to verify or reject our conclusions.

To test this vulnerability, we first created a new Gmail and Yahoo mail account that we would use to test different mail clients and providers. We than loaded those accounts onto Apple’s “Mail” client, Airmail, and accessed each provider’s web client. We than initiated a man-in-the-middle-attack (using dSploit) on all traffic on our network, and sent an email using both Apple Mail and the web client. We were unable at that point to see the two accounts’ credentials. We than sent an email using Airmail (again with SSL enabled) and proceeded to intercept both accounts’ credentials. Not being satisfied with this test alone, we replicated the prior steps on additional networks. Time and time again, we were able to see credentials of accounts using Airmail, but no credentials of accounts using any other email client.

Until this issue comes to a conclusion (with us either being proven wrong, or an update being made to the software), we have discontinued all use of Airmail. In addition, we have encouraged our colleagues to take the following steps to protect themselves from any other potential attacks. Mainly, using a single password for numerous online services is a big mistake. We encourage everyone to use a password manager and generate completely random passwords for each site they use. While this does not prevent the attack we described in this post, it is a essential habit to practice. Additionally, we recommend using software such as HTTPS Everywhere to force websites to use SSL encryption if available.

As we move forward with investigating this issue, we will keep everyone up to date. As stated, we hope more knowledgable parties will reproduce our tests and help us move towards a conclusion.

Please feel free to reach out to if you have any questions or information on this subject – or just leave it in the comments below.

Introducing Gennifer: The Latest In Data Generation


Here at ISL, we eat, sleep and breathe social. As you may or may not know, our Grandstand platform specializes in taking social interactions and doing  things as simple as data visualization to more complex things such as serving beers to a thirsty bunch. We rely on data from “the world” to drive our social products. However, when it comes to developing these awesome projects things get a bit hairy. At any given time, there could be an absolute flood of data (which is great for stress testing) and at other times there could be no data coming in at all.

Screen Shot 2014-05-22 at 11.45.08 AM

Most of the time, engineers test incoming data by manually performing social interactions via test and/or personal social media profiles. This is not good enough and makes for an unreliable development process. Additionally, most Grandstand-based projects have clear front end/back end functionality splits. Most development can take place concurrently but eventually, whomever is working on the back end of the system needs to work with whomever is working on the front end — if only to sync up the data formats, which get transformed between the time it originates on your favorite social network and the time it reaches the client in the browser.

We require an easy, flexible way to control the flow of data through our system so that we can turn up the frequency to stress test, simulate malformed data to ensure proper error checking occurs and various other semi-magical things. Unit tests on the server certainly help with this, but even unit tests require data.

Screen Shot 2014-05-22 at 10.12.51 AM

Enter gennifer. Gennifer is a fake social data generator created by the engineering team here at ISL. She can, in truth, generate any type of data, but given the nature of our work further development will focus more on social data. You can tell gennifer about your event emitter or socket and she will send data over that channel automatically as it is generated. Gennifer is under active development and so API changes are likely.

At ISL, we rely heavily on the open source community to build beautiful experiences for our clients. We feel that it is only right that we contribute back to that same community in an effort to further foster innovation. Look out for more open source projects coming from our team in the future.

Let us know what you think about Gennifer and if you’d like to contribute.

The Power of “I Don’t Know”


I’d say in most of life, but particularly in development, sometimes the best answer to a question is “I Don’t Know.” I am a huge fan of the Freakonomics podcast series, and was recently listening to episode 167 “The Three Hardest Words in the English Language” where they talked about how saying “I Don’t Know” is so incredibly hard. They cited a study where 2/3 – 3/4 of children and roughly 1/4 of adults would answer unknowable questions (seriously, they just made stuff up). While listening to this, I realized this is one of the key things we try to avoid in development here at iStrategyLabs.

When working together to solve a problem, the development team strives to keep an open mind about all of the technologies available in our toolbox. When faced with a new problem, not saying “I Don’t Know” when we need to hinders the discovery of new, possibly more effective ways of doing things. Saying “I Don’t Know” means that you are open to exploring the problem space fully before deciding on a particular solution.


Similarly, when talking with clients during an initial meeting or a discovery session, we want to be  confident in our ability to say “I Don’t Know.”  It is at these times that I am always reminded of a cliché I heard during an Agile training session. When do you know the least amount of information about a project? That’d be the initial kickoff. So why would we define every technical decision at this point? Instead, and our ability to do this is predicated on our success in delivering, the best thing to do is to say “I Don’t Know” and to then explain the steps we will take to explore the problem space and define the best possible solutions.

To be clear, saying “I Don’t Know” is not an act of ignorance. In fact, it is often times the clearest indicator of a cogent understanding of the issue at hand and trust in a client. And if you find yourself saying “I Don’t Know” too often, take the time to examine why and either focus in on the problem spaces you’re tackling or take a deeper dive into the area you’re working in.

Meet Transit, The Latest In Commuter Technology


Lately, I have been obsessing over the Electric Imp, a small internet connected device that allows makers to do some pretty awesome things. Where it truly excels is pulling in live data from APIs.

With our office located in Dupont Circle, we have easy access to the Metro and Capital Bikeshare Stations.  Since our team is constantly on the go, I thought it would be helpful to manipulate this travel data in a fun way, easily digestible way.  Thus Transit was born.


The first step in building Transit was choosing the hardware. I decided to go with six LED matrices that provided a similar aesthetic to the real metro signs, one Arduino Mega to power the LEDs, and an Electric Imp to collect the desired data. Next I brainstormed how much information I would like to show. I decided to display the next four trains arriving at the Dupont Circle metro, how many Capital Bikeshare bikes were available at the Dupont station, and the current temperature for Washington, DC.


The final unit is mounted on the wall between our two elevators, making it easy for people to see the information they need before they head out of the office. The sign pulls in new data from each of the APIs every 30 seconds.

P.S. I must commend the WMATA’s API for this project. Everything from signing up to embedding their data was extremely well done and easy to use.