I want to direct this towards the folks commenting here who might be in the anti-Apple camp. Yes, a walled garden is no fun for anyone once it reaches a critical mass. We're sort of starting to see this with Twitter, with their recent API adjustments. Decentralized and open platforms are also really tough, just look at OpenID. The adoption is not there.
Apple saw that the current SMS implementation was flawed in many ways and sought out to improve/replace it. For example, all of the carriers (at least in the US, with the exception of the underdog Sprint) charge an exorbitant amount of money just to send/receive text messages. I pay $20 per month for that ability. SMS also has a limit of 160 characters. It also only works via cellular, whereas iMessage works via data connection. This is awesome for me, as I live in the boonies where I don't always have a cell connection (but do have excellent wifi). Being able to reply from multiple devices is also nice. Let's not forget all of the little 'nice-to-haves' like knowing when a message has been delivered and/or read, knowing when the other party is replying, etc...
Alas, they did this because the carriers wouldn't. Prior to Apple releasing the iPhone, you couldn't buy a phone that didn't have some one-off UI, preloaded with garbage apps, etc... Apple forced the hand of the mobile industry with their iPhone (this is obvious to many, but concrete evidence exists inside of the Samsung vs. Apple court documents recently released)
Apple is now doing this again with iMessage. They took something that really needed revolutionizing, and did it. It began as something great for members of the Apple ecosystem. They used their users and platform to prove it, and it's been successful. I can communicate via my Mac, iPhone, and iPad in a (mostly) unified experience. So, I do agree and hope that this expands to a wider audience. That being said, it will be tough. An open consortium leads to all sorts of issues (ahem, Android) and sometimes having one chef in the kitchen yields the best overall experience for everyone (Apple).
How is iMessage better than GTalk on Android (except for the end to end encryption)? GTalk BTW. is a slighlty modified XMPP. It is not even incompatible with regular XMPP clients. It seems to have some additional features to save power by not sending presence updates when its not necessary.
AFAICT Apple did not revolutionize Instant Messaging with iMessage.
It's a seamless experience. Apple doesn't typically innovate on the actual technical software implementation. iMessage at a basic level is very simple. It's the integration in the platform. It's the fact that I do not need to know someone's email address to talk to them on gtalk. Also, what if you don't have a gmail address? Many people do not.
I type a phone number in, begin sending a message, and that seamless/transparent handshake occurs in the background where the device I am about to message tells me it's an iOS device supporting iMessage. I don't need to change the way I use my device.
You don't need to use Google Talk or have a gmail address to use XMPP. It's just another implementation of an existing standard.
I don't think that I need handholding from a protocol to the extent that it saves me from putting their chat address in my address book. If I don't know it, I can text them and ask:)
I don't ask their home number to automatically give me their work number.
It seems all that iMessage really does is enable users to discover connectivity through an alternative means and enable communication through that means. There's no reason you couldn't use the same mechanism to discover a JID/XMPP ID.
Well said. Just like facetime vs video chatting apps. Facetime is a natural extension to the phone functionality, something everybody is familiar with and using on a daily basis already.
thats only because its the default app that apple uses third party developers test to see if users are interested, the creates their own version and makes it the default on their phones.
I am not super familiar with this, but I don't think you can use GTalk to send SMS to a regular phone number can you? With iMessage it's the same app as regular SMS on the iPhone, and it uses iMessage instead of SMS if both sides have it, otherwise it falls back to regular SMS, it's a seamless integration that many people aren't even aware of.
with google voice you can push it to sms, email or gvoice service accessible from phone or browser, and also falls back to sms if not using gvoice. With that being said I hope Google does unify gtalk and gvoice for a better experience between chat/sms/email
Your argument that Apple revolutionized text messaging is kind of flawed. Even if you ignore IM/XMPP clients (they're not the same), fact is, RIM did it first with BlackBerry Messenger (BBM).
With BBM, you get end-to-end messaging between BlackBerry phones, with no limitations on the lengths of messages. You get a typing notice, delivery notice, as well as a read notice. You can transfer files, pictures, and video between devices.
BBM is also very tightly integrated into the OS, more so than any other platform. It requires no set up on the part of the user, all they need to do is exchange PIN numbers with their friends. No signup, nothing, it just works. Moreover, it allows developers to incorporate into their own apps, so they can provide in-app chat capability, as well as app-to-app communication ability (e.g. a multiplayer game initiated with you and a BBM friend). What's even better is that if that friend doesn't have the particular app/game installed, you can invite them to download it. When you go to invite a friend to use the app with you, it will only show you BBM contacts with that app installed (i.e. BBM knows what apps your contacts have). It's a pretty powerful setup, especially when combined with push notifications. It is leagues ahead of what XMPP can provide. Just ask WhatsApp or Kik.
RIM misstep (amongst MANY) is that they didn't translate this to other devices. They have delayed BBM on the PlayBook while they updated their infrastructure to allow 1 user to use BBM on multiple devices with multiple PINs. They're fixed this a while ago, and will release it for BlackBerry 10. They also don't have a desktop client available for public use.
So while iMessage is definitely an improvement over SMS (pretty much anything is), it still has a lot of catching up to do to BBM. Old school BlackBerry OS is a pretty shitty system, but they did get BBM right. Apparently, it's going to be very improved for BlackBerry 10. Here's hoping it is.
Edit: Reading some other comments here, I realize that iMessage's "innovation" is that when you send a text message to a phone number, it checks to see if they use iMessage too, and sends it that way instead. While that's cool, it's by no means revolutionary. Furthermore, you're still shackled by the limitations of SMS messages. That can be good, can be bad. Finally, I'm unclear of what happens when you're on your Mac or iPad: do you iMessage someone using their phone number still? Is that the unique ID?
The main UUID for an iMessage account is your Apple ID email address, but each account on iMessage can be hooked up to multiple email addresses also. For example if your contact for someone has a phone number and email addresses it will check for the phone number, then check for the associated email addresses. On my mac I receive all my iMessages because I set my reply to address to be one of those email addresses on the phone/pad. And yes, you can iMessage someone to their phone number form your computer / iPad.
iMessage supports all of the end-to-end messaging features above, but doesn't support letting devs use the messaging function other than being able to send one-off messages with attached photos / movies in iOS. Apple has something more like Xbox Live for doing in-app voice chat / messages (GameKit).
Reply to your Edit: You can have a phone number and multiple email addresses associated with your iMessage account. It really is quite a great thing at scale that would be almost pointless as a startup.
for people that are pro apple - apple didn't revolutionize anything, there were plenty of third party apps and companies prior to imessage that were providing the same service along with being cross platform. Apple is actually cannibalizing those services that were providing a valuable service to their customers and now are cutting them out. This is nothing more than further attempt to lock in users into their ecosystem.
This is completely false. When i'm out at a bar and I meet a cool girl, she gives me her number. I type it into my phone and begin sending her a text. Instantly my [Send] button shifts from green to blue to indicate that she is an iMessage user. It's seamless. It falls back on SMS automatically if iMessage fails. Otherwise, it just works.
Having multiple platforms for messaging is silly. Absolutely silly. If I have an iPhone and so does my sister/mom/random-stranger what am I guaranteed that we both have in common? One single messaging app. I don't want to ask a random stranger if they've used X Y Z free messaging app, that doesn't fly.
The only difference, aside from having one app do sms and internet text messaging, is that if I don't have iMessage I have to buy an entire phone or computer to get it, while if you don't have gtalk or similar all you need to do is install one app and register an account should you not already have one.
With iMessage, I can talk to maybe one or two people that I know. With gTalk, I can and talk to them all, even those on iPhones.
iMessage is not revolutionary. If anything, it's a step backwards. We've had BBM as a vendor locked message system for many years already.
I can't see it as a step backwards when it provides great functionality to hundreds of millions of people. I doubt iMessage would be anyone's sole IM platform, and in fact the OSX client supports AIM XMPP as well, so it's really more of an enhancement (where available) for iOS users. Apple isn't really trying to solve problems for people who don't buy their products. At some point in the future I could see AIM and XMPP being added to the iOS client to be used as a fall-back in the same way SMS is used now. So eventually there may be one client that is basically a proxy to various other services and just sort of figures it all out for you.
>Having multiple platforms for messaging is silly.
so what if shes on windows or android or blackberry or not using a smartphone. It works seamlessly as well if you both are using the same app to text. Theres nothing revolutionary about it.
As someone else has pointed out, it's an irrelevant protocol until it's made an open protocol. This will join the pile with FaceTime, iBooks, etc, that exist merely to lock people into Apples 'garden'. People should want to use your platform, not be forced to remain there cause they have to. Provide an open protocol, and make people want to use your products because you have the best implementation of it.
I understand the technical issues at hand, and I don't want to dismiss them as being unimportant--because they are important. However, the majority (who are non-technical end users) simply don't care.
Security is great, and everyone wants to know that their text messages are as secure as possible. When it comes to iMessage, however, I've yet to meet a single regular user who counts improved security as a reason to use iMessage. Heck, none of them even think iMessage is more secure than a regular text message.
What do they use iMessage for? It tells you when someone read your text. It tells you when someone is responding. It sends faster than regular text messages and confirms that it's actually been sent. Even more importantly, it allows us to send international text messages for free. As a Canadian being charged $.35 per text to the US (even though US and Canadian numbers formats are identical), this means I don't need to reroute a Google Voice number through 3 numbers just to keep in touch with my US friends.
The selling point of iMessage has never been technical; it's been functional.
A lot of the people out there using iMessage don't even know it. Because it hooks in so transparently with text messaging, people who used to SMS between iPhones now iMessage between them and many don't even realize that anything has changed.
Among those who do know the difference, my experience is that by far the most common reason to use it is to avoid paying for text messages. (I'm in the US here, so it's common.) A secondary reason, but really secondary compared to that, is the fact that it works on other iDevices, not just iPhones.
Until I read these comments, it didn't even occur to me that security might be an advantage of iMessage. I think the number of people who use iMessage because of that is roughly zero.
Not really. iMessage can be used in a transparent way with non-compatible devices (it can just fallback to sms), and it merely loses its advantages. People won't care too much that it's closed, and will still use it. And it won't lock them. If their next phone isn't an iDevice, they will just go back to sms.
FaceTime doesn't fail merely because it's a closed protocol. It fails because it's a closed protocol and the application has no way to fallback to other networks in order to communicate with non-Apple people.
that exist merely to lock people into Apples 'garden'
You don't think providing good features to users or creating a competitive advantage has anything to do with it at all? I agree lock-in is part of the equation in large part because Apple doesn't care about other platforms but there are definitely many other reasons these things exist. When/If it's in their best interest to support other platforms they will. (iTunes for Windows, for example)
Yes, please. And if the protocol doesn't turn out to be too horrid to work with, this will allow interoperable implementations. The last thing we need is another messaging protocol that only works with one vendor's products.
However, FaceTime was supposed to be submitted to be made into a standard, but I haven't heard much about that, and with the percentage of time that FaceTime breaks for me, I'm guessing that it's a pretty nasty protocol and they're too embarrassed to follow through. Hopefully iMessage is better.
There's a rumor that FaceTime wasn't supposed to be a standard -- when Jobs announced on-stage that it was going to be, it (supposedly) surprised the FaceTime developers. http://zachholman.com/posts/steve-jobs-sometimes-lies/
This reminds me of the Mountain Lion/Gatekeeper announcement. We heard it second hand from John Gruber [1] so it's possible the facts got mixed up on the way, but developer IDs for Gatekeeper were supposed to be free. As it turns out, they require you to pay for the Mac developer programme to be able to sign your apps, just as you do for the App Store.
I can't help but get the feeling they deliberately make these false announcements to generate goodwill. The gatekeeper misinformation in particular seems to be extremely pervasive and it causes users to believe Apple is acting in everyone's interest: it improves security and is free for developers, right?
Of course, it could just be accidental. Which would strike me as odd for a company that so closely guards what it communicates.
If there is confusion it may have been from reading more into what Gruber wrote than was actually there.
The Gatekeeper certificates are free to registered developers, but I don't Apple ever suggested that you didn't have to be part of the Apple Developer Program.
Gruber explicitly stated that it was "free-of-charge" full stop, and a lot of people at the time chose to believe him over the information on the Apple website that said paid membership in the Apple developer program was required and the other reports correctly saying the same thing.
And this isn't good. But two points: 1. Your Telco doesn't advertise secure end-to-end encryption. 2. Cellular protocols are (relatively) hard to intercept /and/ interception is prevented by a whole bunch of FCC regulations. iMessage will happily use an insecure Wi-Fi access point.
Worrying about evesdropping is derailing your otherwise fine train of arguments.
Security against evesdropping comes down to one and only one factor: The evesdropper cannot distinguish the bytes transmitted by iMessage from a stream of random bytes.
This is a solved problem, and getting it right in practice comes down to the simple rule, "Don't try to implement a crypto scheme. Use an existing library."
That's so easy to do nowadays that Apple would have to be breathtakingly incompetent to get that aspect of the security equation wrong.
Do you mean "no, they do not have to be incompetent to get it wrong" or "I agree, but incompetency is the norm, so it would not surprise me if they erred there"?
Those aren't mutually exclusive. It's actually quite easy to get this stuff wrong (and I'd argue almost guaranteed that some part of it is wrong, although hopefully not a part that makes the whole thing fall apart).
To build something like iMessage, there's basically three discrete levels (this is a little "handwave-y", but I think conceptually accurate):
You have the underlying cryptographic primitives. This is what people spend hours arguing about on the internet, but is actually probably the least of what you should be worried about when designing a system that uses cryptography.
Any good system should be using sound primitives, but the primitives don't by themselves really do very much, so you need to combine them into something useable (and by you, I mean whoever wrote the library you're using, which hopefully is one that's been through a lot of analysis).
So now you've got a cryptographic system (which is composed of usually several primitives, hopefully all of which are sound); but even this system doesn't actually do what you need it to do, it's usually just a function you call to perform some operation as part of the larger thing you're building.
So for something like iMessage to be sound, Apple had to do the following (either explicitly, or implicitly based on what libraries they chose):
1.) Pick a bunch of primitives (which isn't hard, and if there turn out to be problems, a lot more things are screwed than just your application)
2.) Pick a library (which is a little more difficult, and security problems with libraries still get discovered all the time, but let's also assume that they did their homework and both chose and implemented sound ones)
3.) Write the actual application to be secure (which is surprisingly difficult to do right, even when you work for a company with a mountain of cash)
They most likely actually started with number 2 (which would have dictated number 1).
I would argue that the likelihood of vulnerabilities in number 3 is astronomically high (but again, hopefully not ones so severe as to render the system pointless), moderately high in number 2 (just look at how many vulnerabilities are still discovered in OpenSSL for example), and probably low in number 1 (which is the part they probably didn't even pick, as it's generally determined by the library).
iMessage isn't the most complicated piece of software ever written, but there's still a decent amount of functionality it provides, and you'd be surprised how easy it is to screw up systems that use certificates (again, not because of problems with the primitives).
Just to be absolutely clear: if Thomas Ptacek says this is a problem, then it's absolutely a serious concern and I was a complete idiot for saying it wasn't.
It's actually very easy to get this wrong. Especially on the key and trust management side. The crypto algorithms themselves are the simple bit provided you don't try to invent your own.
Rather, consider this post as a plea for help. iMessage is important. People use it.
If you have a problem with a closed service working only within a walled garden, maybe you should look at an actual open standard instead, like XMPP.
It may not have "end to end" encryption, but at least you get to know how it works and how secure it really is.
Nobody is forcing you to use Imessage. Apple may encourage you, by permissive defaults, yes. But nobody is forcing you to use it. It can be disabled. You can even buy a phone not made by Apple and avoid the problem all together.
I've always wondered if there are multiple levels of this.
We know of at least two: one reaches public court records. The other level we know about, for sure, is NSA level stuff, which remains secret forever as a matter of national security. Do others exist? For example it's possible an agency could use the information to gather internal investigation evidence, and keep that evidence dark only using it for further gathering of more traditional evidence. That way their techniques would remain secret.
Anyway, the technique of discovering government agency abilities through court records seems to be a vital part of our civilian rights that I don't see enough information about. If anyone knows anything about it and reads this, please share some info!
1. It's just a guess but I don't think many users care about iMessage's encryption. Cryptographers are the exception.
2. XMPP is not true peer-to-peer. If you are a fan of XMPP as a p2p "solution", and you're not the XMPP provider trying to make a buck offering this "service", then I would say you don't know enough about p2p.
3. If you really care about end-to-end cryptography the solutions exist. Working with the nacl library is not rocket science. It's a lot simpler than SSL/TLS. And I don't see any cryptographers cracking nacl anytime soon.
4. Decentralised and open platforms are not really tough if you keep things simple. But for most (but not all) designers of these systems that seems just about impossible. If it's not complex it's not worth their time.
The biggest challenge I see with good, easy cryptography and a decent, simple peer-to-peer platform for the general public is that you will have a huge PR problem from day 1. Because the only folks who will want to use the system will be troublemakers who attract the wrong kind of attention, and a handful of smart people, like cryptographers, who no one pays attention to.
iMessage is based around APNS, which, while proprietary, doesn't require a background process on the client. This is way better than XMPP, and also doesn't try to do things that are pointless on mobile, like maintaining "presence".
This doesn't really preclude things like federation, but it's a fundamentally different approach from XMPP (though bridges are possible -- see, for example, Verbs app, also see how buggy it is, and What's App, which apparently is pulling it off quite well). But bare XMPP doesn't really work that well.
How is maintaining presence useless on mobile? I like Google Talk on android ten times better then just plain sms for this very reason. Being able to know whether your friends have service, and then being able to know whether they are actively paying attention to their phones (online/away), is crazy useful when trying to communicate.
Because there's a single thing that makes presence useful, which is the device going off or to sleep, y'know, like a desktop computer in the nineties. There aren't many people who maintain their availability by hand, as that's just a pain.
A cell phone is always on, so depending on the solution, I'm either always "online," or always "away" with some single blips of "online". Me being "online" doesn't mean I'm really paying any attention, I just took out the phone for a second while my friend was in the toilet, or anything, and now I'm gone, but will still appear as green for some time.
What's App and iMessage solves this by replacing online with read receipts, and in case of WA, "last seen online" data. Much less pretense makes it way more informative.
What he probably meant is: You don't want your mobile to be notified about presence unless you open the client and look at your roster. Or if you set a trigger to be notified if someones presence reaches a certain state. When you control the server side both is possible with XMPP. You could use privacy lists XEP-0016 for that. You'd just have to make sure that the server sends the last presence when you enable presence notification after you disabled it while the client was not in the foreground.
Also a push-notification needs something on the client to react to it, be that a running normal or a background-process. Pull needs maybe an additional background-process and generally wastes more energy, but APNS can't be that much magic.
I think the power consumption advantages of APNS come from the fact that it's built into the OS and it's multiplexed, meaning that you only ever need one persistent connection/monitoring/etc. no matter what needs to listen. If you did XMPP directly, you'd need a separate background process and connection just for that, in addition to APNS. If you had two different apps doing this, then you'd need two processes and connections, etc.
You need only one process, and, furthermore it being push means it's possible to handle it with way more resources (you don't really have to maintain anything on the client, excluding the relatively rare situations when something important changes and you have to tell about that to the server).
I'm interrested to develop a new messaging system that truly provides end to end encryption and is as secure as possible. All that with an open source protocol. I would be glad to share the work with people sharing the same interest.
The protocol and several implementations (at least in C and in Java) are already there. It's called OTR (Off The Record) http://www.cypherpunks.ca/otr/ Not to confuse with a GTalk feature that has the same name.
It's built into the normal iPhone texting application and turned on by default. When my Mom texts another Apple user, iMessage will automatically route her message over the Internet. She doesn't have to approve this, and honestly, probably won't even know the difference.
How does your phone know that another phone has iMessage? Is it set up manually by the user or do phones lookup the phone number on Apple's servers? If the latter then would it be possible to reverse engineer this to test if any number was an iOS device?
Your phone number is associated with your Apple ID. So I'm guessing they just reverse lookup the number you're texting to determine if iMessage can be used. It can definitely be reserved engineered. Just text any number from an iOS device and see if it switches to iMessage. The only caveat is users can remove their phone number association with iMessage so you could never be 100% sure.
BBM messages are encrypted end-to-end. However, BBM messages sent through the BlackBerry Internet Services (BIS) network (i.e. via your carrier) are encrypted using a RIM possessed by RIM. That means, that if/when required, they can be subpoenaed and asked for those messages.
The same is not true for BBM messages sent via the BlackBerry Enterprise Server (BES). Those are also encrypted, but using a key possessed only by your company's IT department. That means that if someone wants to read you messages, they have to subpoena your company. RIM can't help them, at all.
I'm not sure what happens when a BlackBerry connected via BES sends a BBM to a person using BIS, or even another BES network. Either decryption and re-encryption occur, or it reverts back to using RIM's private key. But it would be safe to assume that BBM messages sent within your own company's BES network are safe and secure.
iMessage fails on the security front. I have received more than one message (via wifi) after I removed the SIM card from an iPhone. This would not have happened with SMS.
With iMessage, your account isn't (solely) linked to your SIM card. It cannot be, because iMessage also works on devices without SIM cards (iPod Touch, Mac).
I do not think you can claim it fails because it still works after removing the SIM card. You cannot claim that SMS fails on the security front because you can receive SMSes without logging in to iCloud, either.
Because I received messages that were not meant for me. I got this iPhone from someone who removed his SIM card from it. And then I received messages for him that should have been delivered to his phone (the phone he put his SIM-card in).
Under settings on the iPhone there's the option to completely wipe the phone. Before you give your phone to someone else you should do this. Otherwise you were still logged in to his iMessage account.
The security problem here is the person who gave you the phone thought removing the SIM erased all their personal data/accounts and it definitely does not.
Apple saw that the current SMS implementation was flawed in many ways and sought out to improve/replace it. For example, all of the carriers (at least in the US, with the exception of the underdog Sprint) charge an exorbitant amount of money just to send/receive text messages. I pay $20 per month for that ability. SMS also has a limit of 160 characters. It also only works via cellular, whereas iMessage works via data connection. This is awesome for me, as I live in the boonies where I don't always have a cell connection (but do have excellent wifi). Being able to reply from multiple devices is also nice. Let's not forget all of the little 'nice-to-haves' like knowing when a message has been delivered and/or read, knowing when the other party is replying, etc...
Alas, they did this because the carriers wouldn't. Prior to Apple releasing the iPhone, you couldn't buy a phone that didn't have some one-off UI, preloaded with garbage apps, etc... Apple forced the hand of the mobile industry with their iPhone (this is obvious to many, but concrete evidence exists inside of the Samsung vs. Apple court documents recently released)
Apple is now doing this again with iMessage. They took something that really needed revolutionizing, and did it. It began as something great for members of the Apple ecosystem. They used their users and platform to prove it, and it's been successful. I can communicate via my Mac, iPhone, and iPad in a (mostly) unified experience. So, I do agree and hope that this expands to a wider audience. That being said, it will be tough. An open consortium leads to all sorts of issues (ahem, Android) and sometimes having one chef in the kitchen yields the best overall experience for everyone (Apple).