Application security - too much function brings problems

In the past 5 days i came across 3 examples which proved that too much functional complexity can backfire in terms of business competitiveness and security:

  • The car example - I read an AutoBild 100,000 km test of the BMW series 7. Their biggest complaint was the iDrive system (no relation to Apple). The idea of BMW was that a single computer interface will replace the arrays of buttons and dials on the central console of the dashboard (from radio to suspension setting). The initial version of the iDrive system was so complex that it became a nightmare for the driver to use it. The end result-a very expensive car that is a difficult to use, and sometimes even dangerous since the driver is focusing on the iDrive instead of the road
  • The phone example - My 2.5 year son loves to play with my cell phones. While usually interested in fiddling a phone for around 2-3 days before he got bored, he is still constantly playing with the iPhone. What is even more fascinating, he is quite adept to actually activating and deactivating the iPhone's features without any help from an adult except for the initial showing. Although not an actual user of the iPhone, he knows how to use most of its features.
  • The software example - I was doing a review of an application design for a Engineering ACME company. This application has a feature which enables the user and manager to follow what actions are performed, and to revoke any of his commands even out of sequence, provided they are not interdependent. While a possibly good idea in the long run, the implementers placed the invocation of this feature the action history in many places, including one wrong place. With this wrong place, they caused a situation in which action history can be invoked even if the user is logged off, and a command for cancellation or re execution can be issued. While no harm can be done at the moment since there are no credentials to complete this change, the implemented mechanism of the action history cached the issued command and completed it upon a successful log-on of the user whose action is to be changed.
These three examples lead to the following conclusions:
  1. It is rarely good to choose a solution only based on the function set it offers.
  2. Bad implementation of functionalities can make a very expensive high quality product to a situation where people will be afraid to use it
  3. Bad implementation or too much functionalities can make a product under perform, or cause a situation where people will be afraid to use it, thus not using the features they paid for
  4. Bad or too fast implementation of functionalities WILL produce security issues which can even pass undetected into production
  5. Good implementation will enable fast adoption of any product, no matter how inexperienced a user is
  6. Simplicity of the user interface does not mean it is based on simple or inflexible engine.

The users, especially corporate users buy on number of functionality, not on the quality of implementation. But a complex poor implementation WILL backfire.

It is only a matter of time before it does. The later it does, the more problems the software developer will have to fix the problems, if he can fix the problems at all!

The iPhone and the iPhone community is an excellent tutorial for system architects and software engineers: Have a strong core, and develop functions one at a time. Don't just overload the system with functionality.


Related posts
Security risks and measures in software development
Security challenges in software development

Talk back and comments are most welcome

No comments:

Designed by Posicionamiento Web