Just How Easy is it to be Hacked?

Earlier this year, David Gilbertson published an excellent article on Hacker Noon with the eye-catching title “I’m harvesting credit card numbers and passwords from your site. Here’s how.” While the article is noted as a fictional endeavor, the approach that is detailed is certainly something that could have a negative impact on corporations around the world.

A Relatively Simple Approach

In the author’s pseudo-confession, he states “I’ve been stealing usernames, passwords and credit card numbers from your sites for the past few years.”

Gilbertson went on to detail how his code looked at form fields with standardized names (password, card number, CVC, etc.) and relied upon built-in events to execute the following tasks:

  • Digest data from all form fields (document.forms.forEach(…)) on the page.
  • Grabs document.cookie from the session.
  • Transforms the information into a random-looking string const payload = btoa(JSON.stringify(sensitiveUserData)).
  • Sends the data to a domain he manages, between the hours of 7 pm and 7 am (local browser time).

How Does His code Work?

At the heart of the attack, is the uber-popular implementation of npm. For those who are not aware, npm is a JavaScript package manager and at the core of products like grunt, bower, gulp, browserify, and cordova (just to name a few).

“Lucky for me, we live in an age where people install npm packages like they’re popping pain killers.” – David Gilbertson

In David’s (fictional) approach, he decided to leverage npm as his distribution method. Creating a library that allows console log messages to be displayed in color, he figured other libraries would welcome his functionality. After all, seeing colors on the console is pretty cool, right?

Next, he used several accounts to submit pull requests (PRs) to various front-end packages and dependencies. The PRs focused on making a much-needed fix, then added his logging functionality as well. Developers going the extra mile is always a welcome thing, especially in open-source projects.

The PRs would be approved and the fix would be deployed, as well as his way-cool colorized logging package. The only issue is that his way cool package also included the functionality to perform the tasks noted above.

Once his PRs were approved, he started to see ~120,000 downloads a month – with none of the customers expecting any issues. As a result, he began receiving torrents of usernames, passwords, and credit-card information. Some of those arrived from Amazon Alexa-top-1000 sites as well.

Are We Doomed?

While Gilbertson states his endeavor was purely fictional, the simple nature and potential for wide-spread deployment is very concerning. The biggest challenge is getting development teams away from simply accepting packages that are available via services like npm.

In a perfect world, every package (and all associated dependencies) would be analyzed, reviewed, and scanned at the version level, prior to being implemented. In the real world, this feat is daunting at best and unlikely to be utilized. As a second layer, the QA effort (in a perfect world) would be mindful of monitoring network activity when updates are being validated. However, the real world typically yields a laser-focused eye on the item being addressed with the fixes/enhancements, often leaving broader topics (like network activity) unaddressed.

Agile teams utilizing Scrum typically allocate 20% of a given Sprint cycle for technical debt. Perhaps, some of this time can be spent gaining an understanding of the packages and dependencies that are being introduced from the prior Sprint – if not the current Sprint.

A RESTful Interface With a Wide-Open Contract

A RESTful Interface With a Wide-Open Contract

I remember first hearing about RESTful API design at a Gartner Application Architecture, Design & Integration Summit back in 2008. I recall thinking how practical the idea was, leveraging GET, POST, PUT, PATCH, and DELETE to communicate with an API server.

It wasn’t until a couple years later that I started seeing RESTful APIs at client engagements. All of them seemed to follow the standard RESTful API design, making it easy to build client applications against the back-end API services built upon REST.

Well…all except for one.

A Different Design
As part of an application conversion project, I was told that there was very little work to do on the API side of the solution. My focus was to replace a legacy client framework with something more responsive.

When I started looking at the legacy code, I noticed that one single endpoint continued to be utilized over and over again. Basically, there was a single REST end-point, which was configured as a POST and required the client to provide a query that will be accepted by the end-point, executed and then returned with a standardized, but very generic response.

Here is an example:
var data = {
where: [
[‘dateDeleted:date’, ‘is’, null]
$http.post(‘//api.myapp.com’, data);

In the simple example above, the API is being asked to locate CustomerVO objects, which do not have a value for the dateDeleted attribute. The results would be ordered by the name attribute in ascending order.

The response would then be structured as follows:
“data”: [{
“id”: 1001001,
“entityType”: “CustomerVO”,
“dateDeleted”: null,
“name”: “ABC Company”
}, {
“id”: 5003003,
“entityType”: “CustomerVO”,
“dateDeleted”: null,
“name”: “Beta Company”
}, {
“id”: 3002002,
“entityType”: “CustomerVO”,
“dateDeleted”: null,
“name”: “Zeta Company”

Only three records were located, and they were sorted by the name field.

This approach reminded me of a Seinfeld episode where (Cosmo) Kramer’s telephone started ringing as a result of Moviefone customers seeking show times in their area. Evidently, the number of Moviefone was very close to Kramer’s telephone number. So, instead of letting people down, he attempted to ask the caller to use their touchtone phone to type in the first three characters of the movie they wish to see. Unable to translate the touch-tone sounds into a title via a couple of guesses, Kramer finally announced in a robotic voice, “why don’t you just tell me the movie you selected?”

You can watch the clip here.

To me, instead of having a standardized manner to obtain a list of items for a given resource, the RESTful API is acting like Kramer almost to say, “why don’t you just tell me what data you want me to return.”

Brilliance or Insanity?
What I never really found out is if this design was brilliant or a less than ideal approach to meet the needs of the customer’s API.

On one hand, it was kind of neat to be able to place the control in the hands of client – empowering them to obtain whatever data was required. With this open access to the back-end data store, client-side developers do not have to wait for the back-end developer to release new end-points which provide access to the much-needed data.

However, the other hand is heavily weighted down with challenges with this approach.

For starters, there seem to be some significant security vulnerabilities with the approach – especially in cases where sensitive data could be exposed. A good rule of thumb is to not expect the client to maintain the same security levels – even if the client is internally facing. After all, some simple analysis of the network connections in order to determine the parameters of the POST request being used. From there, common tooling (such as Postman), could help the curious customer gain access to additional data.

With everything flowing through a single end-point, the potential for scalability issues also exists. As the POST-based requests for data increase in size, the response time is likely to also increase – yielding performance concerns. Compounding the issue would be the increases associated with additional clients of either the same application or a related application – leveraging the wide-open contract-free API.

Finally, nature of the response differing based upon the request seems like it would be a concern. Along the same lines, the support team may find it difficult – if not impossible – to make changes to the API without breaking every client utilizing the service. Of course, a new version of the API could be released, but at that point maybe it would make sense to convert to a more traditional RESTful API.

When I first encountered this API, the design caught my attention. In my mind, I wondered if this was a similar scenario to when everyone believed the earth was flat. That, all along, we the RESTful API developers were using an approach that was mythical, at best.
After giving this idea some additional thought, I believe that the challenges I noted (I am sure there are others) far outweigh the way-cool benefits of being able to “just tell the API what data you want it to return.” Still, this article gave me the opportunity to link back to a comical segment of one of my favorite situation comedies back in the 1990s.

Have a really great day!

Being Smart About Your UI/UX Design

Being Smart About Your UI/UX Design

The electronic age has certainly made life simpler.

Even before we found the need to be connected, electronic devices have become a supplement to our daily lives. The simple word processor and spreadsheet on the way-overpriced home computers helped make communication easier to read and reduced errors with pencil and paper computations.

With our connected world, just about everything we used to do can be completed (in one way or another) using an electronic device. Earlier this week, our family searched the web-sites of a couple grocery stores (and Amazon, of course) to see who had a particular type of icing that was going to be used on a cookie cake. Performing the search from home saved us the time and money (gasoline mostly) of driving around to reach our goal. With a newborn baby in the house, both time and money savings are always appreciated.

The success of being able to provide a need or service electronically requires some type of user-interface. In modern Information Technology (IT) applications, this is often referred to as user interface (UI) or user experience (UX) design. While it might be hard to believe for some, the UI/UX design is equally as important as the actual need being met. Some argue the UI/UX design might even be more important.

Below are three scenarios I have encountered of cases where the UI/UX design probably wasn’t the highest priority in the overall goal of meeting the application.

The Original Links – Golf Game

Growing up a fan of playing electronic games, I was super excited when the idea of PC-based games started to gain momentum. I had invested in a pretty nice computer that I was using for school and could not wait to allocate some of my entertainment budget toward playing games. At this point of my life, I was still enjoying a round of golf – both for the time outside and the challenge of doing my best at the game. So being able to golf virtually (especially during the winter months in the midwest) was something I was looking forward to evaluating.

The original Links game series was called “Links: The Challenge of Golf” (you can play it using your browser here) and the game was incredible (for the time). Since this was before computers had dedicated video cards, the CPU was used to handle every aspect of the game. So, it took several seconds for those picturesque golf scenes to render on computers back in those days. Players didn’t really care about the lag, since this was awesome … and compared to nothing else available at the time.

However, one thing that always bothered me was UI decisions within the game. When you bought the game, it came with only one course: Torrey Pines – South. Each time you started a new round, the game would always prompt you to select a course, as shown in the screenshot below:

When this screen arrived, it was common to jokingly ask, “which course do you want to play? Torrey Pines … or err … Torrey Pines.”

What I never understood is why the development team wouldn’t put in a feature to check to see if any other courses existed, before making the user select from a single select list. Especially since the game only shipped with one course and other courses were provided at a later date … for an additional cost.

I have seen this same type of logic years later, where a dynamically generated pick-list has only one option and an option is required to continue. If the field is required and there is only one option, why not go ahead and preselect that option?  The savings the development team would save on making this default selection not only saves the end-user time but also provides a more positive UI/UX experience.

When Using Grids – Mock Up Using Grids

A great deal of projects are using web frameworks (like Bootstrap) to supplement the design of a web application that can provide a responsive application across multiple end-user devices. A core aspect of the responsiveness is the CSS Grid Layout technique, which divides the <div> into as many as 12 equally spaced columns. Within each <div> another set of 12 can be added (and so on) with a goal to meet the needs of a majority of user interfaces.

Below, is a simple example of a basic grid row.

Grid systems have been a part of nearly every web-based client interface I have worked on since 2013.

The one challenge I have seen is with the UI/UX team not recognizing our decision to use a CSS Grid Layout. Instead, the UI/UX team provides 2D screen mockups using their preferred graphic design tool. For the most part, the elements depicted in the 2D screen sample can be rendered into the grid system without any issues. However, there are times when quirky CSS is required to meet the design – which can be a challenge to support across multiple screen resolutions or devices.

Most of the time, accommodations can be made to update screen designs to represent reality. However, it would be nice if the UI/UX team had a clear understanding of CSS Grid Layouts and it would be even nicer if their tooling allowed them to mock up the screens using the same frameworks that were ultimately utilized by developers. Otherwise, the disconnect will often require re-work costing the project team unexpected expenditures and potential timing delays in meeting their goal.

Actually Quitting Phone Apps

Mobile devices have certainly seen their share of great and not-so-great UI/UX experiences. I believe a good portion of the bad UI/UX designs are due to the fact that the work was completed by an individual without much experience in front-end design. This could probably be traced back (in most cases) to the boom of mobile applications and a flooded market of individuals attempting to cash in on the wave.

However, I have seen a couple applications that have been developed by major corporations which lack one major feature: the ability to easily quit the application. Two applications that come to mind for me are the UnitedHealthcare (UHC) Motion application and the iHeartRadio application.

I initially downloaded the iHeartRadio application so that I could continue listening to an over-the-air program while I worked on the lawn after my drive home. What I noticed at the time was that there was no way to quit the application. I could stop the broadcast from playing, but the application remained open and at the taskbar on the top of my screen. To close that version of the iHeartRadio application I had to force quit the application – which was crazy!

Currently, the iHeartRadio app includes an Exit App option, buried inside the Settings screen:

I use the UHC Motion application about twice a month to sync my daily steps for Health Savings Account purposes. The application provides an easy way to review my steps for the day (as shown below) and for the month, but it lacks the ability to easily exit the application. Instead, I must hit the back button on my mobile device what appears to be a million times before the application closes.

If I check the settings there is a Log Out option, but I don’t think that I want to log out … especially since that action does not close the application either.

In both cases, how hard is it to place an exit/close option on the main screen or to require only a single press of the back button?


The importance of a good UI/UX design is equally as important as the product or service being provided by the application. I think it is important for development teams to understand cases where:

  • Default selections can be set, cutting down on predictable functionality that is required.
  • The UI/UX and developers share common tooling.
  • Applications include the basic functionality to minimize end-user frustration.

These are just three examples of how common sense and collaboration can lead to a much better user experience.

Is Bimodal IT A Realistic Approach?

The topic of bimodal IT has been around for several years and I have a couple clients who are actually considering implementing a bimodal approach to meet the needs of a wide customer base. Upon hearing one particular client talk, with enthusiasm, about implementing bimodal for his team, I wondered if the expectations being set are truly realistic.

Gartner’s Definition

According to IT research firm Gartner, bimodal IT is “a collection of principles, capabilities, methods, behaviors, and approaches that enable an organization to differentiate the normal from the abnormal, the evolution from the revolution, the continual improvement from the disruptive innovation — and manage them differently but coherently. It’s about the business, not IT, even if in some cases bimodal starts within IT.” (Source: Gartner – Deliver on the Promise of Bimodal)

Two modes have been established, to define bimodal IT:

  • Mode 1 focuses on predictability and has a goal of stability.
  • Mode 2 is exploratory and is best-suited for areas where an organization cannot make an accurate plan because of too many unknowns.

In essence, Mode 1 operations are basically “keeping the lights on” from an IT perspective, while Mode 2 is where innovation work is performed for future design.

A Similar Example

The bimodal approach outlined by Gartner matches an experience I ran into while working as a full-time employee a few years ago. This scenario was driven by two recently promoted individuals who both reported to the CIO. In an effort to figure out how to allocate staff across these two senior vice-presidents (SVPs), the decision was made that one-half of the development team would be in charge of new application development (Mode 2), while the other half would be in charge of production support for applications that were fully deployed (Mode 1).

Perhaps, on a whiteboard or an organization chart, this sounded like a logical breakdown. One SVP handled everything in production, which included the Data Center and associated support staff, plus a development team to handle break/fix needs and minor feature requests. The other SVP would be focused on meeting the emerging needs of the business, agile and exploratory in nature, to provide solutions that were flexible and not confined by legacy decisions.

The Mode 2 team would provide innovative solutions and, once ready, they would pass the solution to a Mode 1 team, before starting work on the next innovation.

The resulting challenge for this approach is that, more often than not, the solutions designed by the Mode 2 team were not completely thought through from a production support perspective. It was like the team put on blinders and developed a solution that met the business need with a laser-focused approach. While meeting the requested need, the solution often did not fit in well with the larger IT application infrastructure. In some cases, competing frameworks and languages were selected, which had an adverse effort on the Mode 1 team attempting to support the application once it was transferred to their control. In several cases, the Mode 2 design approach was not complete, exposing a backlog of technical debt that had to be corrected as part of the first production support Sprint implemented by the Mode 1 team.

Attempts to resolve these design issues were not successful because the Mode 2 innovators always focused on the next innovation and failed to consider how their decisions impacted production support of the application. As one might imagine, this caused discord between the two modes and cultivated an environment that, though once enjoyable to work in, became challenging at best.

The core of this issue was the need to split up staff in order to accommodate two individuals who were recently promoted. As a result, changing the model wasn’t a possibility. The better approach would have been to maintain one development group. Instead of fully dedicating the staff to a given mode, rotating the roles periodically would have been a much better approach. Meaning, the team introducing a new innovation would continue to support/maintain the application, while the other team would be assigned the next new project. I have found that if the Mode 2 innovators go into the process knowing they will need to support their solutions, they are more likely to be responsible with the decisions that are made.

Alternative Views

Alternative views of Gartner’s Bimodal IT have been published. While some critics recommend staying clear of Gartner’s Bimodal IT, others are supporting Simon Wardley‘s Value Chain Mapping (VCM) concept. The approach behind VCM is almost trimodal in nature, where a value chain exists to meet the ever-changing needs of the business. As part of this chain there are three groups:

  • Pioneers – truly innovators, like Mode 2 teams in Gartner’s Bimodal IT.
  • Settlers – the missing layer – a team dedicated to refining, maturing, and stabilizing products before they are considered production-ready.
  • Town Planners – truly production support, like Mode 1 teams in Gartner’s Bimodal IT.

The following diagram, courtesy of Simon Wardley, demonstrates how Value Chain Mapping fits into meeting the needs of the business:

Image title

Keep in mind, the chart above is simply one step (out of ten) in Simon Wardley’s “How to get to Strategy” publication, which I recommend reading when time allows.

In my experience, larger corporations have placed the pioneer need into the hands of enterprise architecture (EA) staff. The EA team maintains the responsibility to innovate, making sure their innovations have the ability to work within existing IT infrastructures. A challenge to this approach is that the burden can be too much to place on the settlers – since they are not always approaching the solution with the same mindset as the pioneer. The pioneer’s vision is one of enterprise scale, while the settler has a focus on meeting the current need of the business. So, even in a trimodal (or VCM) approach, challenges should be expected.


I understand there are individuals who thrive as innovators and there are individuals who enjoy their focus on providing production support. However, for a majority of those in Information Technology, there is a desire to participate across both ends of the spectrum. It is important to understand the background, goals, and traits of your staff before trying to place them into positions which are not a solid fit, based on their skills, abilities, and ambitions.

Since an IT department’s greatest investment is the human resource expenditure, the decision to implement bimodal, trimodal or nonmodal (I just made that up) should be driven by the people who will actively live in that mode. Making the incorrect decision and hoping for a positive result is no different than trying to place a round peg in a square hole.

Playing Find and Seek on a New Project

Playing Find and Seek on a New Project

Have you ever found yourself in a position on a project where you struggle to obtain answers to your questions?  For me, I encountered this situation while being part of a team converting an application built in a proprietary language to a solution based on standardized languages and frameworks.

On this project, the stories contained references to program code in the current version of the application. This caused our team to play a game I have referred to as “find and seek” in order to derive the underlying business rules and functionality.

The Building Contractor Example

Reviewing a significant amount of proprietary code eventually leads to uncertainty with the results provided. While doing my best to analyze and understand program logic written in an application that I am far from an expert in, there are times when I would need to reach out to the subject matter expert (SME) on the project. Upon asking my task-related questions, most of the answers referred to revisiting the current code to gain an answer.

While I certainly understand that everyone, including the SME, is very busy with tasks related to the project, the following example came to mind:

Assume that my job is to frame houses for a living. I have a strong understanding of the framing process and have experience with the tasks assigned to me to yield a fully framed home. While on a project, I reached a point where I needed answers from the architect on the project. When I asked for a quick answer to my question, the architect instead provided me with the following answer:

“Get into your vehicle and drive about 20 miles to a house I completed prior to this project. Ask to enter into the home and find your way into the attic. Once in the attic, if you review the work I completed in the northwest side of the home, you will understand how I want this task completed.”

In essence, the architect asked me to make a 40-mile round-trip drive to (hopefully) gain access into a home which had the same requirements when built. The hope is that I can actually gain entrance into the home to be able to navigate inside the attic to obtain an answer to a question that could have been provided by the architect within a much shorter period of time.

The Cost of Find and Seek

While the building contractor example may sound absurd, asking a team member to spend extra time to find an answer is not much different. When these types of situations continue to occur, it is easy to understand how a project can stall or go over budget as team members continue to derive requirements and functionality from the version of the application that is being replaced.

In addition to the loss in time, there is the aspect of the time required to regain productivity after an interruption in planned work. The following graphic appears in Arshad Hossain’s blog entry “A study on unplanned interruptions in software development:”

With a goal of obtaining 70% productivity, the time period between data points I3 and I4 demonstrate the loss of productivity due to an interruption. Based on the graphic alone, it appears there is a 45-minute period of time where productivity bottoms out at 10%. In this example, the author references helping another individual during this time, but the segment could also reference the topic discussed in my example.

The productivity does not reach zero, as some level of productivity is gained from the find and seek effort. Eventually, productivity reaches 80% before a break is taken.

By comparison, the I1 data point could represent the impact on productivity if the SME was to take a few minutes to provide an answer. Here, there is a small drop during the conversation, but productivity increases rapidly as a result of the quick assistance provided.

Impact on the SME

Looking at the graphic from Arshad’s article could raise the question, “do the I3 and I4 data points represent the productivity loss by the SME by fielding questions about the application being converted?”

Considering the role of the SME, I don’t believe this is a valid consideration. While the SME’s productivity will be impacted from answering the question, it is part of the SME’s job to provide expert information regarding the current application. In fact, Arshad Hossain concludes, “On average, about 40% of working time is lost because of interruption, but not all of it should be counted as waste as some of it is unavoidable and some of it can actually increase other people’s productivity.”


I truly understand the task load on team members during application conversion projects. During these types of projects, the product owner, development lead, and other key roles are often overloaded with tasks because they’re focused on delivering a quality product at an accelerated pace. However, it is important to keep in mind the impact that asking team members to play “find and seek” has on not only their productivity, but also the cost of the project.

If your business is looking for help with software asset management, building an app, cloud consulting, or any other IT issue, our team at CleanSlate can help. Contact us today.