" /> BP's Weblog: July 2007 Archives

« June 2007 | Main | August 2007 »

July 17, 2007

In the doghouse: iamidentity.com imdentity.com

I've been tinkering lately with the mypw.com service, which offeres a SecureID-like service that's exposed as a webservice. Pretty nifty. I guess I was going to miss the two-factor SecureID I have working at PARC, or something. More on that once I've got something fun working.

However, looking for other places to test things out, I noticed they have a partner, iamdentity. These people win my first DogHouse award (in the style of Bruce Schneier). When you get to their website, it's not 100% clear what service they even offer. How does a service which keeps an additional copy of your personal information safeguard it, exactly? I suppose single signon is useful, but....

So, I click on the "New Client? Click to apply for an iamdentity account" link, which takes me to a scary questionnaire to "assess my risk". It's riddled with typos and questions you can't really answer correctly.... After scary questions like "Have you ever been successful in ensuring all your personal data has been deleted after canceling a subscription?", and "How often do you familiarise yourself with a sites data protection and online security policy?", you get to click a button and get an answer. I'm pretty sure the best result you can get is:

Although you do spare a thought for personal information security, you are not doing enough and risk becoming the victim of an opportunistic fraudster.

You have taken some precausions to prevent your identity being stolen, but not all the holes are covered yet.

Of course, you're still offered the chance to apply for an account. In the following form, oddly, they ask you for a ton of personal information. Hrm, how are they protecting me, exactly? This form loads from a different domain than iamidentity, some mysterious "ssl-01.com". You want me to trust my privacy to a company that's too cheap to even follow standard practices and register their own SSL cert? And I'm never once given control of the encryption key that stores my data (if, in fact, there even is encryption against my stored data, which I highly doubt).

Once done with the form, you get e-mailed a confirmation link, which includes your initial password. When you log in, they e-mail you again, this time with the session PIN. Apparently, they'll do this each time you sign up. I'm unconvinced how much this helps security, but it certainly does slow down the process, increasing the chance someone's going to ditch their service entirely.

Once logged in, you can see that they're trying to integrate with a small list of probably e-commerce sites. I guess they do do something, after all. No one on the list I've heard of, so, no reason for the account, and the MyPW integration only comes if you pay MyPW $20/year for service on their token. Unfortunately, when I clicked on the "cancel account" link it leads to an error message implying I'll have to contact support to cancel my account (but with no link, error number, or other details). Huh, wasn't one of their questions "Have you ever been successful in ensuring all your personal data has been deleted after cancelling a subscription?" Sure gonna' be tricky this time. The initial e-mail links to a web page for support, but, when I go there, it says I have to e-mail support@iamidentity.comsupport@iamdentity.com for anything other than password or initial signup concerns. So, I do... leaving an ironic comment in the e-mail at the absurdity of this process from a company supposedly providing a user-information-management solution.

... and nothing happened. I made the request to cancel my account nearly 2 weeks ago, and yet, my account still exists. No response to my e-mail was received.

Stay far far away from these snake oil salesmen.

Update: Sheesh. One of my other problems with this site is that, at least for me, it's cognitively difficult to spell their domain. I, for some reason, easily type iamidentity, when it's just plain imdentity. They could have at least registered the common typo domain and redirected. sigh

Technorati Tags: , ,

July 10, 2007

Why SIP sucks and IAX rocks - a rant on latency and the media path

As many of you know, I tend to tinker with technologies... not to build a business around them, but to add them to my bag-o-tricks, or just for the shear fun of doing something that you can't get as easily, cheaply, or, if possible, at all on the open market.

For the last several years, I've been playing around with VoIP. Hardware, software, various ins-and-outs. And, while there are dozens of blog posts I could write about what I've learned, today I'm going to cover one of the issues I've spent the most time tinkering with, because its one of the issues that every VoIP company has to deal with to satisfy their customers.

Several things go into the perceived quality of a telephone call - fidelity, echo, reliability.... and transmit delay. Transmit delay is tricky - up to a certain point, delay doesn't greatly affect the happiness of the callers, but, after a certain point (around 100ms of total delay, a rough amount of latency from many kinds of technologies that start to get annoying), the delay on a call makes conversation harder. So, as a tinkerer with less-than-top-notch equipment and connectivity, I've spent quite a bit of time over the last few years trying to remove latency from the systems I use for VoIP.

This is tricky, of course. You can look up that your provider is in New York, say, and that your colocated box where you run your VoIP is in Pennsylvania. In theory, that should be close enough that the extra latency isn't very noticable. That is, until you discover there are many different ways the Internet might route between New York and Pennsylvania.

One of my best tricks, as the title of this blog implies, is to use a better tool for the VoIP, and thus get out of the way. I use the open-source Asterisk for my VoIP software, which supports both the standards-based SIP VoIP protocol, and its own, proprietary-but-open IAX protocol. SIP has the benefit of being implemented in fairly widely available hardware... IAX is, to a few exceptions, not supported in hardware. But, IAX has a few really killer features: it has a guaranteed-success transfer handoff, and a small enough base of supported devices that interoperability is rarely a problem. If you want to remove latency from your calls with IAX, you just have to teach your system to hand off the transfer of the media path to the two endpoints - no more routing through Pennsylvania even if both the caller and the callee are on the west coast.

SIP can do this, but, it has a much more complicated media path, and a much bigger pool of implementations. With SIP, you might try to do the same trick where you hand off the media path to be direct between the source and destination, but only find out it didn't work when you get a support call complaining that there was no audio on the call. Or, you have to use elaborate discovery tools on your network to figure out which devices are behind a firewall, and which ones aren't, and then check those results before trying to hand off a call.

In my own setup, I have tags I apply to the incoming channels on my Asterisk system. If a call is IAX, I deliberately try to complete it using IAX, and get my system out of the path. Otherwise, I have SIP set up to hand off where it can, but, in practice, I have to leave the configurations a little bit conservative to avoid no-sound issues from cropping up periodically: my callers pay with extra delay.

Bigger corps have different approaches (and, with few exceptions, all have to use SIP). I've read that Vonage has regional centers, and your device is setup to detect the closest one and use that. Then, presumably, they have internal rules to minimize the total network distance your call crosses. Too hard for someone small-time like myself, but probably very effective. GizmoProject seems to push everything through their SIP proxy. Even if you call from one phone on your local network to another. I believe they can still fix the media channel some of the time, though I'm pretty sure its beyond the reach of the Asterisk SIP implementation.

It's hard to get right... especially because some of the ways you can transfer a call effectively put you outside of the call - if you need to bill on that call, this just isn't an option. Here's hoping the day comes soon when providers just charge for listing and support: when we stop paying per minute, we can stop worrying about auditing every second of every call, and instead focus on delivering the best sound experience. Skype has got this right, and cheers to them for their routinely very high call quality.... but, they're not using SIP or IAX, so there's not much that can be learned from them directly.

Unfortunately, my favorite (and, at this point, the only one I've never had a serious gripe with the service of) VoIP provider started out as an IAX-only shop (http://iax.cc/), but got bought-up to a bigger firm that has now started to treat their IAX features as deprecated (http://vitelity.com/). I hope I'm small-time enough that they let me keep the IAX side active - I sure do appreciate the better call quality that results. Further unfortunately, I'm moving across the country soon, so I'm going to have to reconsider what all of my most-prefered choices are for colocation and VoIP routing. Good for my family, though, who is centered nearer where I'll be living, and are likely to end up with better call quality all around. sigh

Ok, . If anyone reading this is interested in my tricks to detect source channel type and try to send outgoing calls to an appropriately matched destination channel type, please chime in on the comments. It's all done with Asterisk macros, and it isn't quite a drop-in fix, unfortunately.

Technorati Tags: , , , ,