http://www.theverge.com/2013/11/3/5061136/sunrise-calendar-a...
[0] https://developer.apple.com/library/ios/documentation/Networ...
Sunrise doesn't have a (known) security problem. Sunrise happened to reveal a glaring problem with Apple's security policies.
http://www.theverge.com/2013/11/3/5061136/sunrise-calendar-a...
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.
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.
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.
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.
Of course you can, but you need to do extra work to store and synchronise calenders.
But thinking about it, it's a CalDAV server which normally uses email + password to authenticate..
"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 [email protected]"