1. I was the frontman (singer/songwriter/guitarist) for a band.  We released an album which you can preview and purchase on iTunes.  Personal favorite: track 4.  The band called it quits after the drummer and bass player broke up.  Bonus cliché: I delivered pizza for most of my musical career.
2. Favorite guitar: Fender Telecaster HS (humbucker in the neck position).  When I learned that Fender stopped making them, I bought a second one on eBay and had it professionally set up.
3. My hobby is collecting hobbies.  Music, writing, photography, web stuff, Mac fanboyism, video, social media, cooking, painting, collecting movies, design, drawing, and collecting domain names.  My unmaintainable list of hobbies means I’m not especially good at any one of these things.
4. I was a contributing author for this book.  I wasn’t paid.
5. I’ve been skydiving.  If you haven’t done it, you should.
6. I have a tattoo on my left arm.  It’s the logo for one of my favorite bands, and reminds me that no matter how much of a corporate tool I become, I’m still a wannabe rock star at heart.
7. My hair used to be very long.  Like down to my ass.  I looked like a girl.  Years later, I maintain that cutting it was one of the best decisions I have ever made.

I’m going to risk death and dismemberment now by breaking the chain.  Primarily because I can’t think of seven people who have blogs and haven’t already participated.  I reserve the right to reverse this decision at any time.

BeejiveIM has hit the App Store with their entry in the battle for iPhone IM superiority.  Let’s get right to it.

Aside from XMPP, Beejive offers AIM, ICQ, MSN/Windows Live, MySpace IM, and Yahoo! Messenger support.  Their XMPP support comes in two flavors: “Jabber”, or pre-configured Google Talk.  Strangely, configuring a GTalk account as a “Jabber” account doesn’t work, despite being the same thing.  This is a curiosity, but not a limiting factor by any means.

Adding my primary XMPP account was relatively straightforward, with my ridiculously long password as the lone speed bump.  During configuration, I was struck by the ability to set up a resource, set my client priority, choose a host and port, and determine whether I wanted TLS or legacy SSL (no option for plaintext authentication).  This is already feeling like a real XMPP client.

The login process was similarly confident, offering me the choice between available, away, busy, and invisible presence settings, and the option to set a custom status message for each.

Rich presence?  In my iPhone client?  It’s more likely than you think.

Their “Buddy List” sorts contacts by group (”list by account” is also an option), displaying your contact’s nickname, JID, status, full presence, their avatar, and an icon indicating which IM service they’re using.  If I had to ask for something here, it would be merged contacts, but the interface is solid enough to make this less of an issue.

Chatting is a thing of beauty.  Outgoing messages, as they are typed, are shown in a semi-transparent bubble, giving a clear visual cue when the user is typing, and making the absolute best possible use of screen real estate.  This is by far my favorite feature of Beejive, and one I expect other clients to adopt in the future.  Once the “send” button is hit, messages are shown in the iChat bubble style of the SMS app.

My other favorite feature, and the one most likely to be shown off, is landscape mode.  Yes, you can rotate your iPhone to get a larger keyboard.  Of course, this comes at the cost of message visibility, but the rotation-switch happens quickly and seamlessly.

Now for the obvious question: “does it proxy?”  Yes.  But here’s the good news, from Beejive’s privacy policy:

We do not collect or store any of your instant message (”IM”) account information, such as your user name and password, messages, or contact lists, except that we temporarily store your instant messages solely in order to complete the instant message communication (for example, in response to a dropped call); however after the communication is complete the instant message is deleted from the Beejive system.

Completely fair, and Beejive has a solid reputation.  And compared to MobileChat, their servers are stable and fast.  As a positive side-effect, Beejive servers can notify the client that a message was not delivered, resulting in a cute interface cue to let the user choose whether to attempt re-sending.  There is also an in-app option to set up email alerts if messages come in while you’re doing something else.

Now for the bad news.  At $15.99, it’s difficult to tell if the price is driven by arrogance or ignorance.  This is a fantastic offering, to be sure, but the price will keep many potential users away.  I’ll be shocked if the price is still above $9.99 a month from now.

Beejive has thought of everything, including a built-in help system.  This may be the best 1.0 release I’ve ever seen, and the future looks very promising.  From the iTunes description (emphasis mine):

Coming soon, group chats, emoticons, and full hyperlink support!

BeejiveIM is beautifully designed, expertly implemented, and offers a new level of reliability.  Could it be that we finally have a viable XMPP client for the iPhone?  Yes.

Update: pictures.

      

I understand that people are frustrated and are tired of waiting and Shaun and I feel absolutely terrible. However, all I can offer is your money back. For that, please go to support.twenty08.com and submit a request for a refund.

Blocking updates is orders of magnitude worse than rejecting applications to begin with, because money has already changed hands.  I paid full price for MobileChat, which is, frankly, broken.  But forgivable.  It was a first release, and the developers wanted to be first to market with a real IM client.  I maintain that MobileChat is still a superior product and service to its competition, but if the final word is that I’ll never get an update, I want my money back.

From a developer’s perspective, the App Store may be too much of a gamble; even if your app is accepted today, a future update may be rejected, and you may have to give all of the money back.  From a user’s perspective, your software could see end-of-life at any moment.

Cisco announced today that it has acquired Jabber, an open-source IM and presence protocol used by Google Talk and Gizmo, for an undisclosed sum.

This is so flawed as to be laughable, and very well sums up the quality of research and fact-checking that goes into a typical TechCrunch story.  Still, XMPP is colloquially referred to as the “Jabber protocol”, so this kind of mistake is almost forgivable in the form of, say, an uninformed Slashdot submitter.

Luckily, we have Jack Moffitt to clear things up for us; Cisco is acquiring Jabber, Inc, not the protocol.  Meanwhile, Saint Peter has stepped up to quiet any rumors or innuendo vis a vis the impact this acquisition might have on the XSF or Jabber, Inc morale:

I’m excited to be part of the Cisco team, and I think the whole community will see even more good things happening because of their support.

Argh mateys, Jabber has been boarded by Cisco: http://tinyurl.com/4juk53

WebMessenger requires an account with Callwave before any of the IM services can be used.  They got my confirmation email to me quickly after I signed up, but I don’t see any good reason to put me through this unless they’re doing some kind of undocumented proxying.  Once I was signed into their service, I was asked to set up an IM account.  I picked Jabber, naturally, but not before having to restart the app twice to get it to offer me a choice of services.

After all of that, I was asked to import my “Buddy List” (an AOL trademark, by the way).  I have no idea what this button was supposed to do, but my roster never loaded, and I wasn’t able to test the chat functionality.  When I attempted to test with a second XMPP account to be sure it wasn’t something on my server, I discovered that only one Jabber account is allowed.  This is where I gave up.

“WebMessenger” is a great name for this app, since it has nothing to do with the Web, and doesn’t function as a messenger.  I expect more from a 1.0 release, especially when two functional XMPP clients have already been released on the App Store.  WebMessenger may be free, but isn’t worth the headache.

It’s not that XMPP is not up to the job; people just keep making the same mistakes while trying to implement it.

Bonus points for Blaine Cook’s comment below the article.

The original email with his analysis is after the jump.  Meanwhile, I have asked IM+ developer SHAPE Services for a comment.  I’m willing to accept that they’re simply doing something stupid rather than something evil.

Update - SHAPE Services has responded to the story with some clarification.  Their email is below, after Scott’s, but the bottom line is that IM+ does use proxy servers, which SHAPE claims are on the up-and-up.

Update 2 - Another round of emails from SHAPE.  This time, on the issue of logging.  The good news is that they say no customer chats or login information are logged.  Everything else is for support purposes, and they claim to have a solid security record.

The willingness of SHAPE Services to quickly address these concerns and set the record straight says a lot; they could have ignored me entirely.  Clearly, their reputation has value to them, even if the application itself is free.  Their one true mistake was not specifying the gateway/proxy functionality in the iTunes write-up.  A mistake that they tell me will likely be fixed next week.

My hope is that you’ll take all of the information into account when making a judgement about this application.  The existence of a security analysis is not itself an indictment of IM+.  This is simply the system at work.

Dave,

As soon as IM+ was released I analysed the network traffic and came to the conclusion that in fact it is doing proxying, just in a different way, and worse, it looks potentially primed to share sensitive data with the company that makes IM+.

From actual network captures performed yesterday:

The app looks up some host in Germany, which is the “gateway” for the company that makes the client.  When it connects, it sends:

0×0030:  3b90 f309 fe00 4741 736b 4761 7465 4f70  ;…..GAskGateOp
0×0040:  7420 6c63 6b65 7928 2920 6272 2849 5048  t.lckey().br(IPH
0×0050:  4f4e 4529 2076 6572 2831 2e30 2920 696d  ONE).ver(1.0).im
0×0060:  6569 2831 3131 3131 3131 3131 3131 3131  ei(1111111111111
0×0070:  3131 2920 7264 7228 6661 6c73 6529       11).rdr(false)

Okay, so, this release doesn’t send your IMEI, but there’s certainly nothing stopping a future version doing it!

This seems to be a form of license check.  It would send your IMEI to the company, which checks to see that you have a valid license.  They sell this client for other devices, it’s free for iPhone.

This generates a unique ID:

0×0030:  1a7a 70d2 0023 4964 2069 6e73 7428 3441  .zp..#Id.inst(4A
0×0040:  4245 3242 3437 4236 3237 5f44 3737 3746  BE2B47B627_D777F
0×0050:  3737 4238 4141 3529 0a                   77B8AA5).

Which if it did an actual comparison would probably activate the client on non iPhones.

As an ACK to the license being installed, the iPhone sends:

0×0030:  3b90 f325 fe00 5c49 6420 696e 7374 2834  ;..%..\Id.inst(4
0×0040:  4142 4532 4234 3742 3632 375f 4437 3737  ABE2B47B627_D777
0×0050:  4637 3742 3841 4135 2920 696d 6569 2831  F77B8AA5).imei(1
0×0060:  3131 3131 3131 3131 3131 3131 3131 2920  11111111111111).
0×0070:  7264 7228 6661 6c73 6529 2070 7274 636c  rdr(false).prtcl
0×0080:  2832 3030 2920 6376 6572 7369 6f6e 2831  (200).cversion(1
0×0090:  2e30 29                                  .0)

Which is essentially the “login” to the system as well.  This generates the response of:

0×0030:  1a7a 70d3 0020 5264 7220 6970 2837 302e  .zp…Rdr.ip(70.
0×0040:  3338 2e32 342e 3137 2920 706f 7274 2833  38.24.17).port(3
0×0050:  3030 3030 290a                           0000).

HELLO…

AS      | IP               | AS Name
32613   | 70.38.24.17      | IWEB-AS – Groupe iWeb Technologies inc.

Some Canadian hoster which I am pretty darn certain is NOT America Online.  If you look for login.oscar.aol.com, you’ll get an IP like:

AS      | IP               | AS Name
1668    | 205.188.179.233  | AOL-ATDN – AOL Transit Data Network

But that may vary depending on various factors.  No matter what, this is not AOL though.

From there, the iPhone connects to the iWeb site, offering the same “here is my ID and IMEI” authentication check, which causes the second server to generate a list of services supported:

0×0030:  1a7a 7230 012a 4964 2073 6964 2837 3235  .zr0.*Id.sid(725
0×0040:  3932 2d38 3631 3731 290a 5472 616e 7370  92-86171).Transp
0×0050:  2074 7228 4929 2064 6573 6328 4943 5129  .tr(I).desc(ICQ)
0×0060:  0a54 7261 6e73 7020 7472 2841 2920 6465  .Transp.tr(A).de
0×0070:  7363 2841 4f4c 290a 5472 616e 7370 2074  sc(AOL).Transp.t
0×0080:  7228 4d29 2064 6573 6328 4d53 4e29 0a54  r(M).desc(MSN).T
0×0090:  7261 6e73 7020 7472 2859 2920 6465 7363  ransp.tr(Y).desc
0×00a0:  2859 6168 6f6f 290a 5472 616e 7370 2074  (Yahoo).Transp.t
0×00b0:  7228 4a29 2064 6573 6328 4a61 6262 6572  r(J).desc(Jabber
0×00c0:  290a 5472 616e 7370 2074 7228 4729 2064  ).Transp.tr(G).d
0×00d0:  6573 6328 476f 6f67 6c65 2054 616c 6b29  esc(Google.Talk)
0×00e0:  0a54 7261 6e73 7020 7472 2850 2920 6465  .Transp.tr(P).de
0×00f0:  7363 284d 7953 7061 6365 290a 5472 616e  sc(MySpace).Tran
0×0100:  7370 2074 7228 5429 2064 6573 6328 5472  sp.tr(T).desc(Tr
0×0110:  616e 736c 6174 6f72 2920 6973 626f 7428  anslator).isbot(
0×0120:  7472 7565 290a 5472 616e 7370 2074 7228  true).Transp.tr(
0×0130:  5a29 2064 6573 6328 534d 532b 2920 6973  Z).desc(SMS+).is
0×0140:  626f 7428 7472 7565 2920 6372 6564 6974  bot(true).credit
0×0150:  7328 2d31 2920 656e 6428 7472 7565 290a  s(-1).end(true).

Quite interesting.  It looks like the system is meant to dynamically update the protocols supported on the fly.

Keeping in mind that all of this is to the Canadian site, the next few packets are the interesting ones:

0×0030:  33ad f3cc fe00 404c 6f67 696e 2074 7228  3…..@Login.tr(
0×0040:  4129 206c 676e 2849 6d70 756c 7374 6573  A).lgn(Impulstes
0×0050:  7465 7234 2920 7077 6428 3030 3433 3030  ter4).pwd(004300
0×0060:  3537 3030 3436 3030 3444 3030 3537 3030  570046004D005700
0×0070:  3546 3030 3043 29                        5F000C)

The gateway server takes the (A) style login data (AOL), the username, and some encoded password, and then passes the data on to AOL.

So it effectively operates just like Palingro or the other proxying servers, using your IMEI & license (if you have one) as your authentication credential to the German IM+ system and proxies your connections on from there.

In my opinion, this is even worse than Palingro/etc as it appears to be a direct connection when it definitely is not.

Regards,

Scott

The response from SHAPE:

Dear Dave,  

Thank you for the attention to our service.
Below is the answer from our developers, please pass it to Scott from XS4ALL.

We feel very sorry if the information in IM+ or on our websites was
misleading in any way. All our IM+ implementations, except versions
for Symbian and Windows Mobile devices, are connecting to IM services
through the gateways, developed by us and hosted in Europe and North
America. Even though we might also implement direct connection for
iPhone version, like for Symbian and Windows Mobile, our experience
shows it is by far not the best approach regarding service
reliability, upgrade capabilities and features. That’s why we’ve
implemented the gateway-based approach, like we (and all other mobile
IM vendors) do on other platforms.

SHAPE Services is developing mobile IM clients since 2003 and we
believe there’s no way we can be suspected in any illegal or dangerous
activities.

We’d be happy to see your suggestions on how can we avoid such
misunderstanding among other IM+ for iPhone users. 

In case you have any additional questions, feel free to send them to me or to Alex Makarov, Head of Development at SHAPE (CCd).

Thank you in advance.
Maria Dyatlova
Alliance Manager
SHAPE Services

Followup from SHAPE:

No conversations, credentials or other personal data is stored on the gateways. Credentials are only used once per each login procedure, and are not stored anywhere. Messages are passed through the gateways and are also not stored or logged. We only keep registration-related information (that is, license keys) and some non-personal information for statistics, such as device model, IMEIs, connection method to provide better support etc. This system is in use for more than four years and we had no complains about any security breaches.

For closed environments where conversation logging is mandatory we provide dedicated gateways setup with support of commercially available IM archiving services. 

Connection error

The ID [JID removed to protect the innocent] does not exist or do now allow subscribshion

That’s sort of cute.  The interface is otherwise pretty tidy and easy to use, though not very feature-rich — presence options are limited to online, away, invisible, and offline.  The Inbox icon at the bottom of the screen updates when a new message comes in, but tapping it leads to a confusing list of open chats.  Apparently the envelope with paper in it means no unread messages, but a closed message means one or more unread messages.

One-to-one conversations are functional, if not pretty.  Instead of MobileChat’s Adium-style conversation windows, IM+ offers the simpler approach of alternating blue and red usernames.  Only the remote contact’s username is shown — the local user is simply “You”.

Also unlike MobileChat, IM+ doesn’t appear to be doing any proxying, instead connecting you directly to the server.  This means that when you close the app, your connection is terminated, but the upshot is that none of your login credentials or private conversations are being stored on someone else’s servers.

XMPP support is included (yay!), but IM+ sweetens the deal with AIM, MSN, Yahoo, and MySpace IM support.

The app feels stable enough, and the major features are in order.  If not for the god-awful ugly icon and some interface quirks, this could be a five-star application.  As it stands, I’m very excited to see someone stepping up to give MobileChat some competition.  

Update –  Scott A. McIntyre has emailed me with a detailed analysis of IM+ traffic that may indicate something worse than proxying.  Please see this article for details

1. To clarify, the error occurred because I had a pending subscription request to an invalid contact.  In short, I mistyped someone’s name, and the client was reporting the error.

Jabber/XMPP

• Fixed authentication on XMPP in cases where GSSAPI fails (#9492)
• Fixed bug where you couldn’t join a group chat after trying and failing once (#1874; #7388)
• Fixed not updating the userlist for nickname changes in group chats (#479)
• Fixed bug that would allow you to try to message contacts from accounts that don’t have the contact on their contact lists (#5152)
• Fixed offering to unregister GTalk accounts when you delete them (#9798)
• Fixed error when trying to log into Wildfire Jabber server (#9801)
• Fixed passwordless login on broken Jabber servers (#9748)
• Fixed a crash when finishing a file transfer (#8979)

Alex will be working exclusively on the MobileChat iPhone client and will be working to improve stability as well as the overall user experience. We’ve discussed some great plans for UI improvements and we’re very eager to see them implemented. 

(Via TUAW)

Why would twenty08’s servers be impacted, you ask?  MobileChat offers pseudo-persistence by logging in on your behalf, then doing live updates to the client while it’s open.  When MobileChat is closed, the service continues to collect messages for you until you log in again.  Assuming you trust them with your IM passwords, this is really the best you could hope for, and the only way you’re ever going to get around mobile problems like connection-hopping and driving under tunnels.

As soon as Apple releases the push services, MobileChat will utilize the push API to send message notifications to your iPhone.

Oh, and it supports XMPP.  

[Update] - Saverio at twenty08 has sent me a copy of their privacy policy, which should be on the twenty08 site and iTunes soon.

“I understand your concerns; however, we are not evil :)”

They do cache all information, but much of this seems to be legal ass-covering rather than a statement that they’re reading your chat logs.  

[Update 2] - Since it isn’t immediately obvious, I’ll point out that storage of personal conversations is absolutely necessary for this service to work.  And yes, this is a service as much as it is an application; twenty08 is holding your messages for you while you’re disconnected.

The full policy is copied below, so you can draw your own conclusions.

“twenty08” owns and operates a number of websites, including (but not limited to): twenty08.com, tumblr.twenty08.com, mobilech.at, quickshareit.com. These will be known as the “Websites”. Each website has its own privacy policy, as each website and/or brand offers different products and/or services. The purpose of this document is to alert you (the prospective user) of the privacy concerns associated with the use of MobileChat. This document may change without notice and an updated version can always be found by clicking the link found at the bottom of mobilech.at. 

General Website Access 

Access to the mobilech.at website will not yeild any requirements for personally identifiable information. You may visit mobilech.at without the need to identify yourself. We do not collect any information aside from the standard information supplied to us by your computer’s browser. This information includes: Cookies, IP Addresses and Session information. While you may not be forced to provide personal information for general website access, certain information may be needed in order to access special features and or use the products or services. 

Usernames and Passwords 

The nature of MobileChat forces us to store your usernames and/or passwords for the various IM services on our servers. We have taken many precautions to ensure that your data is kept out of harm’s way; however, “twenty08” nor it’s founders , will not be held liable in any way should a security breach occur. On that note, we will ensure that we make every effort to contact our users if such an event should occur. 

Collection of Usage Data 

“twenty08” reserves the right to collect and harvest any data that occurs as a result of usage of our products. This information will be kept for internal usage to develop solutions on how to better our products. Information such as usernames, passwords, buddy lists, conversations, IP addresses, away messages, profile contents and more is retained and “cached” on the server as a matter of operation. Once this information is stored, we retain the right to use it as we need to. We will NEVER sell or distribute your information with or without your consent. We are dedicated to providing a safe platform for our users and will ensure that our user’s data remains within our control and out of harms way. 

QuickShareIt Integration 

MobileChat benefits from another one of our products, called QuickShareIt. If you, the user, engages in usage of this feature, you are implying that you have read and agreed to the QuickShareIt terms of service and privacy policy listed at the quickshareit.com website. 

Storage and Disclosure of Your Communications 

By using MobileChat you understand that your information and conversations are logged as a matter of operation. (We use servers to sit between our users and the IM services in order to keep users connected.) As a result of this, we need to keep track of all data going to and from our servers. We take great care in ensuring that our user’s data remains safe and out of harms way, but as a MobileChat user you must understand that your data is retained within our datacenters. 

“twenty08” may disclose chat logs if required by law. This is a legal obligation and this standard is upheld with the IM services that we work with as well. 

Cookies 

“twenty08” may use cookies on the Websites. Cookies are small text files that are placed on your computer’s hard drive by our servers to identify your computer to our servers. You can disable cookies through your web browser; however, some features of the Websites listed above may not work as intended nor function at all. 

IP Addresses 

“twenty08” logs IP addresses of the visitors to the Websites as well as via the MobileChat application. We use this information for various operation; however, these may be used for investigative scenarios should we suspect abuse of our services or products in accordance with our terms of service. We may turn this information over to the authorities should a situation of this nature arise. We will NEVER share information regarding your personal identity unless required by law. 

Changes 

Changes to the privacy policy will be posted to the website at mobilech.at. We may or may not notify users of changes. 

Legal 

“twenty08” is operated and hosts all of it’s products and services in the United States or Canada. We use a variety of vendors and as a user, you must uphold to the governing law of these jurisdictions. Regardless of whether or not you are connecting from the United States, as a user of our service, you are required to follow the laws regardless of the statutes set in your own jurisdiction. 

Acceptance 

As a result of your usage of any of the Websites or MobileChat, you accept in full, the privacy policy and terms of use. The terms of use incorporates this privacy policy and is available via the website at mobilech.at 

Comments and Questions 

If you have any questions or comments in regards to this document or anything else in relation to MobileChat, feel free to contact us at support@mobilech.at. Or mail us at twenty08 – 173 N. Main St. #114, Sayville, NY 11782

In all, XMPP has been around for almost 10 years. It is open, standardized, robust, widely-implemented, and straightforward to understand compared to most other protocols in this space. Yes, it’s different than HTTP, or anything else a web developer might have run in to. That’s because it solves a problem that isn’t easy to solve in the traditional HTTP world: bi-directional, asynchronous, short-latency structured communications.

HTTP for pull, XMPP for push.  Federated, presence-enabled push.  As soon as someone creates a whiz-bang web development framework for XMPP, the web community will be all over this stuff.

For any user of instant messaging and other presence-enabled social applications, it is second nature to look at the presence indicators in the application to see who is online and available. This, the most basic use of presence information, provides considerable value, even without any messages being sent. Presence has particular value during emergencies, when it is necessary to determine the status of many people but there is no time to contact them all on an individual basis.