Someone who is not apple should do this and charge for it. I'd pay $10 for something like that
Apple Sign In
21–30 of 544 posts
Re: Apple Sign In
#22I can already see devs implementing things such as `if email domain ends in privaterelay.appleid.com reject the email address and ask for a "real" one`, like what already exists for yopmail and others.
The difference is Apple is too big of a player to ignore.
Re: Apple Sign In
#23I can already see devs implementing things such as `if email domain ends in privaterelay.appleid.com reject the email address and ask for a "real" one`, like what already exists for yopmail and others.
But now they block "normal users", not nerds. And there are many of normal users.
I'm not sure if they could sustain such a policy.
Re: Apple Sign In
#24"This domain is not allowed."
yeah, and say goodbye to your app on app store and hundreds millions users.
Re: Apple Sign In
#25I can already see devs implementing things such as `if email domain ends in privaterelay.appleid.com reject the email address and ask for a "real" one`, like what already exists for yopmail and others.
Such a dev would likely just not implement "Sign in with Apple".
This is for the devs that specifically want the minimal-friction sign-in.
Re: Apple Sign In
#26How long until sites start blocking the cloaked addresses? (although of course Apple can just churn those address patterns)
Re: Apple Sign In
#27I can already see devs implementing things such as `if email domain ends in privaterelay.appleid.com reject the email address and ask for a "real" one`, like what already exists for yopmail and others.
The difference here is that Apple can reject apps that do this from the App Store.
Re: Apple Sign In
#28Can’t services just disallow/block this address? Fun thing is, Apple themselves block name+addon@gmail.com addresses when using their dev console. You can bet that some companies will disallow Apple’s signature private passwords similarly if they can, in the name of ‘security’ or what have you. Or am I being too cynical? Feel free to CMV. EDIT: best response addressing this seems to be ‘The addresses are only generat…
No, you're clearly correct. But Apple pushing this does give it a sense of legitimacy and blocking signups from this service might just cause less signups than actually forcing people to use their real address.
If Apple makes this extremely user friendly and quick to use than blocking it will cause a loss of signups.
Re: Apple Sign In
#29"This domain is not allowed."
While websites do blacklist temporary email providers like Mailinator, I think Apple has more power here; blocking the domain can be pegged as more of an anti-privacy move than blocking Mailinator, which is more anti-spam.
Re: Apple Sign In
#30Can’t services just disallow/block this address? Fun thing is, Apple themselves block name+addon@gmail.com addresses when using their dev console. You can bet that some companies will disallow Apple’s signature private passwords similarly if they can, in the name of ‘security’ or what have you. Or am I being too cynical? Feel free to CMV. EDIT: best response addressing this seems to be ‘The addresses are only generat…
Yes. Back when Google+ oauth launched, "sharing user identity info" was the carrot that incentivized developers to build the integration. Otherwise, devs preferred Facebook so they could get user info.