4 ms·

There's an interesting part in the linked article, including a reference to HN: He found that iMessage Chat for Android essentially inserted itself into the mi

by chmars 13y ago

There's an interesting part in the linked article, including a reference to HN: He found that iMessage Chat for Android essentially inserted itself into the middle of the normal back-and-forth between a user and Apple's iMessage servers. In a thread on Hacker News [https://news.ycombinator.com/item?id=6435902 https://news.ycombinator.com/item?id=6435902], Freeman spelled out his findings. At least on iOS, the man-in-the-middle part would not seem unusual: As far as I know, messaging apps that want to be available to the user all the time, need the user credentials in order to keep the users online since there is no way on iOS for an app to reliably run all the time. And such messaging apps use the user credentials on their own server(s) to keep the users online and reachable. If the app is no longer running and a new message arrives, the server sends a notification to iOS and the user can open the app if he wants to read the new message. A major difference is of course that the iMessage user credentials are (cannot be?) used only for messaging.

saurik 13y ago
You seem to have everything backwards, which makes me question whether you read the actual comment as opposed to just attempting to guess at things from the snippet :(. What you said would make some sense if the client connected to someone in the middle who then connected to the server. Instead, the client connects to the server, but when data comes back it is forwarded to someone in the "middle" (really, off to the side) who then processes it and returns results to forward back to the server. In essence, the device is in the middle of a connection from the developer to the service, as opposed to the developer being in the middle of a connection from the device to the service. In such a configuration you are not getting any of the benefits you are talking about, as if the device isn't online it won't be able to maintain the connection on behalf of the developer's server. (Also, I must point out the normal situation with such messaging apps on iOS is that you get them from the service itself. In addition to being less common on Android, it is thereby interesting to point out to people who might not realize the app is implemented in this weird way--some people who even analyzed it assumed this was a side-channel for analytics--so they can make the right call for themselves.)
- perlpimp 13y ago
  Thats how jabber works afaik having a network of domains and each domain can have a set of transports to connect to various non-jabber networks, this might as well be a proprietary implementation of transport and private service. Anytime something might smell like a certain lawsuit you bet you will be on the short end of the stick - with corporations.1
- lnanek2 13y ago
  This is very standard with web scraping implementations. Honestly, if you are reversing someone's protocol or scraping their web site, you are stupid if you put the implementation on the client because it will break all the time. Instead you put it on a server where you can fix breaks instantly. The server usually delays/shows stale data while things are broken as well, then does what it can to replay once fixed.
  - elyase 13y ago
    On the other hand putting things on the server means that you can get cut (by IP) and also brings the need of dealing with scaling problems.
    - toomuchtodo 13y ago
      You can always scale easier on the server platform, as well as spin up new instances with new IPs on any VM platform. Handling it on the server allows you some control over the chaos. Not so much when all the logic is on your mobile app.
      - marcc 13y ago
        You aren't suggesting that it scales easier on the server than on the mobile client, are you? Nothing would scale better for this app than putting the logic on the client -- it's a customer's phone communication with an Apple server. This leaves nothing for him to scale, anywhere, except for engineering to push out updates.

by chmars 13y ago

saurik 13y ago

You seem to have everything backwards, which makes me question whether you read the actual comment as opposed to just attempting to guess at things from the snippet :(. What you said would make some sense if the client connected to someone in the middle who then connected to the server. Instead, the client connects to the server, but when data comes back it is forwarded to someone in the "middle" (really, off to the side) who then processes it and returns results to forward back to the server. In essence, the device is in the middle of a connection from the developer to the service, as opposed to the developer being in the middle of a connection from the device to the service. In such a configuration you are not getting any of the benefits you are talking about, as if the device isn't online it won't be able to maintain the connection on behalf of the developer's server. (Also, I must point out the normal situation with such messaging apps on iOS is that you get them from the service itself. In addition to being less common on Android, it is thereby interesting to point out to people who might not realize the app is implemented in this weird way--some people who even analyzed it assumed this was a side-channel for analytics--so they can make the right call for themselves.)

perlpimp 13y ago
Thats how jabber works afaik having a network of domains and each domain can have a set of transports to connect to various non-jabber networks, this might as well be a proprietary implementation of transport and private service. Anytime something might smell like a certain lawsuit you bet you will be on the short end of the stick - with corporations.1
lnanek2 13y ago
This is very standard with web scraping implementations. Honestly, if you are reversing someone's protocol or scraping their web site, you are stupid if you put the implementation on the client because it will break all the time. Instead you put it on a server where you can fix breaks instantly. The server usually delays/shows stale data while things are broken as well, then does what it can to replay once fixed.
- elyase 13y ago
  On the other hand putting things on the server means that you can get cut (by IP) and also brings the need of dealing with scaling problems.
  - toomuchtodo 13y ago
    You can always scale easier on the server platform, as well as spin up new instances with new IPs on any VM platform. Handling it on the server allows you some control over the chaos. Not so much when all the logic is on your mobile app.
    - marcc 13y ago
      You aren't suggesting that it scales easier on the server than on the mobile client, are you? Nothing would scale better for this app than putting the logic on the client -- it's a customer's phone communication with an Apple server. This leaves nothing for him to scale, anywhere, except for engineering to push out updates.