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.
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.
I'm an engineer an I didn't know you could use two accounts for different tasks on the same device. Just never thought about it, because why would I? Not a reasonable workaround, I agree.
if you set up an iOS device, it specifically asks you if you want have a single Apple ID or 2 ids ( one for iTunes/App Store and another one for iCloud/FaceTime/iMessage).
It's not even default behavior to use the same account. You are required to make an explicit decision during setup whether or not you want to use the same Apple ID for iCloud and the App Store.
I’m glad that you are able to understand that abstraction, but if I'm being honest, how Apple handles accounts gets way over my head — and anyone around me is baffled by it too.
I cannot even find any guidance from Apple on recommended patterns for which Apple IDs should be shared, which should be individual, and so on. This isn't even a configuration option, it's a hack that happens to work. (And there's no guarantee that Apple won't change their model tomorrow, since they've never given any guidance on what those multiple AppleIDs are supposed to mean.)
That doesn't really seem to transfer existing app purchases between accounts (so updates continue to work etc). It also doesn't mention moving documents&settings&calendars from one icloud to another?
You can even use multiple accounts on a single iOS device to purchase stuff. So you can "share" apps with someone by logging in as yourself and then downlading the app.
In iOS 7, you do it under Settings/iTunes & App Store; tap "Apple ID: [whatever]" and choose "Sign out", and once signed out you'll be presented with options both to sign in under an existing Apple ID, and to create a new one. (I didn't actually do so, so there could possibly be a hoop or two to jump through which I didn't see, but I tend to doubt that.)
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.
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.
Yeah, I'm not sure what exactly that is trying to justify but off the top of my head I can think of about 1/2 dozen different ways to tie rich media to the calendar entry. iCloud and EventKit have their issues but this just seems way wonky to me.
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.
Not true. What probably happened was that your Google Play account was tied to your mobile (i.e. Verizon) account, so charges made in Google Play was pushed to Verizon, who then pushed those charges to you. T-Mobile used to do that, and I needed no credit card, until about two years ago, when one was needed because T-Mobile or Google no longer wanted to do business that way.
>> First of all this has nothing to do with iOS/Android...
I know it's not. I was just hinting the plus sides of a competitive product, something the new users should know, and something Apple should learn from. It's less about the app, and more about what the app is allowed to do, yet.
>> This is untrue.
No, it's not. You mean Google asked you to setup a "Merchant" account for being a "customer" of $0 apps? ... Think again. :)
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)
That's actually a great idea, and it wouldn't be hard at all, as long as they were to use TFA for all iCloud access. The second factor (e.g. a 6-digit number) could be displayed in the dialogue box asking for your password.
If it's a genuine dialogue box, no problem. If it's _not_ a genuine dialogue box, then the captured username/password is of no use, as you don't have the second factor. Replay and MITM attacks could be avoided by using a session identifier; the app wouldn't be able to get at it due to the sandbox.
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.
What point are you even trying to make? You trust the app for the same reasons you trust a web site you put your credit card number into, or the card reader that the cashier uses at the local business down the street.
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.
That sounds right. Although since I haven't entered my security question directly in that app, I was not asked to update them from any other App.
It just felt weird that a non Apple app suddenly asked for these things. I do use Find my Friends semi regularly in which you also login with your appleid password but so far there was never a message saying I needed to enter my security questions... weird.
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 know this is older but just in case some one experienced the same thing, the above mentioned is true.
I experienced this on iTunes on my PC quite a while ago. And since then I have not made any purchases from the iOS device itself. I buy through the PC and then sync to my devices because of slow internet.
So now, basically when I tried to make an IAP, I got the same popup. I first thought it was the app that wanted to know my details but it really is Apple. I got this out of the way by purchasing a small, 99ct app directly from my Device. So I went into the AppStore, bought the app and the same popup came up. Since this was now in the official Apple Appstore app, I answered two of my questions, downloaded the app and now, this popup is gone and I can make IAP all I like.
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?
"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"