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 [email protected]"
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.
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.
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.
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.
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.
I wonder if the reason why they are asking for AppleID and password is because that's the only way they found to overcome the iCloud integration problem described back in April/2013
Every other calendar app seems to do it, what’s taking Sunrise so long?
To explain let’s breakdown a calendar app into two parts, the presentation layer and the storage layer. In the stock iOS Calendar app, Calendar is the presentation layer and EventKit is the storage layer, both developed by Apple. Other calendar apps in the App Store also follow this two layer design but only redevelop the presentation layer while continuing to use Apple’s EventKit storage layer. In other words, these apps quite literally take your data and dress it up in a different color. What we do at Sunrise is redevelop both the presentation layer and the storage layer.
You guys are crazy, why bother reinventing EventKit?
The storage layer is responsible for keeping your data in a structured format. If we were to use Apple’s EventKit storage layer, we would have no control over what can be stored and how to store it.
Okay, so what’s wrong with not having control over the storage layer?
The storage layer needs to be revolutionized. Why can’t my calendar store anything besides text? What if I wanted to attach a picture to an event? Better yet, why not a video? What about other rich media that I would want to be included?
Herein lies the problem, the current storage layer isn’t capable of storing anything other than basic data. Not only that, it only stores certain kinds of basic data: titles, descriptions, dates, etc. We want to break these barriers and let you store anything!
Revolutionary features are coming to your calendar. We’re working as fast as we can.
The only stated way they're going to 'revolutionise' calendar storage is by adding rich media? You can hack on EventKit for that - just used the notes or URL properties on EKCalendarItem.
I would guess that if they had another way to access your iCloud calendar from their servers they would. Apple unfortunately has everything linked to a single account without any sort of Oauth. This is more an issue with iCloud than it is with iTunes or the App Store.
iClouds PIM stuff uses DAV for syncing. In theory they could issue separate credentials to handle PIM syncing, and keep it all transparent to the user: have an API that devs can use to request a token, or something, from Apple to access DAV, when a request is authenticated through an OS native dialog (only going through apples servers and your device) -- keeping actual iCloud credentials away from the app itself.
Admittedly, Android does it much better by providing oAuth, an easy way to get the users sign in, and of course APIs for almost all the popular features. And also, for installing $0 apps you don't need any credit card details at all. Even the buttons are different "Install" v/s "Buy".
>> Admittedly, Android does it much better by providing oAuth, an easy way to get the users sign in, and of course APIs for almost all the popular features.
First of all this has nothing to do with iOS/Android. This is an app trying to access a web service. Apple needs to provide oath or similar for accessing their iCloud services.
>> And also, for installing $0 apps you don't need any credit card details at all. Even the buttons are different "Install" v/s "Buy".
This is untrue. I couldn't download any free apps until I had setup a merchant account with credit card.
I would guess that most iOS users think that the confirmation message for in-app purchases (prompting you for your iCloud credentials) is from the app from which they initiated the purchase, rather than from a system service.
This probably conditions them to trust all iOS apps with their password if prompted to enter it.
Which is precisely why the thing this article is pointing out is extremely terrible - Apple should have made it a rule a long time ago that no 3rd party app can ask for Apple ID credentials.
But they dug themselves in a ditch by unifying extremely sensitive things (App Store access) & very sensitive things (email, calendar) under a single account.
A few ways to get out of that ditch:
- not allowing any iOS/Mac app store 3rd party app to ask for iCloud credentials. This will suck but at least protects the average Joe.
- forcing users to have a different password for the app store/anything that can take money from a credit card.
- using something like OAuth.
- use two step verification for app store purchases (of course, the mobile app store being on a phone makes it harder)
They can't win, can they? I'm sure if they did exactly what he suggests a long, long time ago we'd be hearing how evil they are for not allowing calendar apps to work properly on the store.
Nobody is calling anybody evil. Developers may complain that there is no server-side API for an iOS user's calendar but it's still crazy that Apple allows and promotes an app that normalises an extremely dangerous practice.
IAP is required for virtual goods used within the app. It's fine to ask for a credit card number to purchase physical goods and services. That's why Apple hasn't shut down Uber and Square.
Okay, I have a question. AppleID and pw non-withstanding, I have experienced the following. I played Where's my water2 recently and came to the end where you have to pay to get additional levels. No biggie, I did this with the first game as well. But, when I clicked the in app purchase and entered my password I was prompted with a pop saying I needed to answer my 3 security questions next. Of course I hit cancel and not okay right there.
I have never seen that an app requests the security questions when making an in app purchase. Granted it's been a while since I last made one. Can anyone tell me if this is supposed to be normal now?
I tried to talk to Disney's support but of course no answer there...
I had the same request from inside one of Apple's apps. I think Apple just want you to update your security questions. I logged into the AppleID site, appleid.apple.com, and updated the questions there. Relaunched the app and no more questions.
I think you get 3 or 4 tries before they lock your account, I had gotten 1 question wrong 2x an didn't want the account locked because of a typo.
It seems Apple is keen to push the 3 security question setup after a while on app store interactions, it's probably just unfortunate that it appeared during an in-app purchase interaction.
I don't have a huge beef with this, though. I am assuming that Apple has vetted the company and the app already through their normal process of allowing the app in the app store. Am I being overly trusting?
[+] [-] way66|12 years ago|reply
"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]"
[+] [-] objclxt|12 years ago|reply
http://www.theverge.com/2013/11/3/5061136/sunrise-calendar-a...
[+] [-] kevinpet|12 years ago|reply
Sunrise doesn't have a (known) security problem. Sunrise happened to reveal a glaring problem with Apple's security policies.
[+] [-] aestra|12 years ago|reply
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.
[+] [-] Angostura|12 years ago|reply
[+] [-] fhars|12 years ago|reply
[+] [-] edoloughlin|12 years ago|reply
Of course you can, but you need to do extra work to store and synchronise calenders.
[+] [-] Khaine|12 years ago|reply
[+] [-] koudi|12 years ago|reply
[+] [-] obsim|12 years ago|reply
[+] [-] Moru|12 years ago|reply
[+] [-] adamio|12 years ago|reply
Love and passion?
[+] [-] msantos|12 years ago|reply
From http://sunrise-product.tumblr.com/post/47802736454/why-doesn...
Why doesn’t Sunrise support iCloud/Exchange yet?
Every other calendar app seems to do it, what’s taking Sunrise so long?
To explain let’s breakdown a calendar app into two parts, the presentation layer and the storage layer. In the stock iOS Calendar app, Calendar is the presentation layer and EventKit is the storage layer, both developed by Apple. Other calendar apps in the App Store also follow this two layer design but only redevelop the presentation layer while continuing to use Apple’s EventKit storage layer. In other words, these apps quite literally take your data and dress it up in a different color. What we do at Sunrise is redevelop both the presentation layer and the storage layer.
You guys are crazy, why bother reinventing EventKit?
The storage layer is responsible for keeping your data in a structured format. If we were to use Apple’s EventKit storage layer, we would have no control over what can be stored and how to store it.
Okay, so what’s wrong with not having control over the storage layer?
The storage layer needs to be revolutionized. Why can’t my calendar store anything besides text? What if I wanted to attach a picture to an event? Better yet, why not a video? What about other rich media that I would want to be included?
Herein lies the problem, the current storage layer isn’t capable of storing anything other than basic data. Not only that, it only stores certain kinds of basic data: titles, descriptions, dates, etc. We want to break these barriers and let you store anything!
Revolutionary features are coming to your calendar. We’re working as fast as we can.
[+] [-] coob|12 years ago|reply
Sorry, they're not getting my credentials.
[+] [-] pat2man|12 years ago|reply
[+] [-] 0x0|12 years ago|reply
[+] [-] girvo|12 years ago|reply
[+] [-] piyush_soni|12 years ago|reply
[+] [-] k-mcgrady|12 years ago|reply
First of all this has nothing to do with iOS/Android. This is an app trying to access a web service. Apple needs to provide oath or similar for accessing their iCloud services.
>> And also, for installing $0 apps you don't need any credit card details at all. Even the buttons are different "Install" v/s "Buy".
This is untrue. I couldn't download any free apps until I had setup a merchant account with credit card.
[+] [-] adnrw|12 years ago|reply
[+] [-] rahimnathwani|12 years ago|reply
This probably conditions them to trust all iOS apps with their password if prompted to enter it.
[+] [-] GuiA|12 years ago|reply
But they dug themselves in a ditch by unifying extremely sensitive things (App Store access) & very sensitive things (email, calendar) under a single account.
A few ways to get out of that ditch:
- not allowing any iOS/Mac app store 3rd party app to ask for iCloud credentials. This will suck but at least protects the average Joe.
- forcing users to have a different password for the app store/anything that can take money from a credit card.
- using something like OAuth.
- use two step verification for app store purchases (of course, the mobile app store being on a phone makes it harder)
[+] [-] Touche|12 years ago|reply
[+] [-] barumrho|12 years ago|reply
[+] [-] msantos|12 years ago|reply
And as for "to offer a Sunrise experience everywhere, on all platforms", but at what cost?
[+] [-] zw|12 years ago|reply
[+] [-] po|12 years ago|reply
[+] [-] FigBug|12 years ago|reply
[+] [-] cmelbye|12 years ago|reply
[+] [-] schappim|12 years ago|reply
[+] [-] supercoder|12 years ago|reply
If I ask for your gmail user / pass is that fine because there's no API ?
[+] [-] rsynnott|12 years ago|reply
[+] [-] robmcm|12 years ago|reply
[+] [-] yaeger|12 years ago|reply
I have never seen that an app requests the security questions when making an in app purchase. Granted it's been a while since I last made one. Can anyone tell me if this is supposed to be normal now?
I tried to talk to Disney's support but of course no answer there...
[+] [-] yardie|12 years ago|reply
I think you get 3 or 4 tries before they lock your account, I had gotten 1 question wrong 2x an didn't want the account locked because of a typo.
[+] [-] 0x0|12 years ago|reply
[+] [-] smackfu|12 years ago|reply
http://imgur.com/xK4Hmy2
[+] [-] unknown|12 years ago|reply
[deleted]
[+] [-] bhartzer|12 years ago|reply
[+] [-] piyush_soni|12 years ago|reply