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 generated from the "Sign In With Apple" workflow that a developer has to enable in the first place’
Presumably such services won't implement Sign In With Apple in the first place. People will accept it because they want the sheer quantity of users Apple provides.
The useful thing about Apple is that they can force people to do things they don't particularly want to do, like accept anonymous e-mail addresses or stop using Flash. (unfortunately this is also the bad thing about Apple)
"[Sign In with Apple] will be required as an option for users in apps that support third-party sign-in when it is commercially available later this year." https://developer.apple.com/news/?id=06032019j
There by, when apple passes a XXXXXXX@privaterelay.appleid.com address back, it won't match the existing account's email address = Sorry, matching account not found ?
One other thing that seems powerful is that users that use Sign In With Apple have some guarantee of quality; with Apple using FaceId to authenticate, there's some amount of guarantee that you're not a bot.
I think this is something that people are missing when they suggest services will just block the Apple relay address.
Of course they wont. They still want the business and as you've pointed out, these accounts will be in a different customer engagement category. They are almost certainly real people and they a lot of value to marketers, even is you don't have all of their other personal details.
Or they already rely on FB login and are now _obligated_ by Apple to implement this feature. I work for a company that has allowed people to create accounts with FB login (meaning we don’t have an internal password associated with them). This change would ostensibly require us to also allow Apple Sign In _even if we don’t want to_ just to continue to service existing users.
There really isn’t much choice here for us. Leave Apple / iOS? Abandon FB login and piss off thousands of people? Implement Apple Sign In regardless of its tech stack / requirements?
As someone who also run a service where the only login option is using Facebook, I'm curious about how you regard the negative press regarding Facebook, the recommendations to leave Facebook, and the many users who is sceptic to or has already left Facebook.
Do you have any plans to adopt any other login provider? I would really like to, but other than email/password, I'm not really sure what would be a good alternative, and I'd really like not having any personal information stored at all - email addresses included.
We let people create a username/password but can also use FB if they prefer. Turns out having their email is nice; we need to send them notices and reminders from time-to-time.
I’m not a FB fan. I post on social media maybe twice a year. As an advertiser I don’t trust the numbers they report. None of my criticisms of Apple in this decision should be interpreted as pro-FB. I just have a very strong distaste for Apple deciding that they get to decide how we run our apps.
They have to mandate usage because it’s the only way devs will do it. And it seems like a fine enough product for Apple-only hardware. But when you get to supporting multiple connected devices it falls apart. Are they going to support this for PCs? What about on the Roku? How will anyone who uses Apple Sign In on the iPhone log in anywhere else?
The addresses are only generated from the "Sign In With Apple" workflow that a developer has to enable in the first place, so it wouldn't make any sense to do that and then reject the addresses.
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.
‘Error: We love Apple and anonymity but we require a real email address to prevent fraud and to properly secure your account. Please enter your real email address.’
It would work roughly the same way. Integrating an OAuth provider like this requires registering an application with revokable ClientIDs, so Apple can technically pull them just as easily as they can pull Apps.
(It remains to be seen if they'll put in the legwork to actually police these things, though)
> ‘Error: We love Apple and anonymity but we require a real email address to prevent fraud and to properly secure your account. Please enter your real email address.’
GDPR would probably want to know specifically why you need someone's real email address.
However they most likely won't for the same reason that people who are upset about Apple's 30% App Store cut still develop apps for iOS: they have their customers spend far more on average than other phone / OS users.
But in return for that, the services that choose to employ this will get a soft guarantee that the person signing up is unique/real. Its a way to get real-name/real-id with some amount of privacy.
Apple IDs cannot guarantee a real or unique user - users can have multiple accounts (some users will create a second account by mistake, others have a separate work account, etc), users can share accounts (especially ones tied to generic email addresses), and there are people selling app store reviews, so some bad actors definitely have a lot of accounts.
Thanks for your comment. I used the word soft guarantee, which is meant to encapsulate those caveats. Maybe I should have used a better term since I guess people were confused as to what it meant.
Facebook is trending downwards and privacy concerns with Google are trending up.
Critical mass might be achieved where if you don't include Apple Sign-In you might lose more users than whatever benefit you see from having more identifiable personal information.
They surely can do whatever they want, they can definitely choose to deny service to users that are traditionally high spenders and limit the fake accounts to professional scammers that use account farms from Asia.
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.
Sure, they really could. But for me, it could be a reason to pick Lyft over Uber for example. I hope they add support to the App Store description, that would really help filter apps.
Is that block a recent thing? It might be different as for my on GSuite account I can add the name+addon@mydomain.com - it might just be a difference between the "public" Gmail system vs the Gsuite Gmail system. In which case, my question is completely invalid and feel free to ignore ;)
Note: This comes from my own developer account having 3 name+addon@ accounts live, and working with things like ApplePay etc for testing.
Developer with a name+addon@gmail.com Apple ID here. No idea what OP is talking about, I was able to generate my Apple ID and sign up for the dev console no problem.
Apple now strips the +... part when you create an ID. So if name@gmail.com is already in use, name+addon@gmail.com will be refused with the message that name@gmail.com is already an Apple ID.
If Apple users use Apple Sign-In en masse then any services which blocks it will face harsh negative publicity. If enough people use it then services will have no choice but to acquiesce.
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 generated from the "Sign In With Apple" workflow that a developer has to enable in the first place’