Sign In with Apple [video]
developer.apple.com
developer.apple.com
US competition laws are outdated with undue reliance on the concept of a monopoly.
I don't care if you're a monopoly or a third of the market or even a small company. If you run a marketplace or app store or similar platform, you should NOT be able to:
- Force usage of a separate product of yours over/with competitors (in this case, Apple sign-in, but also Apple Pay instead of Google Pay, etc.)
- Prevent competing products from appearing (whether Apple not allowing other browser rendering engines, Amazon not allowing Google Home or Chromecast to be sold, etc.)
- Rank your own items higher in search results etc. if competitors can't bid to do the same e.g. sponsored results for everyone including yourself (so Amazon Basics or Google Shopping needs to be listed as a sponsored result, not as a separate feature)
This is the kind of thing 21st-century legislation for fair competition should address.
We already seen the regulatory outreach coming to app stores when EU ruled that Google was hindering the distribution of Aptoide store for Android.
The Web?
I've seen reports that Apple is finally starting to fix issued related to adding PWAs to the home screen as well.
https://en.m.wikipedia.org/wiki/The_Antitrust_Paradox
Essentially, the book advocates that the only goal antitrust laws should have is to protect consumer welfare, not competitors.
IMO, Apple’s requirement doesn’t feel like it would harm consumer welfare.
Good job Apple, you raised your image only to crush it again with anticompetitive bullshit.
As someone who has never bought an Apple product, I can safely say their monopolistic practices don't affect me.
Stop buying Apple products. Its that simple.
The only thing you can do is educate consumers on the evils of Apple and hope they make better decisions in the future.
That's similar to what happened to Windows Phone. They opened up development towards the end since they could no longer justify forcing developers to behave the way they wanted; they simply didn't have the market share to enforce it.
Is it the market size that keeps you in the iOS space? Are you on other platforms? What are the revenue/cost/effort ratios for each? Does it make sense to focus on non-iOS options?
It’s ok to not like Apple or any company that doesn’t match your values, but it’s important to argue using the right terms and definitions, otherwise you sell yourself and your argue short.
There are alternatives to offering an app for iOS. Web apps are an example. Releasing only for Android is also a valid choice.
I don’t like paying for using a toll road, but if I want the benefit of a nice road, and a shorter travel time, I have to pay. If these benefits aren’t worth the price, I can use an alternative.
Curious, why not?
Because if i understand correctly it's designed so that Apple cannot see any of the data... So for what reason would you want to provide another third-party provider, but not Apple Signin?
To me it seems a huge win for consumers privacy wise, and Developers have nothing to loose.
not a win for privacy, but i'm sure there are some that would be unhappy about not getting the data the other providers are giving them.
I am tired of seeing my email address popping up on leaks and I don't want to rely on spam filters any more. The best spam filter out there is built into gmail, but they are no longer interested in actually preventing spam, instead they want to control it. Now Google shows me ads that look exactly like emails in my inbox, inside the iOS app.
I wasn't happy with this so I built https://idbloc.co, which is basically equivalent to the disposable email element of Sign in with Apple, now that Apple built it into their Sign In, I guess now it exists for users who don't want to or can't use Apple.
Personally, I'm fine with Apple having that kind of info as I generally trust them and also that my main concern is the same with your frustration of my email ending up in yet another leak seemingly frequently.
...up until Apple decides to change their leadership, or their business model, or the mobile market implodes and they start looking for new revenue streams, or their relationship with the US government changes, or ...
I get that as a practical matter we are forced to trust somebody somewhere eventually, but at best we should be saying that "Apple doesn't seem motivated to abuse this information for now."
I think the primary security white paper describes exactly how it works, but essentially there's a set of shared symmetric keys that are encrypted to public keys for each of your devices. Outside of the key vault path, the way a new device gets access to those keys is one of your other 2fa devices encrypt a decryption key to the new device when you approve it. The basic result is that there is no point in which the key material is transmitted unencrypted off a device.
This is only true for certain services.
Apple is in a unique position where they can sell hardware at profit making prices to a huge customer base. Even if we are at peak iPhone, current Apple users are not going anywhere (I tried to switch my wife to an Android phone once and it was a disaster hah). Privacy moves like Apple ID will only solidify the current user base. Best in class products like AirPods and the AppleWatch also lock users in - in a good way though.
I've noticed that since this announcement it is also pulling some stout Android users I know who have become disillusioned with how Google is slowly locking Android down. The constant bad press Google has received combined with the Apple privacy drum beat is starting to pay dividends for Apple.
However, for a company like Apple to change its stance would take a long time. Culture is sticky and, furthermore, they simply don't have the mass data collection and processing pipelines necessary for such an about face. There would be a fairly long period (my guess is years) during which consumers would be able to change providers.
I feel of all the major tech companies, Apple is way more invested in retaining their brand image.
But there's also a huge security benefit to apple not tracking this information: A hacker/angry-former-employee/creepy-current-employee can't access it either (eg. like the various stories we here about fb,uber,etc admins and employees spying on people).
The problem with burner address servers:
* They don't protect against fake addresses (which is why many services actually block them)
* They are much harder for regular users to use
* They're annoying to use, and fundamentally require providing your email address to yet another third party
Apple Sign-In clearly make the use of cloaking addresses much easier.
Again this still only applies to "social" logins, you're welcome to have your own login system.
I’ve personally tried personal burner email addresses for forums sign ups but the thing I found is that it is a maintenance (if that’s the correct word) nightmare. If you go with the ones that last for a brief period of time, you better guard the credentials because there’s no clicking forget password.
I’m hopeful of the feature, but even if it proves to not be that great, I’d still rather they be my identity provider over Facebook or Google so it’ll still feel like a net win.
Apple could in the future become evil after 40+ years. The other two companies are actively evil.
Do jack booted thugs come to my door to force me not to buy an Android device?
Do you really think most users were aware that they were giving up their privacy? Even if you assume they do, Google broke a contract with Apple by using a developer certification.
Google was upfront about what their app did and paid their users for that data. It's just like a Nielsen box. I had installed it on an unused tablet myself, tapping the notification to check in weekly, and collecting enough Amazon credit to pay for Prime. https://www.google.com/landing/panelresearch/
Were they clear in telling people “we can record all of your internet activities including messages, banking information”, etc.?
Yes Apple stored data on Chinese servers, but your private keys never leave your device. Do you have any evidence to the contrary?
What the app was capable of collecting is different from what the app actually collected, which was clearly specified when signing up. The app is still available in the Play Store, and people still use it because nobody was surprised by what it collects. https://play.google.com/store/apps/details?id=com.google.and...
> Were they upfront with Apple about their use of the enterprise certificate?
Who cares? There's nothing evil about circumventing some arbitrary Apple policy to give users an app that they want.
> Yes Apple stored data on Chinese servers, but your private keys never leave your device.
Not your private keys but Apple's private keys, which gives the Chinese government unfettered access to everything Chinese users store in iCloud https://techcrunch.com/2018/07/17/apples-icloud-user-data-in.... Worse, the change was applied retroactively to data the users had stored in iCloud prior to the change. No other US tech company comes close in evilness.
Yes they pinky promised not to collect all of your data. So will you email me your social security number if I promise not to use it?
Who cares? There's nothing evil about circumventing some arbitrary Apple policy to give users an app that they want.
Yes there is nothing wrong with breaching a contract....
Not your private keys but Apple's private keys, which gives the Chinese government unfettered access to everything Chinese users store in iCloud https://techcrunch.com/2018/07/17/apples-icloud-user-data-in.... Worse, the change was applied retroactively to data the users had stored in iCloud prior to the change. No other US tech company comes close in evilness.
That’s not how public/private key pairs work and the article said no such thing.
The app is still available in the Play Store, and people still use it because nobody was surprised by what it collects. https://play.google.com/store/apps/details?id=com.google.and....
So you’re absolutely sure that every single person who downloaded the app was aware of what it was able to collect and that everyone who downloads it was legally of age able to consent to data gathering?
That's dense. If you use Apple email, they also collect your social security number if someone sends it to you, and they (and the Chinese government for Chinese users) have the ability to reset your password and gain access to any service is sign up for, despite pinky promises otherwise, and Apple's software has permission to read absolutely everything you do on your phone. In just the same way, what they have the ability to do exceeds what they tell their customers they do. What the app actually collected was specified, and there remains no evidence that they did anything more than they told the panelists.
> Yes there is nothing wrong with breaching a contract....
There is certainly nothing evil about giving users what they want in spite of the whims of a capricious (and actually evil) middleman.
> That’s not how public/private key pairs work and the article said no such thing.
Apple encrypted user's iCloud emails and iCloud data in a way that Apple still has access to for search. It is Apple's keys that matter in this case, not the user's keys for communicating with Apple.
The article said exactly such thing: "Before a switch announced in January, all encryption keys for Chinese users were stored in the U.S., which meant authorities needed to go through the U.S. legal system to request access to information. Now the situation is based on Chinese courts and a gatekeeper that’s owned by the government [emphasis added]."
So users want to install software that can intercept all of their communications? I’ve never heard someone say, “I would give up all of my privacy and install a network sniffer/key logger on my device of someone paid me*
Apple encrypted user's iCloud emails and iCloud data in a way that Apple still has access to for search. It is Apple's keys that matter in this case, not the user's keys for communicating with Apple.
That’s also not how email works. Email is not a secure communications and is never encrypted. Besides that, you don’t need to use an Apple provided email account.
The article said exactly such thing: "Before a switch announced in January, all encryption keys for Chinese users were stored in the U.S., which meant authorities needed to go through the U.S. legal system to request access to information. Now the situation is based on Chinese courts and a gatekeeper that’s owned by the government [emphasis added]."
That’s not how public/private key encryption works - despite what you read from techcrunch. The whole purpose of a public private key pair is that you (or your device) creates the key pair, you send the public key out for anyone to use. They then use the public key to encrypt a message and you keep your private key. Anyone can encrypt a message and only you can decrypt a message with your private key. Am I really explaining how public/private key encryption works on Hacker News?
I just told you that I did exactly that. If you read the reviews of the app on the Google Play Store, you will find many other users confirming that they knowingly and happily made the same deal. The Nielsen box itself contains a microphone that can hear everything in the room, and people happily sign up for the payment.
> That’s also not how email works. [Blah blah blah.]
You missed the point. The point was that Apple has the exact same access as Google from the operating system. There is a difference between what the operating system allows an app to do and what it actually does, which you have repeatedly conflated.
> That’s not how public/private key encryption works.
Now you've confused end to end encryption with public key encryption. It's a bit ridiculous that I have to explain the difference to you, but here it goes. iMessages is end to end encrypted. ICloud services like mail, drive, and docs are not. By handing over the iCloud keys to China, Apple has given the Chinese government unfettered access to this information and, by extension, all services which can be accessed using those credentials.
Now that you understand the problem, do you understand how that is evil?
In some cases, your iCloud data may be stored using third-party partners’ servers—such as Amazon Web Services or Google Cloud Platform—but these partners don’t have the keys to decrypt your data stored on their servers.
If Apple is in fact lying,I’m sure a lot of government agencies would be glad to know.
https://support.apple.com/HT202303/localeselector
This is different from the (nonexistent) Chinese privacy policy.
https://iphone.appleinsider.com/articles/18/02/24/apple-to-m...
I agree, this is some win for privacy against random rogue apps, but I don't see how Apple would secede anything.
Could you elaborate?
They obviously have a mapping of cloak address -> real address, but there's no requirement for them to have any record of which apps got which addresses.
Nitpick: seceding = leaving a group, ceding = giving up something.
Thank you very much :p
It's not a stretch of an imagination that Apple might cut a developer out of the app store for some abstract-defined violation of terms (as they do now) and now ALSO cut that developer from the identity/contact with their users. In total, this is almost the ultimate kill switch to push companies to adhere to their policies or risk a total shutout. This scenario might be considered overblown, if it wasn't that Apple already exercises pushy monopoly(esk) control on their ecosystem. The new identity system expands that control to now outside the Apple hardware ecosystem, possibly affecting platforms like Android.
I'm ranting here a little, but I think we should be cautious of accepting privacy as the sole reason Apple wants to enforce all app authentication to use.
No they're not. They're preventing third parties from accessing your data. You can communicate with your customers just fine; it's just that if you sell their data (or get hacked) the email you get is useless.
Centralization of communications is not a good thing and it's worth discussing whether we're going in the right direction.
1. when your business is on the app store it can be difficult not doing whatever Apple wants you to do because not doing what they want you to do can come close to destroying your business. This has often been compared to being a hostage of Apple.
2. If you suddenly decide to stop paying the Apple tax or if Apple decides to ban you - cutting you off from new business - it can certainly be problematic and can kill many businesses but you could theoretically keep going because you could have a customer base you inform of your decision and tell them to download your app from your homepage instead of the app store etc. In short - in the event of Apple not liking you anymore you can communicate with your customers.
3. In this new setup if Apple does not like you anymore you cannot tell your customers hey Apple doesn't like me anymore.
Thus Apple increases its ability to hold your company hostage and thus I do not believe it is the same logic as Google controls Gmail unless when selling an Android app Google only allows you to do so if your customer has a Gmail account.
Google does not have a mapping between an application and email address the customer used in that application. Also Google is not really enticing a customer not to provide the service provider any email address other than the ones in the mapping.
The parent commenter is correctly pointing out that Apple would be able to disable the email for other reasons as well.
With these emails they could trivially, and surgically, cut off a developer from every customer. It is a one-to-many action that also has no obvious other side effects (unlike bricking users phones).
Not sure where I stand with this, but wanting to point out that the added powers this gives Apple are very real and different from the ones they had before (again, maybe this is a good thing, but it’s undeniable that it is a different thing).
- Is there a big enough reason to motivate them to do so?
- If given a "legitimate" justification, would they?
If either of those are "yes" then the question we need to know is: "Is there any appeal, oversight, etc?"
It's not like you can ask Apple to forward emails to your own email server if you decide that you no longer want to use Apple.
I think Apple shutting down your access is a legitimate concern. Yet Apple is the only one who has taken any steps to protect the customer here. The reality is we are unlikely to see other major competitors to Apple find a better alternative because their entire business is built on exploiting user data.
And 3rd parties who create a similar system are unlikely to be successful because they don’t have the clout to convince websites to incorporate them.
But you're right, it does give Apple power, just the same power that has already ceded to Facebook and Google through their logins.
The reality is that companies need to understand that user's are sick and tired of being spammed, and are rightly annoyed by needing to provide every company with their email address for no good [to the user] reason.
I totally agree with your point that this is arguably a good thing, though; although I don't personally own or use any Apple products, there are fairly few services I'd want to sign up for that I'd want to ensure that they had my real email, and I'd be happy to make sharing my email address an opt-in choice rather than the default.
It’s just that whenever Apple decides so, the email you got becomes useless.
Apple is judge, jury and executioner, and it makes the laws. That is problematic.
For example, do we need the ability for Apple to delete the link between a company and all their users in one sweep, or is it sufficient to make it easy for individual users to cut such ties?
If the latter, could we remove that giant master switch, or move control of it to a third party?
(I haven’t watched the video, so, possibly, that giant switch doesn’t exist. Skimming https://developer.apple.com/sign-in-with-apple/get-started/ didn’t tell me that, either)
There is, it's called IM2000 where email becomes a pull-based system instead of push-based (so users would have to consent to spam, and spammers have to store their spam to send it in bulk). Unfortunately, despite many attempts to switch over we're still stuck on the current incarnation of SMTP.
There also isn’t an easy transition from now — I can see exactly why we’re “stuck” with what’s actually a pretty great last bastion of decentralization on the Internet, for all its warts.
But yes, the transition would require replacing SMTP so once again we're stuck on a system that is terrible enough to grumble about but not terrible enough to change.
(I would also argue that Matrix is becoming a new decentralised system for the internet, as well as ActivityPub depending on who you ask.)
The percent of times I want to recieve email communication from something I have to sign up for is very close to 0.
If Apple for some reason doesn’t allow the app maker to use the OATH service, I doubt very seriously that they will cancel the email forwarding without the user specifically turning off the forwarding.
At that point both the user and the app provider both have generated email address.
Where's this confidence coming from? If Apple sees it fit to prevent you (the developer) from accessing your Apple specific userbase for any reason / violation, other people seem correct in their theorization that there's nothing you can really do as the developer.
Not implementing this new "Sign in with Apple" will also probably be interpreted as not being privacy friendly by the users, a developer can't really have that either.
Pretty much the definition of being stuck between a rock and a hard place.
I agree with the group that's (rightfully, imo) concerned about handing over this amount of power over their business to any 3rd party. There's a real potential for abuse.
If Facebook sees it fit to prevent you (the developer) from accessing your FB specific user base for any reason / violation there is nothing you can really do.
If Google sees it fit to prevent you (the developer) from accessing your Google specific user base for any reason / violation there is nothing you can really do.
Worse
If Gmail sees it fit to prevent you (the developer) from accessing your Gmail specific user base for any reason / violation there is nothing you can really do. Gmail already does this occasionally by quickly blacklisting non Gmail senders in their spam filters.
If Apple tells you to take a hike, and then subsequently disables the email redirect -- you're completely SOL. You'd have no way to reach out to the user anymore, unless you took other identifying bits of info. And if you did that anyway, that defeats the purpose of AppleID to begin with.
Most users will probably not even be tracking what autogenerated email they're using, hence you no longer have a way to reliably reconcile what user had which account.
Regarding the GMail specific case though, I fully agree. Being banned by GMail is a company ending thing.
Probably from the fact that disabling these email addresses would be a distinctly user-hostile move. If Apple determines that the developer is actually a malicious entity who slipped malware past the App Review process, then it might be reasonable for them to disable the forwarded emails as well as a malware vendor has no legitimate reason to talk to "users", but beyond that specific scenario, cutting off the email address harms the users who signed up for that service. For example, if the app actually represents a web service, and Apple determines that the app shouldn't be in the App Store for whatever reason, blocking "Sign In With Apple" (which is distinct from removing the app from the app store) and cutting off the email address means the user has no way to recover their account even though the service is still active, just without an app. There is no reason for Apple to take this step as it benefits nobody and only serves to harm Apple user.
I'll even go one step further and say that I personally don't think Apple will do it unless under extreme circumstances.
The thing is though, business continuity assessment still points to adopting Apple login to be a bad idea. You never really know when you'll find yourself in hot water with one of your vendors, especially a vendor who's a LOT more powerful than you.
Here’s a crazy idea: if you don’t want your users giving you a private forwarding address, give them some reason to trust you with their real one, instead of saying they’re idiots who don’t know what’s best for themselves.
But if you come to trust the app, and Apple excommunicates it, should you need to rely on Apple to help you reestablish your own contact with it? That won't work -- Apple already demonstrated that they don't like that app.
That's why makomk's complaint is
> there is no way for users to prove their accounts belong to them without Apple's co-operation
rather than "I should be able to get customer emails from Apple regardless of what the customers want".
There is no requirement that you only support apple sign-in, you just aren't allowed to require user's to sacrifice their privacy to use your app.
If Instagram is using https://developers.facebook.com/docs/facebook-login/ with the little “log in with Facebook” button, it’s a social login. If they have their own proprietary way to do it in-house, it’s not, and not subject to Sign In With Apple.
That easy.
If it "chose provider" then yes, apple could shove in their own with the pretense of user privacy, while it is painfully obvious that it's just leveraging their appstore control to grab market.
Not even OAuth can be unambiguous. I can have a single OAuth login. That could be myself as provider, or leveraging some other provider, which could be more or less connected to my app.
The comment is saying you're free to implement your own auth mechanism using plain ol email or a phone number, but you also have to support Sign in with Apple
a. actual users have a non-FB/Google OAuth identity
b. apps have something other than google or facebook login?
I've literally never encountered an app that had anything other than google or facebook for their oauth login. The only site I ever encountered that used something different was stack overflow a decade ago, and I recall them killing it off or at least complaining about it.
I suspect that the reality is that in a regular user's experience Google and Facebook login are the only ones they've ever encountered.
I think you are right that it will be an issue in the long term if things stay the same. Somewhere I hope this forces the other players in the field to react, to avoid Apple getting too much power.
I don’t see anyone else right now that can force app devs to support this scheme (for instance I saw countless signup pages that reject gmail’s + syntax, companies clearly don’t want to be filtered), nor that would be trusted for now by users to not abuse the situation.
Perhaps Microsoft could ? barely, as they for instance were sticking ads in their browser.
So, in a way I see Apple doing what only them can do, and hope it creates enough precedence for other minor identity managers to step in and being a more sane solution for the long run.
Third party apps don't have to use e-mail for logins. They can use user names.
Backers of e-mail based sign-in often call it a "frictionless" method for the users to sign up. What it really is, is a frictionless method for them to collect information about their users.
But this is also specific to "social" logins - eg ones where you aren't intentionally providing your email address.
More in-depth article about it: https://www.troyhunt.com/im-sorry-but-your-email-address-is-...
For accounts that really matter (not throwaways), someone needs to know a fair bit about the user's identity to ensure recovery works. It can be delegated (and probably should be), but that moves the identity problem rather than eliminating it.
Maybe someday we'll all have two Yubikeys (one for backup) and register with each website using them, but that's not how things work today for most users.
- financial accounts: they would never use a third party login anyway.
- social accounts: None of them are going to let you login with third party accounts anyway.
- work accounts: Again they arent going to use social media accounts. They are going to use some type of ADFS federated account.
- My AWS account: I use Google Authenticator for that.
I lost my original Reddit account because I never gave them my email address and it was hacked. (Using a throwaway password set back when I didn't care about Reddit.) I contacted support and they shut it down, but without some other way of knowing it belonged to me, wouldn't give me my account back.
This "problem" has been routinely solved by free forum software and other systems for decades now.
(I still don't. My email address is public. But some people apparently do.)
Apple sells me thousand dollar phones and services. Until they start selling my data to ad brokers and becoming a Google I’ll support Apple on this going forward.
Also, you may want to check the news about Apple selling data ...
Yes Apple sells ads on its AppStore and allows ads in apps. But what they sell is the chance to be in front of a billion affluent iOS owners which is different than using every bit of data from every Google property to create a profile of a user so as to target ads even more effectively or show you even more extreme videos to keep you ever more engaged a la YouTube.
There's really no such thing as checking for a "real" email address, though lots of sites do blacklist known anonymous email domains like 10minutemail. But nothing can stop you from just signing up for a new Gmail.
I don’t understand this complaining. Everyone who has a business has to deal with these sorts of things. That’s why people pay businesses, so we don’t have to deal with the hassle. This is the essence of running a service, such as developing apps.
Or in the best interest of Apple.
“But then Apple will be a monopoly and you’ll get screwed anyway”. Maybe. But no more than I’m already being screwed by every other cable provider, cell phone company, data broker...etc. I like Apple products. I will continue to spend too much money on them. I’d rather be screwed by Apple in exchange for some pro-user policies, than screwed by every other company that’s already screwing me in exchange for...oh right, nothing.
This is not true with Apple. They often ban superior apps to force their users to use Apple's inferior apps.
Once you understand this, you will be able to understand that this isn't pro-user at all. This is giving Apple control, and making it harder to switch in the future.
I’m not saying it’s definitely never happened, but I’d be love to read about some examples.
Absolutely. I have hundreds of different independent ROMs to choose from many of which are completely FOSS. I get to add or remove any app I want and don't even have Google Play services installed.
The only software I don't control on the device are the proprietary drivers and boot loader. But that's no different from my Linux desktop.
once apple starts gaining traction with this feature, it's positioning will inevitably change, possibly for the worse, and then we back another borse who will keep apple in check.
unlike on game of thrones, our watch never ends.
You are the 1st party, the service you want to use is the 2nd party and Apple is the 3rd party.
So you better log in with your own email, but of the 3, I’d rather pick Apple as the lesser evil!
Apple isn't ceding anything here. They still have your email address, they have the record of your activity on the site you're accessing. They are withholding your email address from the site you're accessing, which is good for your privacy. But you make it sound like they've sacrificed something in doing that.
If google had done this, everybody would be up in arms about how google was further overreaching in their goal to gain complete control of the internet and are preventing poor little mom and pop websites from being able to meet their marketing goals.
Just because you believe the FB/G nonsense that the internet is only possible by gross violations of user privacy doesn't mean everyone else buys into it.
They don't need to record what app or service got the alias address, and they explicitly state that they do not record any details about interaction with your service, or any emails that go through the alias. It's an explicit statement in the linked talk.
Which accounts doing what?
Businesses sending to a cloaked email?
I'm not trying to say this is a bad thing, I love what apple's doing here. I'm just trying to push back against any suggestions that apple is giving something up. They are collecting more data about their users now than they were previously, and positioning themselves as the gatekeeper of user identity. There's every indication that they're doing this for the right reasons, and it's good for users, but it still increases their control and their stored user data.
On the other hand, Apple is tightening its control over its own ecosystems as every interaction has to go through them. Moreover, they're inhibiting anonymous usage of services as more and more things required direct or indirect verification of the user. This entices the market to normalize the demand for unique virtual identities.
Google provides a similar thing as an OAuth/OpenID provider. (except they track all that stuff and share the email with the site/app).
I do like the layer of indirection, but I have to imagine that someday the shareholders are going to ask "why not target ads like Google is doing" and they're not going to have a good answer.
You guys trust companies wayyyy too much.
They've also explicitly stated that they will not record any information about interaction with a service.
Based on Apple's general approach to data security, I suspect that there is no "company A got alias address Y" table. In principle all that they need is a table of alias->real. On the other hand maybe it would be useful to have such a table in the case a site gets compromised/starts selling information?
But they have stated explicitly in a public video that they will not record interactions or emails you send, so I'm sure it would be lawsuit city if the reneged on that.
The email relay address could feasibly be just a reference to that state.
Which would be even more reason not to sign in at all. That said I'm sure that whenever the official guidelines come out there will be something explicit about not doing so (although of course that would only apply to apps)
When a company blocks Mailinator, they're giving up a pretty small number of users -- those who know about Mailinator, use it, and refuse to sign up for a service that blocks it. Since Sign In with Apple is required for any iOS app that supports 3rd-party login, any company (with an app, which is mostly what this is all about anyway) that decides to block this new type of authentication will be forced to either give up all 3rd-party login options (costing them existing users who sign in this way and increasing the cost to acquire new ones), or give up their iOS app -- in either case, this probably means giving up a large number of users.
I’d like to see these:
1. Restricted to people who have associated a physical Apple device, and
2. No ability for the user to re-scramble the anonymous identifier once it is assigned to a service.
If these two criteria are met, I won’t consider it a throwaway email service.
I run a large regional forum (10-15k active users per day) and our business model (such as it is) does not rely upon having as many randoms as possible getting user accounts.
We are quite selective when it comes to approving new memberships. We look at numerous subtle signals to decide whether to allow an account to be approved instantly, approved with limits, delayed or rejected. Email, ASN, browser behaviour, user's actions prior to the registration page, and numerous other things which strongly predict whether someone is an authentic new contributor, or a sock puppet/astro-turfer/troll/spammer/abuser etc.
This saves us an astronomical amount of pointless work for our moderators and makes our environment more conducive to constructive and useful contributions. (In a way it's like Hacker News comments except we're not as pedantic about chatty contributions so long as they're good natured.)
User privacy is a great thing, and most of us smaller developers have nothing against it. However, it needs to be done in a way that doesn't threaten our business continuity.
If your business is dependent on giving away user privacy to Facebook or Google unless you are doing something that integrates with them - it deserves to fail.
I don't want to know who someone really is.
I don't care how little information I get through these systems. I don't want it.
What I do want to know is that I can exclude throw-away Google/FB/Apple accounts made five minutes ago specifically to establish a new whitewashed identity on my site.
Right now I don't offer Facebook or Google login at all—specifically because I think the consequences (both privacy and the further entanglement of powerful entities) are not worth it.
For dealing with non-legit users the email address itself isn't so important. We don't ignore it—we happily reject attempts from ~10k throwaway domains and also some whole TLDs—but it's only one in a set of signals. The reason why the click-link-in-email process is so useful is mostly because it's a way for me to inject confusing and uncertain failures to the process to make it incrementally harder to game/predict our registration system. And it lets us inject plausible yet artificial slowness so that a persistent arsehole is never able to move faster than our people.
(Far more important are the subtle signals, particularly how the user behaves prior to registration. For example if a totally clean browser goes straight to the registration page it's likely to be an arsehole in a private browsing window. Legit users almost invariably browse content immediately prior to registering.)
You can still verify their email address for password resets. You send the link with the email address to the alias and Apple forwards it to the user.
But the whole purpose of using SSO is that you are not responsible for passwords - the IDP is. You should just be able to store the user id.
Besides, why use any third party identity provider if you are still managing passwords? You said that you needed an email address to send a password reset link.
Correct but irrelevant. For aiding the registration of legit users, verifying an email address is beneficial as a way for them to ensure they are able to recover their password.
Why do you need to help them recover their password if you’re using a third party?
I haven’t investigated Facebook or Google SSO in depth (I always considered it a bit distasteful to participate in making these behemoths more indispensable) but if they offer some useful metadata that allows me to exclude G/FB accounts which are inauthentic or freshly created, I might look into it too.
The "real person bit" is a thing. It's the sole bit of information Apple gives for free, which is either that Apple thinks it's "highly likely" that the user is a real person (the bit's absence doesn't mean Apple thinks it's a bot, it just means Apple can't be confident it's a real person, which might simply mean Apple doesn't have enough information to make that call).
People can and have been trivially creating “unlimited new anonymous accounts” by creating new and multiple email accounts on Gmail, Yahoo, Outlook, Protonmail, Tutanota and many other “free e-mail” providers. Unless you have a list of all “free” email providers around the world and are blocking them, this stand against Apple doesn’t make sense to me.
These proxy email addresses are supposed to be pseudonymous, one per apple id + app team, and are set to relay to a verified email address associated with that apple id.
Authentication will tie back to an associated physical apple device, although you can have one device associated with more than one Apple ID.
This is not a new thing.
For example, when the iPad launched and digital versions of magazines began to be available, Apple allowed a subscriber to provide the magazine publishing house with their email address, but also required that they be allowed to refuse to provide it.
The new thing here is to give the user a way to shut off abusive spamming of an email address they have chosen to provide.
Again, from a customer angle I’m not 100% sold on this. I don’t want to miss an email because Apple servers are down, and if Apple decides to kill an app I don’t like, I also want the ability to disagree. Separately, I want something that wouldn’t be a pain to use on non-Apple devices.
There's obvious pros and cons to the developer owning that communication channel, or to a middleman owning that communication channel.
What Apple is doing here is using their total control of the application distribution channel on iOS to hold apps hostage to add an option to sell users on handing Apple control, or possibly reduce their growth by forcing them to remove the other login options.
It's mildly pro-consumer, but I think it's anywhere from mildly to very developer hostile. I'm not positive it will have a sustained effect, as developers may do what they did with Facebook and detect the proxied email and ask for the real one in its place.
And Apple may very well outlaw this practice.
Sure, Apple could add even more complexity to their review process (delaying approval), or give stiff penalties to developers for working around it.
Apple's recourse to remedy a situation where a developer does not want to allow Apple to forcefully insert itself as a middle-man is primarily punitive.
Thus, as stated, this is mildly to very developer hostile.
I can't even imagine what would happen if Google did the same thing with Google Sign In and the Play store.
Disclaimer: I work for Google, not on anything related, and am speaking for myself (as always).
Also I think you’re given the choice of using your real email address instead if the anonymizes one. At least that was my understanding.
But lets look at it another way:
* I buy an app on the App Store, and then find out that I have to use FB or Google login.
* So to use the app I have purchased I am required to allow the app and/or Google or Facebook to further their abuse of my privacy.
Alternatively:
* An App is shown as "Free"
* I install it, and it require FB or Google sign in.
That isn't free. Again, signing up for abuse of my privacy is not free.
Additionally, if the app only has FB or Google login and you don't use either, you can just not use the app
Why should an app be listed as free if using it requires sacrificing my privacy to use it? That's fundamentally not free.
If the app cost me money then I've purchased an app I cannot use.
This is very simple: they're saying that you cannot require Apple's (and by extension your) users to submit to abuse of their privacy in order to use your app.
You're complaining that someone else is building apps in a way you don't like. That's their right; they aren't building them for you.
Why should Facebook?
Why should I have to get accounts for those services just to use your app?
Why should apple list apps that can't be used by users because of they require user's to create accounts with companies that are known to abuse user privacy?
The last point I think is the most reasonable: why should I, a user, be required to use some arbitrary third party just to use your app?
If you are solely using them for login support, and nothing else, then all you're doing is adding one more OAuth provider. What makes it so hard to require an Apple identity if you're already willing to accept google or facebook ones?
You are entitled to not use my app. I am entitled to not care.
The common and almost universally accepted understanding of "free" is "no exchange of money". Saying those who don't adopt an extreme viewpoint are lying is dishonest.
But what good would “open source tools” do overall if you still have to integrate with Apple’s services/APIs to do anything useful - the same is true with Android/Google Play Services.
Surely the logical extension of this is that no app with ads should be marked as "free". Your attention is not free. Right?
But the problem they're going after is bigger: how do you allow users to keep using their favorite apps (because most people aren't super privacy-conscious) while at the same time making sure those apps don't track users or sell their data? And, like it or not (and many people won't), I think forcing developers' hand is the only real way to make this happen.
Free in the colloquial sense means "no money required", otherwise nothing is free since there is always some cost, if not an opportunity cost. What are you going to do, complain that an app required bandwidth to download?
Apple has just leveraged their position as the iOS gatekeepers in order to obtain a huge marketshare of the SSO market.
> I can't even imagine what would happen if Google did the same thing with Google Sign In and the Play store.
If Apple made its money by mining its users' data, there would be a big uproar about this announcement, too. But Apple made it very clear that they will not be doing that with this data, and is moving more and more towards establishing itself as the privacy-focused alternative to Google... So this is by and large (and obviously there are many people with reservations, whether about Apple forcing developers' hands, or about trusting a big company in general) being seen as more of a Good Thing.
Not to mention that Google knew that the certificates were meant for internal use only and agreed to the terms.
Just like a Nielsen box, the app collected clearly specified data, and users were paid for it.
That's Apple's fault if the permission screen didn't show that. What the app actually collected was different from what it had OS permission to collect and was clearly described to the user.
I'm not an Apple user, but I would expect Apple to provide and guarantee that you can log in any app with your Apple login. Seems fair to me.
Also, I'm pretty confident that Google offering a privacy-oriented SSO on Google Play would be appreciated by everyone. Privacy on Android is such a joke : any app can freely read the accounts present on your phone, they don't even need you to sign in to identify you
If Google were to implement the same requirement, any cross platform app with Apple's login would also now have a Log in with Google button, making sure that Apple won't be getting any Oauth monopoly any time soon just to keep them in check.
I'm even more thrilled to see, that according to the Okta article linked in another thread by simonw [1], Apple uses OAuth and OpenID Connect for this, and not some home-grown protocol.
Great news all-round.
[1] https://developer.okta.com/blog/2019/06/04/what-the-heck-is-...
It is also available on the web (including on Android and Windows)
Specifically:
It verifies the "realness" of the account, so everyone claiming that they need user's real email address for "fraud detection" can't argue that nonsense anymore. We all know that argument was just a cover for "we want to be able to spam our users with impunity", but this specifically addresses that argument just to be sure.
Run a site that allows/displays user submitted content and you'll likely change your mind about that being a cover or bogus argument.
The only reason they want a user’s real address is because they want an address the user cant stop them from spamming.
There is literally no other reason.
Unsubscribe and report to spam doesn't exist in our world, anymore?
Deleting the anonymous redirect address they’ve been given requires no such cooperation.
And very few apps (at least of what I use) that have 3rd party auth have features where user content is displayed to others.
If you watch the presentation or read the transcript, you'll hear that they already do a bunch of fraud prevention. I'm going to go out on a limb and say Apple is doing much more anti-fraud/fake account work that most others are able to.
You get an email address you can contact them through.
Also, I think most users anyway use a secondary or "throwaway" mail account to sign up to various websites that are not critical to them. This problem is largely already solved.
If you watch the presentation or read the transcript, they explicitly say that they're doing fraud/spam account prevention.
Do you really think you're doing more fraud/spam detection and prevention work than apple?
But also any argument that the makes spam harder to block also applies to Facebook or google logins - I can’t imagine spammers are using real email addresses with those services.
The only people this changes the experience for are actual users. Spammers already have a huge array of options to get “real email addresses”.
1. If my app is both in IOS and Android, and maybe Windows, would this work across platforms? The answer looks like no... Apple's definition of "multiplatform" means iOS, TVOS and WatchOS, and some javascript for the web. (given Apple's poor track record for anything web-based, good luck with that). If you want to port your app to Android or Native Windows, good luck with that. Your users are locked in.
2. If I have an app that is a competitor to Facebook, and FB decides to cut me off, I can use the existing emails so the user are not locked out the app (i.e. they will be sent an email with a link to create a password and keep their account).
This looks impossible with the apple sign in. Basically if Apple decides to cut you off, your user's accounts are lost.
No matter what some folks believe that 'everything social is evil', some applications providers provide the social log-in just because the user that prefer using them over entering the same information over and over. Instead of entering email, authorizing/verifying it, and having a profile picture, a social log-in provides those for you.
As I am building an app that has the social login (Google and Facebook) as well as simple email sign in, this feels like an additional burden that I'd prefer not to (for the two main reasons above).
Feels very anti-competitive.... Apple should provide the log-in as an option, and compete with its own merits, but not force app makers to use it.
Also, I think apple is being totally evil now: By forcing companies like Spotify and other competitors to use their log in, they are creating an very intrusive/invasive way to monitor their competitors.
Eg. Netflix and Spotify and a myriad of other Apple's direct competitor are forced to be locked in the Apple's vendor sign in trap.
edit: Also it looks like it's just OAuth and you could implement it directly
If Mozilla or name your blessed organization of choice came up with this system, most of them would be fine with it.
But because it’s Apple, there’s all this consternation about it.
Apple’s huge advantage: their revenue comes from devices and services, not advertising.
It would be different if this was a one-off but they’ve been implementing privacy features for several years…
Yet this one is not a pro-privacy feature, it's an "apple owns your privacy" feature. Apple will control your account access and even be able to read your emails. Sure you trust them, but in the future they 'll use it to push their own ecosystem (like apple payments) to developers. We 've had single sign-ons for too many years to know that any ecosystem lock-in is a bad thing. As bad as email sounds, it's still the free-est , most decentralized login provider available.
> If Mozilla or name your blessed organization of choice came up with this system, most of them would be fine with it.
Mozilla came up with Persona, which would be great if they pushed it further and perhapps provided an anonymous email relayer like this instead of being based on existing email providers. With Mozilla the big advantage is that your account is not tied to any other service, real name, credit card etc. I wouldn't use Apple Login to sign up to a porn site, despite the high standards of apple's security.
I think people would have the same issue if Google required ‘Sign In With Google’ in play store apps that have Facebook login, and returned throwaway / proxies email addresses.
Also, when OAUTH uses the real email address, it makes it simple to switch between the different login options without much friction, which won't work anymore for people using Apple ID. Maybe I'll just have to make it a habit to use only Apple when available, and plain email otherwise.
just like it looks annoying for your Android users that there's Facebook but no Google?
Also, you can give this email address a base name that is different from your normal email address so if your normal address is xyz@yahoo.com, you can have "abc" as the base name of your disposable addresses, and your disposable emails will have addresses of the form abc-<your-chosen-disposable-id>@yahoo.com (abc-spamsite1@yahoo.com for example).
So unlike gmail's "plus" email addresses, it's not possible to decipher your real email id from the disposable one. Very handy.
Combine this with Firefox's ability to remember userid/passwords and sync across devices, and you have a powerful privacy toolset that is not a pain to use and is not controlled by any single entity.
I'm all in favour of increasing user privacy and the general direction that Apple is moving but we've got multiple Apps which allow users to log in via Game Centre, Facebook or Twitch to the same account. This allows them to access their friends, messages and support tickets from any of our Apps. We're able to do this because each of those providers gives us a unique identifier for each user (we only store that id and don't ever store the email address from them). I fear that Apple are going to make this impossible for us to do this going forward which would be a negative experience for our users.
That conversation has a lot of people arguing about things that this video addresses.
I've seen a few tutorials - https://developer.okta.com/blog/2019/06/04/what-the-heck-is-... is particularly good - but no one seems to have deployed a button I can click anywhere yet.
const t = { baseURI: "https://appleid.apple.com", path: "/auth/authorize", originURI: "", env: "prod", uxMode: "redirect", responseType: "code id_token", responseMode: "form_post", client: { clientId: "", scope: "", redirectURI: "", state: "" } };
Notice the responseMode which is set to form_post which I believe is the only supported mode.
This means you can no longer do things like localhost redirect_uri's for testing, or even use Apple Sign In on an internal web-app. Also, goes against OAuth2. :(
I submitted this feedback. Hopefully, someone takes a look.
Seems this might provide some security benefit, e.g. no credentials showing up in web server access logs. Either way, are you sure the final POST isn't made by the client? If so, the client would resolve the address. On their JS configuration page[1], I don't see any obvious evidence that Apple will make the post. They show this line:
`AppleID.auth.signIn();`
P.S. Aghghgh the mixed camelCase and under_score makes me cringe.
[1] https://developer.apple.com/documentation/signinwithapplejs/configuring_your_webpage_for_sign_in_with_appleNo. The final post is not made by the client and a server has to handle the request. Webapps cannot handle POST requests from an Authorization server.
Apple's guidelines stipulate that it will be "required as an option for users in apps that support third-party sign-in".
In contrast with social logins, you cannot create an account with our app via the Esri login, and your Esri account must be set up first in the back-end to even use it at all.
We can't think of a way to feasibly support this per their requirements, unless Esri allows it via their OAuth flow as well (they do support Facebook/Google today).
So this is not a third-party sign in. This is access to third party data which requires signing in with them.
This is absolutely ridiculous. What about games that allow you to sign in with Facebook specifically for the purpose of tracking your progress relative to your friends? Sign in with Apple has precisely zero purpose in this scenario.
I can sort of understand making this a requirement if sign in is required to use the app at all. I really hope that exemptions will be allowed where Sign in with Apple is 100% pointless.
This taken directly from their JS at https://appleid.cdn-apple.com/appleauth/static/jsapi/appleid...
This seems to imply that using this for your personal site, for instance, requires the $99 "developer tax"...
e.g.
* You have a forum that needs a per user identity, but you recognize that managing account login information securely is challenging, and the most cost effective solution is to offload on a separate authentication service (Google, Facebook, etc)
vs
* You're a 3rd party mail client for gmail, and you app is actually signing into the third party service itself.
Of course I'm sure all of this will be clearly and unambiguously explained by release :-/
Love iMessage autofill on text inputs from text message codes
But... Authy (arguably more secure) is super annoying to open, click, copy, re-window over, click, and then finally paste.
Would be cool if this somehow cleaned up the whole process.
What's the argument ?
>Would be cool if this somehow cleaned up the whole process.
Everyone, just leave 2FA alone. No sms. No custom garbage that sends a push from a cloud and uses a blob on the device. Use TOTP. It's simple and easy. If you want fancier phishing protection, optionally add the newer fido2 or whatever the newer standards end up being. Just no custom garbage.
* you have to install an app, but you can't tell which app you're meant to use
* you have to configure the app with whatever your signin service is
* If you ever delete the app (something that is generally not harmful) you lose the ability to sign in, and reinstalling frequently does not bring back your old authorizations.
But yeah, SMS 2fa is garbage from a security stand point (and will remain so until carriers can be held liable for costs from transferring your number without your authorization), but it is usable and is leaps and bounds better than nothing at all, which is what users will do if you make 2fa hard to set up.
I just want cleaner integration for the user. Don’t care about messing with it
Alternatively, and if the form supports it, you can use the share sheet on iOS to get 2FA auto fill from 1Password.
Essentially what Apple is doing is creating a new gate as they've done before with forcing developers to use their payment processing system for digital goods that costs 30% of the total fee.
Facebook Login already supports users blocking sending sites their email, as I disable that all the time. They even have published guidelines with what a site should do when they think they need that piece of information. So I'm not sold on the privacy story here. Go on, give it a try the next time you are signing in for the first time. You can even go back and remove your email permission from the security page in FB.
Apple did do one thing though, they created a bigger market for junk email services and made it easy to send those to services you expect to get notifications from. Still, this is something Apple could have built into iOS just like they did with password managers. It's not a feature that needed to be forced on anyone for any reason. As a user of the device, I can just pick, get me a junk email and presto, it's done.
I get it though, I can imagine the scenario last year right after news broke with Cambridge Analytica. This was enabled from a shady 3rd party developer using FB single sign-on and execs at Apple were pissed. They probably hastily demanded someone at Apple create something to circumvent FB's position. However, this doesn't just affect FB, it affects Twitter, Google, GitHub, Microsoft as well.
Yes Apple has good-will in this community, and its to their competitive advantage that they continue to build out more privacy focused features. However, I still do not appreciate that Apple gets the final say. This should have been a bigger conversation across the entire industry. Why didn't Apple come out and say, we are investing in the Oauth organization and then published papers on best practices? It would have been a much bigger win to get Microsoft or Google on board from the start and launched together. Hundreds of researchers all over the world would have jumped on it. Instead now we're left with another moral authority move, shoved in developers faces at the whims of Apple Execs.
Developers are free not to implement social login. If they do implement social login then this provides a unique user benefit (privacy) while also increasing user choice (users are still free to login how they want).
WOW what a great feature, you have have done it again Apple. Keep the innovations coming!! :DDD
And apparently, to make up for the 11 year delay in developing this feature, they now force everyone to show it alongside of Google & Facebook sign-in.
Is it implied that as soon as iOS 13 goes out we'll start getting app updates rejected unless this is integrated?
If for no other reason, this is a great reason to use it.
Apple suddenly decided on the amateur-hour policy of forcing users to use an E-mail address as their user ID. And more recently they've doubled down on that stupidity by requiring that it be a WORKING E-mail address, giving you no way to specify (in your user profile) a real E-mail address at which you can be contacted.
The public at large isn't all that savvy about how this works; so when asked to set up an account with their E-mail address and password, what percentage would you guess assumes that they have to use the same password as their actual E-mail account?
I'm guessing that percentage is very high, maybe 50%.
When sites implement this asinine policy, they become responsible not just for the user's security on that one site, but the security of the user's E-mail account. Talk about a ripe opportunity for identity theft or more, if the site's database is hacked or stolen.
You don't see banks or brokerage houses forcing people to log in with an E-mail address. Apple's ignorance of online services continues...
- it's more difficult to implement than FB sign in and websites don't get any of the benefits
- it works with apple devices, and it will be a nightmare to use in other devices, esp. if the user uses the private email
- Apple would control and route the emails of the user and the app! This is a big privacy hole imho.
- Apple drops users or apps without second thoughts from their ecosystem, and the web is not used to this (and is not going to change)
- Maintaining new sign options is already a hassle, adding a new one that will only be accessible to a relatively small user base, with a number of hoops makes it seem less worth it.
On the plus side though, you do know that users coming from apple sign in are probably richer and better monetizable.
You're forgetting the part where Apple is going to mandate that app developers must offer Sign In With Apple if the app offers any social logins like Facebook or Twitter, and that the Sign In With Apple option is strongly suggested to be the first one on the list.
It absolutely will gain traction.
It's standard OATH just like FB
- Apple drops users or apps without second thoughts from their ecosystem, and the web is not used to this (and is not going to change)
That's no more of an issue than if you are using any other IDP that could also drop you.
Maintaining new sign options is already a hassle, adding a new one that will only be accessible to a relatively small user base, with a number of hoops makes it seem less worth it.
iOS users are a small user base?
Doesn't it require an active developer subscription?
> That's no more of an issue than if you are using any other IDP
Google and FB are pretty lenient about who is allowed to use their sign in and i haven't heard of any horror stories. Comparatively apple is very aggressive in removing apps.
> iOS users are a small user base?
It's like 12-25% of users which is not a lot and it is very highly overlapping with people having FB/google accounts already, so it definitely seems like an "optional" sign in option.
-United States 54%
-United Kingdom 49%
http://gs.statcounter.com/os-market-share/mobile/japan
- Japan 70%
https://www.statista.com/statistics/861532/australia-mobile-...
-Australia 56%
Even if you take into consideration poorer countries, the more affluent population still has iOS devices.
What kind of benefits FB offers for websites?