[sturgill]

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).

[ryandvm]

"+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.

[bscphil]

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 [e-mail] gets sent to my inbox at Fastmail. [e-mail] 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.

[JustSomeNobody]

This is called subdomain addressing or subdomain stripping in case anyone wants to look up how to do this with your hosting provider.

[cbsks]

Per what spec? Having “a+b” deliver to address “a” is Gmail specific, as far as I know.

[tekknik]

It’s called subaddress extension: https://tools.ietf.org/html/rfc5233

Can confirm what parent poster is saying, we remove them on signup.

[nprateem]

I wonder whether that's GDPR compliant. If I give you permission to contact me on [e-mail] and you strip off +alias and then contact me on [e-mail], 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.

[frenchy]

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.

[nprateem]

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.

[tekknik]

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.

[nprateem]

Fair enough.

> 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.

[hutattedonmyarm]

> we remove them on signup.

But why?

[tekknik]

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.

[cachvico]

RFC 5233: Sieve Email Filtering: Subaddress Extension

https://tools.ietf.org/html/rfc5233

Not Gmail-specific. Labels however are ;)

[cbsks]

Thanks! I did not know it was a standard!

[alanh]

Gmail ignores (or ignored?) dots on the left of the @, so [e-mail] and [e-mail] and [e-mail] all went to the same inbox. That is gmail-specific.

[CaptainMarvel]

If you email me without the +merchant postfix I gave you, your email will go into the trash without me even knowing you sent it.

[philwelch]

Apple's auth does allow you to use the canonical email address associated with your Apple ID rather than a one-off generated by Apple.