5 ms·
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 I
by way66 13y ago
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"
- fhars 13y agoSubmitting credentials "only once to our server" is a classical fishing attack. There is no way for the user to verify what happen with them.
- Xylakant 13y agoSeriously, 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.
- objclxt 13y agoThe 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. http://www.theverge.com/2013/11/3/5061136/sunrise-calendar-app-hack-mongohq-database-buffer http://www.theverge.com/2013/11/3/5061136/sunrise-calendar-a...
- nathancahill 13y agoOuch.
- lockmovdwordptr 13y agoI guess they have done that for triggering a reset of the validity of the "apple token" that was compromised.
- aroch 13y agoIn fairness, changing your password also deactivates any login tockens associated with the old password.
- rismay 13y agoIf you delete the app, this won't remove the account from sunrise's system then?
- tannerc 13y agoThere is no way for app developers to know which users have deleted the app from their device.
- jhgg 13y agoNot 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]. [0] https://developer.apple.com/library/ios/documentation/NetworkingInternet/Conceptual/RemoteNotificationsPG/Chapters/CommunicatingWIthAPS.html#//apple_ref/doc/uid/TP40008194-CH101-SW3 https://developer.apple.com/library/ios/documentation/Networ...
- koudi 13y agoWhy not generate token on client and only submit that?
- obsim 13y agoCan you explain how it is possible to generate secure tokens? I can't find anything related to it from the iCloud documentations.
- philo23 13y agoI'm guessing, that they simulate an iCloud login and then store the cookie on their servers and then use that cookie to login in the future? But thinking about it, it's a CalDAV server which normally uses email + password to authenticate..
- Khaine 13y agoWhy don't you run your own caldav server instead of relying upon icloud?
- 10feet 13y agoPeople want access to their apple calendar, on all their devices.
- kevinpet 13y agoThey 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.
- weaksauce 13y agoIt's actually phishing. I bring it up because I see more than one commenter on this page that has it wrong.
- hayksaakian 13y agoit might be autocorrect changing phishing to fishing
- pflats 13y agoActually, as a poster mentioned above, Sunrise was compromised 3 months ago, and recommended all iCloud users change their passwords. http://www.theverge.com/2013/11/3/5061136/sunrise-calendar-app-hack-mongohq-database-buffer http://www.theverge.com/2013/11/3/5061136/sunrise-calendar-a...
- seandougall 13y agoHow 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.
- Angostura 13y agoUnfortunately, 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.
- edoloughlin 13y agoWe understand our users, they want a unified Sunrise experience everywhere, and so we can’t use a local API for that. Of course you can, but you need to do extra work to store and synchronise calenders.
- fpgeek 13y agoHow many users would understand the calendar integration hiccups because their iPhone didn't have data coverage or was off or ...?
- Moru 13y agoNot 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.
- lylejohnson 13y agoUnless 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.
- shadesandcolour 13y agoFantastical uses EventKit. As do many of the other calendar apps.
- aestra 13y agoIn 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.
- shadesandcolour 13y agoWhy 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.
- dragontamer 13y agoThink 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.
- frenchy 13y agoI 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.
- adamio 13y ago"We are a team of 7 people building a calendar with love & passion" Love and passion?
- dmur 13y agoLove and passion.