If I understand the model of the hypothetical app referenced above, they send email containing confidential (already, this seems problematic, but let's ignore that) "trip" information to some email address. Within that structure, then sure it's problematic to have to require two different email addresses. Except, you don't have to do that. Don't require an email address to start using the app. Let users enter whatever confidential trip info they want, keep a reference to the resulting DB records in a cookie, and only require an email address when the user wants to, uhh, get an email sent.

Having typed the foregoing, I realize now I'm basically just saying "don't use any third-party sign-in, including SIWA". Maybe it's fine that the ecosystem doesn't always cater to apps of questionable utility...

When you share a Trip with Tripit, or add a traveller, you enter their registration email. [email protected] or something.

> My guess is that it's being send to the email the user registered with

I assumed otherwise because they specifically wrote "sharing". Still, I'm not sure agree with:

> requiring them to provide a separate email from the one they registered with completely defeats the purpose of obfuscating the email in the first place

I can't use most apps without providing an email, whether they need it or not. That's a much worse situation than not being able to use some features without providing one (which still assumes me having no access to or knowledge of my own iCloud email).

When you send an email, there's typically 2 email addresses.

But if you share a trip to a person who's on Tripit - they just get a notice and a record in their webapp.