Sparrow Mail's petition to let them safely deliver push email to iOS(sparrowmailapp.com)
sparrowmailapp.com
Sparrow Mail's petition to let them safely deliver push email to iOS
http://sparrowmailapp.com/push.php
8 comments
Copied my response =)
If there was a way for them to get some sort of useless "token" to get the notifications themselves and pass them to Apple, I don't think the security issues would be anywhere near as severe (especially if it was an opt-in service).
Good point, that would be a much better solution. All they'd need is a web hook to let them know when there is new email for an account. They could use that to send a push notification with the correct badge count for unread messages.
That's what we should really be petitioning for.
If there was a way for them to get some sort of useless "token" to get the notifications themselves and pass them to Apple, I don't think the security issues would be anywhere near as severe (especially if it was an opt-in service).
Good point, that would be a much better solution. All they'd need is a web hook to let them know when there is new email for an account. They could use that to send a push notification with the correct badge count for unread messages.
That's what we should really be petitioning for.
You could get users to give you a read-only OAuth token for their GMail inbox, which is an extra step (although you can do it for them on the device where you have the username and password, and then send just the token to your server.) Then your server can do the polling and push to the iPhone via an approved technique.
https://developers.google.com/google-apps/gmail/#gmail_inbox... gives some details. Contrary to what it says there, it seems to work for gmail.com and google apps addresses.
https://developers.google.com/google-apps/gmail/#gmail_inbox... gives some details. Contrary to what it says there, it seems to work for gmail.com and google apps addresses.
Sparrow seems to be going down the wrong path. They say they don't have server side expertise so they are promoting a solution that the iPhone clearly isn't meant for.
Simple solution, hire someone who understands secure backend infrastructure, wire up the push notifications, and charge a small monthly fee for the service. If they could convert a small percentage of their user base, they'd make their investment back and more.
Simple solution, hire someone who understands secure backend infrastructure, wire up the push notifications, and charge a small monthly fee for the service. If they could convert a small percentage of their user base, they'd make their investment back and more.
I disagree here. The iPhone already supports this functionality for VoIP applications: they maintain a persistent TCP connection in the background and when you get a call the app is activated again.
The way email push works (IMAP IDLE) is the same: the client opens a TCP connection to the server which remains idle and the server 'pushes' data over that connection.
I think it's reasonable to ask for the same functionality for a different purpose.
The way email push works (IMAP IDLE) is the same: the client opens a TCP connection to the server which remains idle and the server 'pushes' data over that connection.
I think it's reasonable to ask for the same functionality for a different purpose.
Actually, maybe there's a much easier solution: Integrate Sparrow iphone app directly with Boxcar notification. Plug my boxcar account in and they can handle the rest.
Non-programmer's question: Why is WhatsApp always able to push notifications and why is that different from Sparrow?
iOS push notifications are created on a server and then sent to the users iPhone. This means that the server must know about the event in order to generate the push notification that you see on your phone.
When you send a message from WhatsApp to your friend, the message is not sent directly from your phone to his. What actually happens is your message is sent to WhatApp's server, which then generate a push notification and sends it to your friends iPhone. (Push notifications must originate from a server. Your friends iPhone cannot check for new messages, instead it is told when there is a new message).
In Sparrows situation, they have no control over Gmail's server, and so they do not know when a new email is received and therefore cannot send a push notification to the users iPhone. Sparrow could store everyone's Gmail credentials on their own server and regularly check Gmail's server for new messages for each of their users and, if there are new messages, send a notification to the relevant user. However, this would mean that Sparrow would have to store everyone's Gmail credentials in one place which has certain security implications and, understandably, they do not want to do this.
When you send a message from WhatsApp to your friend, the message is not sent directly from your phone to his. What actually happens is your message is sent to WhatApp's server, which then generate a push notification and sends it to your friends iPhone. (Push notifications must originate from a server. Your friends iPhone cannot check for new messages, instead it is told when there is a new message).
In Sparrows situation, they have no control over Gmail's server, and so they do not know when a new email is received and therefore cannot send a push notification to the users iPhone. Sparrow could store everyone's Gmail credentials on their own server and regularly check Gmail's server for new messages for each of their users and, if there are new messages, send a notification to the relevant user. However, this would mean that Sparrow would have to store everyone's Gmail credentials in one place which has certain security implications and, understandably, they do not want to do this.
I think the issue here is that it isn't really "push" that Sparrow wants to do. From what I can tell, what they want to do is simply "run all the time so we can keep a connection open to receive new messages immediately". Which, to be fair, is pretty similar to what Apple does for their push notifications (including for Exchange).
However, Apple allowing this would be a bad move for the platform. It'd mean that rather than once centralized connection that knows about the device's network state and can (at least try to) preserve battery life or consolidate network usage, you'd then have as many as one per app, each always open, running code, and listening. (Once Sparrow does this, then why wouldn't any other app? It is much simpler to implement if allowed.)
The real issue here is that, from their responses, it seems that Google doesn't have some sort of authentication method like that could be used to get access to just enough information to pass the push data to Apple — or, at least, not one (like OAuth) that doesn't need them to remotely store a username and password. If there was a way for them to get some sort of useless "token" to get the notifications themselves and pass them to Apple, I don't think the security issues would be anywhere near as severe (especially if it was an opt-in service). But I don't know if Google does that, and their responses don't seem encouraging that something like this would be possible.