Empty Security & Vitamin Cookies

In my previous post, I mentioned the “wicked son,” the vendors who want to give their customers a sense of security, but do not actually want to implement any cumbersome security algorithms. I had a customer using H.323 who sent me specifications for a security implementation for H.323 where the password wasn’t known in advance, and asked us to support it. When I mentioned to them that they were showing the password in the open, where anyone who wants can (read more...)

By Ran Arad  |  April 30th, 2008  |  Filed under SDKs, Standardization
Add a comment 

Four Sons of VoIP security

On the Jewish holiday of Passover, we read about the tale of the four sons: One wise, one wicked, one simple and one who does not know how to ask a question. In this special Passover post, I will consider their approach to security.What does the wise son say? For the wise son, no amount of security is enough. He will use authentication, integrity and privacy algorithms to protect his online data and communications, although he knows that all measures (read more...)

By Ran Arad  |  April 23rd, 2008  |  Filed under SDKs, Standardization
Add a comment 

Logs + Scripts = Ownage

At times, I like to keep scores between Development and Customer Support (CS). If a problem is on the customer’s side, a point is awarded to development and if the problem is with our code, a point is awarded to customer support. Then there are the many special cases, for example problems with documentation (points for CS), problems with API design (more points for CS), problems fixed for another customer already (points for Development) problems which are already fixed in (read more...)

By Ran Arad  |  April 14th, 2008  |  Filed under SDKs
Add a comment 

Gabe Wachob: Memo to API Service Providers

Gabe Wachob provides tips for API developers. In contrast to my low-level approach, Wachob looks at API design from a holistic perspective. Although he speaks on API design for web services, most of his tips are relevant to every aspect of API design. For example: API can be seen as a separate product you are delivering One can document the service and not just the API Provide a reference client application to demonstrate usage of the API The one that I am most fond of involves developing against your API “fun and personal”. Wachob links another post explaining that last point, in which he writes: “If you are a developer, you know what the thrill of the hack is - when your building something, and you sit down and implement a new feature and all of a sudden, your stuff plugs into a bunch of other people’s stuff and what was once a cool standalone thing is now part of an ecosystem of interoperating cool stuff. The whole becomes greater than the sum of the parts. And you, the developer, are part of it.” Here Wachob references web services, developer communities and open source development. I need to think about how this translates to the design of product APIs and protocol stacks and I’m open for new ideas.

By Ran Arad  |  April 9th, 2008  |  Filed under SDKs
Add a comment 

Naughty protocols, need spanking

I have previously mentioned Joel Spolsky’s brilliant post about standards. If you’ve not read it yet, it is really worth your while. In that post he quotes Jon Postel‘s robustness principle and Marshall Rose’s critique: Counter-intuitively, Postel’s robustness principle (”be conservative in what you send, liberal in what you accept”) often leads to deployment problems. Why? When a new implementation is initially fielded, it is likely that it will encounter only a subset of existing implementations. If those implementations follow (read more...)

By Ran Arad  |  April 7th, 2008  |  Filed under Interoperability, Standardization
Add a comment