Now, this of course fails with “hide my email”. What’s the appropriate/standard way to handle this? Should I be using urls with invite codes instead of associating the email itself with access? I’m a little hesitant to do that since the code would have to persist in session and the business logic would have to occur on the login portal, since the mobile/desktop apps don’t share web cookies. Is deep linking the answer?
You could implement read-only access to a workspace via a generated link (containing a UUID or similar), like e.g. a Dropbox link. You would store the link IDs with the workspace, and you can implement (user-configurable) link expiration and such. Since links are shareable, these wouldn't be personalized to the recipient. A recipient who wants more than read-only access would still have to create an account with you and ask the workspace owner for write access.
Thanks, that makes sense as a rule of thumb. I'll move towards invite code (and work domain/SSO) based access. It's also a bit awkward to be able to add existing users to a workspace without any sort of confirmation, so my system needs a bit of rework regardless.
That's eternally a frustrating experience. It ranks among the reasons I groan every time someone asks if we can meet in Google Meeting instead of other options.
That's just dealing with one large giant of a company who you would think if anyone would have the software resources to truly untangle email addresses from account assumptions, they would have more than enough resources available.
Lots of little papercuts like that exist everywhere else. I have multiple accounts with various "Pledge Managers" because I gave Kickstarter a specific filtered address but still tend to respond to surveys and other things sent more directly to me with my primary email address. "For my convenience" most of these "Pledge Managers" tie their accounts to whatever email address they get from a Kickstarter export spreadsheet and then assume that each email address is 1:1 useful for marking an account as mine. It's often easier to juggle a bunch of reminder notes in my Password Manager which campaign is with which account with which "Pledge Manager" than to unify accounts. It becomes the opposite of convenience.
I've seen the same thing happen with + addresses, not just custom addresses at custom domain addresses. Add a + to a signup to get autofiltering when you sign up for a service and most services see `accountname+filter@gmail.com` as a different email address than `accountname@gmail.com`. Which is the correct behavior because `+` filtering is a convention not a guarantee/standard. But it again adds complexity in these sorts of "auto-invites" when you are trying to auto-correlate based on specific email address.
It seems important to me to not assume that the address an invite is delivered to is the primary address for that person nor the intended address for their account with you. It may be useful to associate that delivered address automatically as a "secondary" address in some cases, but to insist that it be the primary on the account that results from the invite is a papercut friction for at least some of your potential users.
It depends whether you want to check the invite code against the invitee's email. It very much depends on the application. For most use cases, just verifying the code is fine and accept any email addresses that posses it.
Essentially ask yourself this, if you change the UI a bit and allow any user to sign up with any email, and the workspace joining is done via a code they enter after login, is that acceptable for your product design and security posture.
> 404 Media is not revealing the exact details of the vulnerability because it can still be exploited as of Monday, when 404 Media verified the issue with one of our own hidden email addresses.
However, based on the current article:
> Now Apple says it has been fixed, we can add that, in simple terms, it required sending a target Hide My Email user a message that got rejected as spam. “We don't know how often hidden email addresses were leaked in email logs. For many major email hosts, the leak was triggered simply by an email being automatically rejected as spam, even if it was a legitimate message. Such emails probably didn't make it to your inbox, so you can’t review your spam folder to learn whether you were affected,” Murphy and EasyOptOut co-founder Ben Weiner said in a new statement.
My guess is that if an e-mail was rejected as Spam, the response had the actual e-mail included. However, based on the next paragraph:
> “The bug that caused Apple's Hide My Email to leak hidden email addresses to senders has been fixed. However, we don't think the risk to Hide My Email users has been eliminated. Because non-malicious emails could bounce, revealing your hidden email address, and because mail transfer logs are often retained, we'd assume that any hidden email address linked to a Hide My Email address created before July 7, 2026, may have been exposed and could still be in third-party logs,” they added.
It seems even bounced e-mails could leak your actual e-mail.
> Now Apple says it has been fixed, we can add that, in simple terms, it required sending a target Hide My Email user a message that got rejected as spam.
I would note that Mac Mail app (I haven't tested iOS Mail) still has an Apple Account email address disclosure vulnerability, though this requires the user to reply to a maliciously crafted email. The vulnerability affects all users of Mail app, even if they don't use Hide My Email! https://lapcatsoftware.com/articles/2026/7/9.html
If they don't use "Hide My Email" trivially replying discloses their email?