Hey everybody, Pierre from @sunrise.
This is the blog post we've just published to give more context:
"Users sometimes ask us why we require the user’s Apple ID and password in Sunrise, instead of using the local Calendar API. That’s a great question to ask, and we understand why users don’t want to share their credentials without context. We’ve thought a lot about that.
The two reasons why we are doing this are:
- one, to provide a better user-experience
- two, to offer a Sunrise experience everywhere, on all platforms (including web and Android)
Providing a better user-experience
Being able to access the data from our servers, instead of just client-side, has enabled us to write a better calendar app. We are working hard to make synchronization faster and more reliable, and it enables us to send push notifications or alerts to users without them having to open the app.
And this is just the beginning, a lot of new features that we are working on at Sunrise for the future will rely on our server-side infrastructure.
Sunrise everywhere
The two biggest feature requests we get from users are: “when is Sunrise going to launch on desktop” and “what about Android?”.
We understand our users, they want a unified Sunrise experience everywhere, and so we can’t use a local API for that.
How does it work? Is this secure?
When you type in your iCloud credentials, they are sent to our server only once in a secured way over SSL. We use them to generate a secure token from Apple. This secure token is the only thing we store on our servers, we never store your actual iCloud credentials.
What’s next?
In the future, we are thinking about ways to take advantage of the local Calendar API for users who don’t want to share their credentials, we understand their point of view.
We are also hoping that Apple will leverage OAuth to authenticate their calendar API, which will make things easier for everyone. We already support OAuth with Facebook, Google, Twitter, LinkedIn, Foursquare and Producteev. We support OAuth where we can.
We are a team of 7 people building a calendar with love & passion, and unfortunately we can’t always move as fast as we want, but as always, we want to address users’ issues with transparency and openness. We’re listening on @sunrise or support@sunrise.am"
The one rather glaring fly in your ointment is that if your system was as secure as you make it out to be you wouldn't have been asking users to change their iCloud passwords after your database was compromised a few months ago.
Not exactly true. If you send a push notification to a device using a token of an app that isn't installed anymore, the feedback service will let you know that the app isn't installed on the device anymore[0].
They should have rejected your app until they had an Oauth solution in place. That's the right answer to avoid training Apple users to be fishing targets.
Sunrise doesn't have a (known) security problem. Sunrise happened to reveal a glaring problem with Apple's security policies.
How would OAuth help? The problem is training users that it's okay to enter their username and password into any schmuck's app... which is exactly what they'd be doing with OAuth. OAuth and its ilk are neat ways for honest app developers to avoid touching user credentials, and therefore (presumably) would have been a better solution for Sunrise, but they offer no protection against phishing in a native app.
Of course, OS X Authorization Services prompts for keychain access with a standard dialog that just pinky-swears it comes with the OS's blessing, so maybe Apple's approval of this practice shouldn't come as such a surprise.
In your giant ad you missed the point so much it hurts.
You are asking sensitive user names and passwords you have no right to have. Just because you don’t do anything bad with them (that you say - and not yet) means nothing. You shouldn't be asking for them. Phishing attacks do exactly the same thing you do. You are not special, your users shouldn't trust you with their appleid and password anymore than any other spam email they get.
Why does the application that accesses your calendar not have the right to the credentials for those calendars. Does my email application all of a sudden no longer have the right to my email credentials.
The issue here is not that Sunrise asks for your iCloud credentials, which it needs to be able to access your iCloud data, which you as a user of their service have given them the right to. The problem is that those same credentials are tied to your iTunes account and your credit card.
Think cloud based. OAuth, if implemented by Apple, would have APPLE asking the users for their username / password combination. APPLE then tells Sunrise that the username / password is valid. There is no reason why Sunrise should ask for the username / password.
OAuth and even older, Paypal, use this methodology. It is a shared deficiency between Sunrise and Apple that they don't have a better way of performing user authentication.
-----------------
Your email application is a null / void example. Email applications run on your own computer. What is going on here is that Sunrise is collecting usernames / passwords on their own server, and promising that they won't do anything wrong with them. Whether or not we should trust them is beside the point, their approach to security is terrible.
I don't think anyone would disagree that OAuth is a far, far better solution. But there's not really anything Sunrise can do to make Apple implement OAuth.
Unfortunately, you are asking your users to engage in an inherently unsafe behaviour. Even if your implementation is rock solid, users shouldn't get used to supplying AppleID credentials to random applications.
Seriously, there's no way for the user to verify what happens with them even if they don't send them to the server and generate the token in the app. They could still just encrypt them and hide them in the requests they send to their servers to retrieve calendar data. It's fundamentally a matter of trust, made worse by the fact that apple obviously doesn't offer oauth or a similar mechanism.
Not to play doomsday profet but:
Apple does not want you to be able to use some other application to access data that apple is already having an application for. So expect to be shut down when apple finally realizes what your app is for.
Unless I'm misunderstanding your point, you seem to be ignoring the numerous third-party calendar iOS apps that access and manipulate your calendar. I'm using one called Fantastical, but there are many others.
"Users sometimes ask us why we require the user’s Apple ID and password in Sunrise, instead of using the local Calendar API. That’s a great question to ask, and we understand why users don’t want to share their credentials without context. We’ve thought a lot about that.
The two reasons why we are doing this are: - one, to provide a better user-experience - two, to offer a Sunrise experience everywhere, on all platforms (including web and Android)
Providing a better user-experience
Being able to access the data from our servers, instead of just client-side, has enabled us to write a better calendar app. We are working hard to make synchronization faster and more reliable, and it enables us to send push notifications or alerts to users without them having to open the app.
And this is just the beginning, a lot of new features that we are working on at Sunrise for the future will rely on our server-side infrastructure.
Sunrise everywhere
The two biggest feature requests we get from users are: “when is Sunrise going to launch on desktop” and “what about Android?”.
We understand our users, they want a unified Sunrise experience everywhere, and so we can’t use a local API for that.
How does it work? Is this secure?
When you type in your iCloud credentials, they are sent to our server only once in a secured way over SSL. We use them to generate a secure token from Apple. This secure token is the only thing we store on our servers, we never store your actual iCloud credentials.
What’s next?
In the future, we are thinking about ways to take advantage of the local Calendar API for users who don’t want to share their credentials, we understand their point of view.
We are also hoping that Apple will leverage OAuth to authenticate their calendar API, which will make things easier for everyone. We already support OAuth with Facebook, Google, Twitter, LinkedIn, Foursquare and Producteev. We support OAuth where we can.
We are a team of 7 people building a calendar with love & passion, and unfortunately we can’t always move as fast as we want, but as always, we want to address users’ issues with transparency and openness. We’re listening on @sunrise or support@sunrise.am"