New rule. “If you are a developer you cannot trust your designers”. If you happen to do both, Don’t trust yourself. Hold your thought on this one. Right now, I will deal with the title. “Why Interfaces lie”. Recently, I was browsing through some websites, most of them of significant importance. To name a few domains, governmental, state run companies, online services, real-time booking services and smaller user-base networks. I noticed one thing they had in common. ‘Weak Interfaces’. I noticed their online interfaces had loopholes that might still be unknown to the developer of the backend application.
Take an example. Google’s default search engine results number is probably set as 10 and documented the same in its early development stages.
I was able to bring the number to 1 result per page by simply modifying the value of the first option entry by firebug and blindly believing there was no validation for the lower bounds.
It is pretty sure from the interface Google doesn’t want a single result to be listed. Though this does not create any concern to integrity of the database, it clearly brings to light how weak the constraints set by the designer are.
SQL injection through input forms and Header injections to manipulate cookie information and authenticate websites are prevented to some levels now. However a large number of basic validations are not done just because the backend programmers believe the data received through interfaces are safe. The information relayed across these containers have least amount of respect for the limits set by designer. This works almost everywhere and the validation is often implicitly neglected. The interfaces today are very highly manipulative and unless a refined form of validation is applied to the process logic level some back-doors can create unexpected results.
I was able to a process an online recharge of 5 rupees when a certain telecom company’s basest recharge option was 55 rs. This is no fraudulent action. However it denotes the decreasing credibility of the bounds set by the designer and increasing amount of validation that needs to enforced at the business end. A much more substantial implication would be on the resources. The company let me process the recharge denomination through the online banking portal of a third-party organization and reverting it back when it finally detected the anomaly at an inner core level. Thus creating an alarming denial-of-service (DoS) scenario taking advantage of this hole. This signifies the importance of a refined way of treating interfaces.
2 Responses to “Why interfaces lie…”
Dear sir, I strongly feel that what you have identified is not the work for a designer. Neither is it the work for a developer. It is the work for a certain fabled beast known as a business analyst.
Or if such a creature is not available to watch for and communicate these issues for said designer and developer to remedy then the more technical of those two (whoever understands a sentence such as “SQL injection through input forms and Header injections to manipulate cookie information and authenticate websites are prevented to some levels now.” – surely the developer?) should aid the less technical one to allow them both to reach a common goal of not allowing one google result, a 5 rupee charge or other more nefarious activities to occur.
Basically I am saying that you are not saying interfaces lie, nor backends lie but both can combine to let business logic lie. And who is responsible for the business logic? If it’s your designer it might look awesome but you should reconsider your team structure.
Strongly I tell you.
@Jammy I may have sounded a bit polarized in this conversation trying to accuse the programmer of some necessary responsibilities. What I was trying to convey was the importance to secure the data passed through interfaces, especially form submissions. Let me elaborate further with the google example. The organization at large may have decided upon a 10 results per page as the bare minimum. This lower bound may be prepared by the business analyst or any information architect. However, It comes to the developer to identify these basic requisites for information handling such validation, normalization and type-checking. Even if the solution rests with this so-called analyst, many organizations have failed to identify this at a lower level. At this level, a common goal would be broken down into individual responsibilities. Somewhere here, the procedures have to be polished to prevent such problem. I have used a designer/developer perspective to elucidate this problem. We all know companies like Google have a more complex team structure.