Why not just bind the sso Mail to an local Account, then it doesn't matter what identity Provider gets used by the customer. In addition, add a check that prevents Account creation of ...@privacyrelay...if you have a problem with it or nag the user to provide a real mail for this account if you detect this type of mail.
This way you would have a user friendly implementation without giving up on sso.
Why we won’t be supporting Sign in with Apple
321–330 of 485 posts
Re: Why we won’t be supporting Sign in with Apple
#322Earlier quoted context omitted.
Google provides an email address. You could replace your Google auth with password auth in an afternoon just by adding a "forgot your password" link. Facebook auth used to provide an email address, but it's been almost a decade since I last used their APIs so I don't know if that has changed. Apple's "provide an anonymous email address" inserts them between you and your customer.
When you use Apple's Sign In it flat out asks whether you want to use your real email or an anonymous one. The user is purposely says, "Hey, Apple get in the middle I don't trust these clowns."
Many apps also don't want to have the hassle of securely managing user login details.
Re: Why we won’t be supporting Sign in with Apple
#323Earlier quoted context omitted.
My app is not the App Store. The user has already paid to download my app from the App Store and Apple has gotten 30% of the cut. What users do on my App after that is none of Apple's business, though of course Apple would like to claim otherwise. Similarly, once I have bought something from Walmart I can use it as I wish. Our business transaction ends there, so your analogy isn't really apt. > Does Walmart let you s…
> once I have bought something from Walmart I can use it as I wish. Not if it's a movie, music, or video game. I.e. anything with digital content.
Providers of digital content seem to be absolutely all over the place with this stuff
Comcast of all people offers the ability to buy movies on demand. Not just rent but outright purchase. If you leave Comcast as a customer, you can have every purchase mailed to you as either a DVD (SD) or Blu Ray (HD) purchase
Steam has provisions in place that if its service ever gets terminated to allow users to continue to use games they've purchased on the platform. They also allow users to continue to download and play games either removed from the store or no longer sold (Alan Wake and Deadpool being two examples in my own library)
Conversely Microsoft's Xbox will de-list titles and make them excruciatingly hard to download, such as Marble Blast Ultra. Requiring you to find the game in your account history and then use that to navigate to a download page
Sony's Playstation is downright malicious with their digital store. Konami's "P.T" was offered as a free download as a teaser for an upcoming Silent Hill game
Once Konami changed their mind however, the game was not only removed from the store but actively wiped from the users console! If you connected to Playstation Network the game would be forcefully deleted from your device
Re: Why we won’t be supporting Sign in with Apple
#324Earlier quoted context omitted.
Obfuscation of the email address is an explicit choice by the user when using Sign in with Apple. It’s not something forced by the service. If users are choosing to do that, it says something about the lack of trust the users have with whatever they’re signing up for.
Not necessarily. I have an app with 1,000 users, and about 99% of them choose to obfuscate. My app isn’t untrustworthy at all either. It’s an experimental app which attempts to let users create an iOS app on iOS. My suspicion is that people choose to obfuscate because it’s what’s selected by default.
This is anecdotal but if I could chose not to share my email with things I sign up for, I wouldn’t have a gmail address used solely for signing up to things. I can’t think of a single thing that I’ve ever signed up for that I actually wanted to have my email.
So sure, it’s default, but unless I’m unique some people will see the default and go “why isn’t every 3rd party login like that?”.
Re: Why we won’t be supporting Sign in with Apple
#325Earlier quoted context omitted.
Obfuscation of the email address is an explicit choice by the user when using Sign in with Apple. It’s not something forced by the service. If users are choosing to do that, it says something about the lack of trust the users have with whatever they’re signing up for.
Not necessarily. I have an app with 1,000 users, and about 99% of them choose to obfuscate. My app isn’t untrustworthy at all either. It’s an experimental app which attempts to let users create an iOS app on iOS. My suspicion is that people choose to obfuscate because it’s what’s selected by default.
I agree with the sibling in that defaults are powerful.
However, I've never built anything directly used "by the public", nor am I very familiar with how Apple Sign in works.
So I'm wondering, as the developer of a trustworthy app, what's the drawback in the user giving an obfuscated address?
Is it not possible for you to contact the user using this address? Does the user have to manually allow getting mail to this address or somehow jump through some hoops to read it?
Re: Why we won’t be supporting Sign in with Apple
#326As they point out at the very bottom, all their arguments apply to all third-party sign-ons, so they're removing Facebook as well. So there's nothing specifically against Apple, despite the title seeming to imply it -- just that they're taking the move right now because of Apple's new policy coming into effect. I've got to say, I really wish there were a way to know whether I already used Facebook, Google, or Apple t…
"all their arguments apply to all third-party sign-ons" No they don't. Other sign-on options don't obfuscate the email address. They are likely removing FB login as otherwise their next app update will be rejected by Apple for supporting third party login but not Apple login.
As a user I can't see why any random app needs to know my true email address.
Re: Why we won’t be supporting Sign in with Apple
#327Earlier quoted context omitted.
Obfuscation of the email address is an explicit choice by the user when using Sign in with Apple. It’s not something forced by the service. If users are choosing to do that, it says something about the lack of trust the users have with whatever they’re signing up for.
Not necessarily. I have an app with 1,000 users, and about 99% of them choose to obfuscate. My app isn’t untrustworthy at all either. It’s an experimental app which attempts to let users create an iOS app on iOS. My suspicion is that people choose to obfuscate because it’s what’s selected by default.
Why is it a problem for you?
Re: Why we won’t be supporting Sign in with Apple
#328Earlier quoted context omitted.
"all their arguments apply to all third-party sign-ons" No they don't. Other sign-on options don't obfuscate the email address. They are likely removing FB login as otherwise their next app update will be rejected by Apple for supporting third party login but not Apple login.
As a user I can't see why any random app needs to know my true email address.
From the article:
> If a customer contacts us asking for support, and we need to look up something in their account, typically we can just ask them for the email address on their account. But with “Hide My Email” that wouldn’t be easily possible, because the customer would have to figure out the privaterelay.appleid.com email address used for their account.
> Furthermore, if there are platforms where AnyList doesn’t support Sign in with Apple, like Android, and someone wants to log into their account, they’d have to know their privaterelay.appleid.com email address. (And that certainly won’t be easy to find if you no longer have an iOS device.) And then they’d have to create a password with us, since they wouldn’t be able to sign in using Sign in with Apple.
> Finally, for a service like AnyList, which is heavily focused on sharing lists with other people, the “Hide My Email” option greatly complicates collaboration. Typically, customers share a list by typing in the email address of the person they want to share with. If that person already has an account, the list is instantly shared. But with the “Hide My Email” option, your spouse or friends obviously won’t know your privaterelay.appleid.com email address, so when they enter your email address, our systems will believe that you don’t have an account. At that point, you’ll get an email from us asking you to create an account. If you accidentally create a new account, it won’t include the work you’ve done in your existing account created via Sign in with Apple. And if you manage not to make that mistake, then there would be a link between your email address and the account you created with Sign in with Apple, negating the value of hiding your email address.
Re: Why we won’t be supporting Sign in with Apple
#329Buries the lede. They’ve chosen to drop support for Facebook login rather than also support Apple login. So working as intended!
It is very unclear to me why removing user options is a good thing. I use sign in with Google/Facebook.
Re: Why we won’t be supporting Sign in with Apple
#330Earlier quoted context omitted.
Obfuscation of the email address is an explicit choice by the user when using Sign in with Apple. It’s not something forced by the service. If users are choosing to do that, it says something about the lack of trust the users have with whatever they’re signing up for.
Not necessarily. I have an app with 1,000 users, and about 99% of them choose to obfuscate. My app isn’t untrustworthy at all either. It’s an experimental app which attempts to let users create an iOS app on iOS. My suspicion is that people choose to obfuscate because it’s what’s selected by default.
My recollection is the first time I used Sign In With Apple it forced me to choose (no default), and after that it defaulted to my last choice.
I expect 99% are obfuscating because that’s the sensible choice to make. Giving an app my real email should only be done if there’s an explicit need for this, such as being able to log in from non-Apple devices.