Keep Web Services on a Diet

 
 
By Peter Coffee  |  Posted 2005-02-07 Email Print this article Print
 
 
 
 
 
 
 

Opinion: Use affirmative APIs and content-analysis tools to make sure they're eating right.

Nobel Prize winner Robert Solow once warned of the hazards of oversimplification, saying that one could call it the occupational hazard of being an economist—except that it was actually the occupation. In the same way, one could say that its the occupation of the Web services developer to make a companys intellectual property available to a wider range of users in a broader variety of ways. Unfortunately, theres no clear boundary between that occupation and the corresponding hazard of doing it too well.
Attacks on Web-based assets are hardest to block when they work by taking "success" too far: when a server gets more hits than it can handle in a simple denial-of-service attack, or when a file access method turns out to be more general-case than intended.
Moreover, we quickly put ourselves into a domain of diminishing returns when we try to define, ever more precisely, the things that we wont permit to a human user or a client application. We might call this the Kerr effect, in honor of the late Jean Kerr, author of "Please Dont Eat the Daisies"—a book whose name came from the hard-learned lesson that a rule-based approach to regulating behavior will never get to the last necessary rule. "I had a dinner party and told the twins and Christopher not to go in the living room, not to use the guest towels in the bathroom, and not to leave the bicycles on the front step. However, I neglected to tell them not to eat the daisies on the dining-room table. This was a serious omission, as I discovered when I came upon my centerpiece—a charming three-point arrangement of green stems," Kerr ruefully reported to her readers. Customer-facing systems must be designed to doubt. Click here to read more.
My wary appreciation of the Kerr effect explains, I suspect, many of my preferences when it comes to software and system security. I favor the Java and .Net approach, for example, of stating specifically what privileges a piece of code enjoys, and which resources its allowed to engage, rather than trying to envision every "thou shalt not" that needs to be stated to keep anyone from using my code to eat my daisies. We see another approach along these lines in the content management technologies described in this mornings story by eWEEKs Dennis Fisher, who describes new tools for content analysis and event recognition to safeguard valuable files against unauthorized use or transfer. The determined will still find ways to get past such systems, for example using tools of steganography, and security professionals must stay abreast of these techniques—but bread-and-butter enterprise developers can at least lock more doors against accidental or opportunistic leaks. We dont want to find ourselves following Jean Kerrs path toward ever-more-explicit prohibitions. "Christopher gets up ahead of the rest of us on Sunday mornings, and he has long since been given a list of clear directives: Dont wake the baby, Dont go outside in your pajamas, Dont eat cookies before breakfast. But I never told him, Dont make flour paste and glue together all the pages of the magazine section of the Sunday Times. Now I tell him, of course," she reported. We can write rules and invoke APIs forever—Im pretty sure thats a literal and formally provable statement—and still not prevent every possible exploit of the loopholes that will remain. The affirmative approach, "This is what youre allowed to do," and the exception-detecting approach, "This would be odd and should be reported if it happens," seem to me a much more attractive set of strategies. Tell me what rules you didnt realize you needed, until they were broken, at peter_coffee@ziffdavis.com Check out eWEEK.coms for the latest news, reviews and analysis in Web services.
 
 
 
 
Peter Coffee is Director of Platform Research at salesforce.com, where he serves as a liaison with the developer community to define the opportunity and clarify developers' technical requirements on the company's evolving Apex Platform. Peter previously spent 18 years with eWEEK (formerly PC Week), the national news magazine of enterprise technology practice, where he reviewed software development tools and methods and wrote regular columns on emerging technologies and professional community issues.Before he began writing full-time in 1989, Peter spent eleven years in technical and management positions at Exxon and The Aerospace Corporation, including management of the latter company's first desktop computing planning team and applied research in applications of artificial intelligence techniques. He holds an engineering degree from MIT and an MBA from Pepperdine University, he has held teaching appointments in computer science, business analytics and information systems management at Pepperdine, UCLA, and Chapman College.
 
 
 
 
 
 
 

Submit a Comment

Loading Comments...
 
Manage your Newsletters: Login   Register My Newsletters























 
 
 
 
 
 
 
 
 
 
 
Thanks for your registration, follow us on our social networks to keep up-to-date
Rocket Fuel