Live data from Hacker News

Apple Fixes Hide My Email Vulnerability After 404 Media Coverage

404media.co

11–20 of 35 posts

Re: Apple Fixes Hide My Email Vulnerability After 404 Media Coverage

#11
post #2

> Apple told 404 Media it deployed a patch for the issue on July 3, which the company says has fully resolved the issue. > 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 requir…

> The vulnerability affects all users of Mail app, even if they don't use Hide My Email!

If they don't use "Hide My Email" trivially replying discloses their email?

Re: Apple Fixes Hide My Email Vulnerability After 404 Media Coverage

#12
post #3

I have a question I wasn’t sure how to ask HN that is tangentially related to this. I’m the developer of an app where people can add other users to their workspaces, via email. The way this currently works is that your email gets added to the workspace and then when you log in with that email, you get access. Now, this of course fails with “hide my email”. What’s the appropriate/standard way to handle this? Should I…

In general it's bad practice for a user to expose someone else's email address to an application provider without consent (email providers being the one necessary exeception, of course), therefore I would abandon that approach in any case.

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.

Re: Apple Fixes Hide My Email Vulnerability After 404 Media Coverage

#13
post #2

> Apple told 404 Media it deployed a patch for the issue on July 3, which the company says has fully resolved the issue. > 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 requir…

> The vulnerability affects all users of Mail app, even if they don't use Hide My Email! If they don't use "Hide My Email" trivially replying discloses their email?

[deleted]

Re: Apple Fixes Hide My Email Vulnerability After 404 Media Coverage

#14
post #2

> Apple told 404 Media it deployed a patch for the issue on July 3, which the company says has fully resolved the issue. > 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 requir…

> The vulnerability affects all users of Mail app, even if they don't use Hide My Email! If they don't use "Hide My Email" trivially replying discloses their email?

It will disclose your Apple account address even when you received the email on a different account in the Mail app.

Re: Apple Fixes Hide My Email Vulnerability After 404 Media Coverage

#16
post #12
post #3

I have a question I wasn’t sure how to ask HN that is tangentially related to this. I’m the developer of an app where people can add other users to their workspaces, via email. The way this currently works is that your email gets added to the workspace and then when you log in with that email, you get access. Now, this of course fails with “hide my email”. What’s the appropriate/standard way to handle this? Should I…

In general it's bad practice for a user to expose someone else's email address to an application provider without consent (email providers being the one necessary exeception, of course), therefore I would abandon that approach in any case. 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,…

> In general it's bad practice for a user to expose someone else's email address to an application provider without consent

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.

Re: Apple Fixes Hide My Email Vulnerability After 404 Media Coverage

#17
post #3

I have a question I wasn’t sure how to ask HN that is tangentially related to this. I’m the developer of an app where people can add other users to their workspaces, via email. The way this currently works is that your email gets added to the workspace and then when you log in with that email, you get access. Now, this of course fails with “hide my email”. What’s the appropriate/standard way to handle this? Should I…

I've seen this kind of thing fail in so many ways just as a user with a custom domain. Someone adds my real email (the custom domain) to a Google invite and my primary Google Account uses its own email (a Gmail account) that is in no way my primary email address and Google gets confused and won't let me access the thing sent to my real email because I'm trying to access it from my Google Account. (Plus additional variations where my custom domain was briefly hosted on what today is called Google Workspace and some things still seem to be misconfigured to point to shutdown accounts for my real primary address still apparently ghosts in Google Workspace.)

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.

Re: Apple Fixes Hide My Email Vulnerability After 404 Media Coverage

#18

But Apple did not yet walk back that they wanted a single dedicated domain for private emails, privacy.icloud.com, such that it'd be easy for any host to block them.

I'm honestly getting tired of us requiring big corps to do everything for us. Use the private domain. Dont have the account if they block it. End users and consumers need to bite the bullet.

Re: Apple Fixes Hide My Email Vulnerability After 404 Media Coverage

#19
post #3

I have a question I wasn’t sure how to ask HN that is tangentially related to this. I’m the developer of an app where people can add other users to their workspaces, via email. The way this currently works is that your email gets added to the workspace and then when you log in with that email, you get access. Now, this of course fails with “hide my email”. What’s the appropriate/standard way to handle this? Should I…

I've seen this kind of thing fail in so many ways just as a user with a custom domain. Someone adds my real email (the custom domain) to a Google invite and my primary Google Account uses its own email (a Gmail account) that is in no way my primary email address and Google gets confused and won't let me access the thing sent to my real email because I'm trying to access it from my Google Account. (Plus additional var…

I've already had to add code to "normalize" addresses with dots and plusses. That should've been my first sign to move to a different design.

Re: Apple Fixes Hide My Email Vulnerability After 404 Media Coverage

#20

But Apple did not yet walk back that they wanted a single dedicated domain for private emails, privacy.icloud.com, such that it'd be easy for any host to block them.

I'm honestly getting tired of us requiring big corps to do everything for us. Use the private domain. Dont have the account if they block it. End users and consumers need to bite the bullet.

Private domains aren't really private because they can be matched across data leaks. Fine for tracking senders though.
Post reply on HN