Therefore, anyone offering Facebook/Google login will also have to accept Apple's anonymized forwarded email addresses, like fc452bd5ea@privaterelay.appleid.com.
But this explicitly doesn’t work as an SSO. How can I tie that back to the actual email address they would have used to create an account using their FB / Google account?
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.
It seems the email part is optional (ie you can choose to share your verified email with the company if you want).
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.
EU is not picking on FB and Google specifically. This mindset is toxic. They are picking on all monopolies for European customers and have been for a long time. Basically we believe the market is not healthy if there isn’t any competition.
This is a bit rose tinted outlook. GDPR does not increase competition, the amount of regulation in EU and worker protections in place raise barriers for new competitors. France has laws that prohibit new movies from being put on Netflix in order to support local distributors etc.
Not saying what the EU does is goos or bad, but painting it as pro free market competition seems unfounded.
GDPR isn’t about addressing monopolies. It’s about addressing privacy and data ownership.
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.
My point is EU will adopt regulation that actively harms competition (such as GDPR), because they have different priorities (e.g. privacy, data ownership as you mentioned).
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.
Presumably it’s always the same address every time they sign in. It is used for single sign on after all!
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.
But someone who has already signed up via FB is going to click that button and then get angry when we can’t log them into their account.
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).
"+merchant" doesn't do squat to prevent bad actors from selling your email address. Anyone so inclined to sell your address would just strip off the postfix since they know it's unnecessary per the spec.
One of the many advantages of using a hosted solution with your own domain is that you can receive email from arbitrary addresses in the same inbox. For example merchant1@inboxname.mydomain.com gets sent to my inbox at Fastmail. inboxname@mydomain.com doesn't exist, so there's no way to get my "real" email address from what I give out to merchants. If I start getting spam on an address, whoops, you and everyone you sold my email to get sent to a black hole in the cloud.
I wonder whether that's GDPR compliant. If I give you permission to contact me on me+alias@example.com and you strip off +alias and then contact me on me@example.com, you've inferred data about me I haven't explicitly given you. One could argue that's in a similar ballpark to running a geoIP lookup and then sending me mail through the post.
It seems rude (like if I told you to drop off a package at my back door and you put it by the front door), but I given the existence of RFC 5233 I don't see how this would be "data about me I haven't explicitly given you".
Also, if you try to mail people based on GeoIP data, you're going to have a bad time.
It's about permission. If I give a company a certain set of contact details, and they run some process to find other ways to contact me that seems unfair and beyond what I've given permission for. The fact that it's trival to find my real email from an alias I think is irrelevant - it's still an abuse of trust. Like I say, I can see a correlation with more invasive methods of finding other ways to contact me that I hadn't granted the company (imagine if they start contacting you on social media just because they could look up your profile from your name).
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.
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.
If you decide you no longer want to receive email from user+detail@domain.com it's easy to set up a blacklist filter. If they circumvent that and email you at user@domain.com you've lost that alias and easy way of blacklisting them. And presumably if someone had wanted to be contacted at user@domain.com they would have provided that email in the first place. So I don't think your analogy holds.
Fair, the analogy doesn't hold onto the functions provided, but RFC 5233 is very clear that the user+detail separation does not provide any privacy protections, nor can it.
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’re a B2B app, it’s unlikely a random user will sign up for our service as it’s quite expensive and contract negotiations happen before the account is activated. we also never send marketing blasts or sell (or even collect) any information about our users. we also don’t operate in any country requiring compliance with the GDPR.
> 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.
to avoid duplicate user signup. allowing the + would not allow me to use a unique constraint for email address on the user table and be sure an email is only used once.
Gmail ignores (or ignored?) dots on the left of the @, so some.person@gmail.com and someperson@gmail.com and s.om.e.person@gmail.com all went to the same inbox. That is gmail-specific.
Because thousands of people already have an account tied to a specific email and are going to click the Apple button and get really mad when we can’t log them in.
Apparently they want to use it, otherwise they wouldn’t, right? This way they can have the easy login using Face ID and you can use the account they already have.
You send information to the apple address, that's what its for. You can still send it invoices or a magic link, the user gets it and clicks on it, nothing is changed in that regard. The difference is they can turn off that email address and never hear from you again if that is what they want.
Stuff sent to the fake email address will be forwarded to the user’s real email address, from what I understand. So you will still be able to communicate with them.
My problem is that I don’t get to choose if your business is worth the implementation cost. Because we’re already in bed with FB we will be forced to implement. It’s the “have to” I’m arguing against, not the feature.
this is the same problem you get from any identity provider — what happens when you finally delete your facebook? — it's just more obvious with Apple. With a 97% satisfaction rate, most iPhone users don’t want to go anywhere else… but yes, if you want to stay free, you should always create credentials directly with any app or service you use, when possible.
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!
I'm speculating here, but Apple Sign-In for Android would work just fine if the sign-in process was based on an OAuth flow where the credentials are entered into a web form. From the limited details I've seen that sounds like how Apple Sign In will work.
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.
It is not about deleting accounts or moving over. Heavy user has multi-device setup, I use Android tablet, iPhone, Mac and sometimes PC, some appliances like Synology with bundled apps also. Nowdays even my printer has online sign in, for file sharing apps. I expect same account to work everywhere. If they provide reasonable platform-independent email solution, it may work.
Yes, but while I can choose to log in with facebook, or google, or whatever, it appears that Apple are mandating that app providers use the Apple sign-in, which means app users no longer get to choose.
Unless I'm misunderstanding what the mandatory part is.
They are mandating that if you offer any other authentication provider (e.g. Facebook, Google, etc), that you have to offer Apple sign-in as an option as well.
The option is mandatory. End users using it is optional.
If the policy is "if you offer one or more authentication providers, you must include Apple sign-in", while it's still a little harsh, I think it's much more defendable and reasonable.
Only if they grandfather existing apps. We made the decision a long time ago to support FB login. That decision now requires us to either stop having an app in iOS, remove FB login (which a good portion of people use exclusively), or implement a new authentication provider _that won't work for people that already have an account with us_.
Again, the tech is fine. The strong-arm is indefensible.
Why would someone already authenticating via an existing identity provider be affected by you adding an additional identity provider?
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.
I expect the disposable email will end up in Keychain, and you can export from there. Not the most user-friendly thing, but doable. Well, at least on a Mac.
