Therefore, anyone offering Facebook/Google login will also have to accept Apple's anonymized forwarded email addresses, like fc452bd5ea@privaterelay.appleid.com.
This sounds like a tremendous headache that I really don’t want to worry about. But Apple is looking to leverage their power in the app market to force me to implement a tool I may not be interested in as a merchant?
I despise being strong armed. I hope the EU crushes this.
However, I wish email and sms would go away as a way to authenticate. Until it does I will be using foo+aliashere@gmail.com so that my account can’t get transferred to someone else through socially engineering a tired rep.
I personally don’t use FB login. And I use `+merchant` to keep track of bad actors. But from a merchant perspective this will likely be a chore. And Apple has decided that we don’t get to decide if it’s worth it. We can’t disable FB login because we’ve supported it for a long time and a ton of accounts only have a FB-synced profile.
To be clear, it’s not the product I have issue with. It’s the draconian ultimatum that because we are in bed with FB we have to also get in bed with Apple Sign In.
They could have just built this into their form system. It already recommends my personal email / credit card / auto generated password. Why not prepopulate / suggest an Apple-generated email? Why force the merchant to implement another standard which breaks all other SSO integrations _by design_?
I don’t have answers to those questions. If this was a consumer feature embedded into their keyboard I’d be ecstatic. Strong arming merchants to implement and bear the full cost of confused consumers who can’t seem to login to their app _even when they click the Apple button_ is inexplicable (to me).
https://tools.ietf.org/html/rfc5233
Not Gmail-specific. Labels however are ;)
Can confirm what parent poster is saying, we remove them on signup.
Also, if you try to mail people based on GeoIP data, you're going to have a bad time.
You could argue that a major feature of the GDPR is to legislate that just because a company can do something, doesn't mean it's allowed to do it.
user@domain.com
The 'detail' is optional, and doesn't infer any privacy.
It's kind of like if you get mail delivered to:
nprateem, office 2, university of ycombinator
and instead they only store:
nprateem, university of ycombinator
Odds are, mail will still be delivered to you, but it might not come to office 2, and might come to office 1 instead. It's not what you wanted, but there's absolutely no impact to your privacy by them stripping away additional details.
The 'user' part is still public information, as is what it's used for. There should be no expectation of privacy for information being used per specification design.
The usability trade-off is a shame, but the solution was half-baked at best, and is primarily useful when combined with privacy-sacrificing public email providers. When you have greater control of your email, distinct 'user' parts can be used, which does provide the privacy aspect desired.
> we also don’t operate in any country requiring compliance with the GDPR
You know it's nothing to do with the country you operate in but the nationalities of your customers though don't you? You could only have a presence on the moon but if you had any EU customers you'd still be bound by the GDPR AFAIK.
But why?
The above scenario goes against what they are trying to achieve though
1) If you support SSO and email/password - then the email and password are still stored (and possibly not hashed and salted if the developer is incompetent) - so you are at risk of compromise if you reuse passwords 2) If you store the users actual email, you are putting them at risk of credential stuffing, as well as opening them up to tracking
The EU can always surprise, but I suspect they would actually like this because it addresses key risks to consumers of password reuse, credential stuffing, and tracking. Additionally it competes against their ideological targets, Facebook and Google.
Not saying what the EU does is goos or bad, but painting it as pro free market competition seems unfounded.
Every tech related legislation doesn’t and shouldn’t need to so,be every tech related problem. The EU has other, non GDPR related, mechanisms to handle monopoly issues.
So to me it seems unfounded to say EU cares about market health and is not, in fact, just picking on FB and Google.
I am honestly curious what you think are examples of EU mechanisms fostering healthy markets. Maybe the MS case but that is the same “EU picks on US tech giant” genre.
I’m not sure what kind of examples you want.
Once I chose to use Apple-Sign In will I be locked into the ecosystem? Will there be 'Apple-Sign In' for Android?
That said, the concept of "Apple Sign-In" for Android and other platforms is an interesting one, not likely in the short term, but possible someday!
Unless I'm misunderstanding what the mandatory part is.
The option is mandatory. End users using it is optional.
Again, the tech is fine. The strong-arm is indefensible.
If you support FB login now and decided to add Google, for example, that doesn't require your existing FB users to do anything different. It should only affect new users who are creating an account and choosing to use the new provider. Wouldn't that be the same for Apple Sign In?
Note, I'm not taking a position on the strong arm tactics, just pushing back on your claim regarding existing users being affected by a new identity provider. That doesn't sound right to me.
A service supporting alternate identity providers via OAuth (Facebook, Twitter, Google, Github) via a flow like this shouldn't have trouble with Apple Sign In from a web page, iOS app, or Android app.