4 ms·
It's not hijacking a protocol - it's hijacking a client for the protocol. Most users were likely not aware that when they open iMessage (the default SMS applica
by robmccoll 5y ago
It's not hijacking a protocol - it's hijacking a client for the protocol. Most users were likely not aware that when they open iMessage (the default SMS application) on their brand new iPhone and send a message to another user by phone number that the application is actually choosing between routing that message via iMessage through Apple's backend or via SMS over their carrier's network.
To me this would be similar to me operating as a browser vendor and having my own CDN that implements a separate protocol from HTTP, provides additional features beyond what HTTP can do, and displays a different color of banner to indicate that the website you are using is coming over my CDN. Then I don't allow arbitrarily anyone to implement my CDN protocol or connect to my CDN, so other browser vendors can't provide a competitive experience. Later when I have built a large marketshare, I decide that I'm good with HTTP 1.1 or whatever version of HTTP at the time and stop upgrading my implementation of that protocol. This is damaging to the other browser vendors and of users of websites that only support HTTP. Obviously this is an imperfect analogy given the client-server nature of HTTP, but I figured this might resonate with this audience.
- tatersolid 5y agoHa! The “own CDN with custom protocol” is exactly what Google did with AMP. They even prevented sites that wouldn’t let Google hijack their sites from appearing atop the search results!
- partiallypro 5y agoThis is exactly what I'm trying to say. To me it would be like if back in the day mIRC rerouted IRC traffic between fellow mIRC users into a proprietary protocol when everyone believes they are just using IRC and treated non-mIRC users differently and even degraded their service. There used to be bots/add-ons etc but nothing ever skipped over the original IRC protocol. To me that is akin to hijacking.
- Melatonic 5y agoGoogle is doing the same thing with RCS though and Google Messages. Android to Android it goes through googles special sauce RCS e2e. Anyone else it falls back to SMS
- SllX 5y ago> It's not hijacking a protocol - it's hijacking a client for the protocol. I don’t know what to make of your analogy, it’s one of those “if facts were different then thing would be different” sorts of things, so just go ahead and read your first sentence. A literal reading reads as Apple hijacking software they wrote and own the source code to… to support an additional protocol. It’s now been just over 10 years since iMessages was released into the wild as a feature of the Messages app and society has pretty well gotten used to it. Would you be happier if they were two apps, one called Messages and with an inferior communications channel and the other with blue bubbles called iMessages supporting all the iMessage features of today? Android had that feature 10 years ago or more. It sucked before you could change the default SMS messenger to Hangouts or something else, and once you did, Hangouts experientially worked the same as Messages does post-iMessages.
- robmccoll 5y agoNot sure what to make of your "if facts were different, then things would be different" - I still think the analogy holds up ok. You could say that things have changed as users have become more aware of the difference over the years, but honestly, if your initial expectation was the default message application on my phone does what I have known as texting (which is/was SMS/MMS) which is a part of my phone plan that I pay my provider for and then you start doing something wholly different with that communication, I would consider that some sort of hijacking. You have seized my action and intention and redirected it to serve your own purpose. Optimally? Switch over to an RCS implementation. If existing rollouts of RCS don't support enough of a feature set to please you (looking at E2EE), push to get that done. Don't go the Google route and end up choosing "collaborating is hard, so let's just not do it". If Apple won't do that, drop SMS from iMessages and open the protocol or at least force users to choose or acknowledge the choice. Auto-negotiating a protocol choice makes sense when you are going from one open standards-based protocol that any vendor could and should implement to a newer version of that protocol with the same expectation of general availability (think the path through the versions of SSL and TLS). It's disingenuous to automatically shift traffic and offer enhanced features through a proprietary protocol when communicating with clients that only implement and can only implement the open protocol. It makes it seem like the other clients are intentionally inferior or otherwise making user-hostile choices. It's good for business though. With respect to Android, that's its own slew of problems and mistakes that shouldn't be the bar Apple needs to clear. iMessage and Facetime are easily better than any communications implementation Google has produced in the last 10 years. Hangouts and its various precursors were better when they were based on XMPP or had functioning XMPP gateways. XMPP wasn't an standard intended to replace or progress SMS, so that doesn't really meet my criteria either. RCS is the way forward, but there's little demand for it or business reason for it in the Apple camp. Maybe if carriers declared that they are going to start taking RCS seriously and start removing SMS from plans and charging more for it.