Hacker News new | past | comments | ask | show | jobs | submit login

Obfuscation of the email address is an explicit choice by the user when using Sign in with Apple. It’s not something forced by the service. If users are choosing to do that, it says something about the lack of trust the users have with whatever they’re signing up for.





Not necessarily. I have an app with 1,000 users, and about 99% of them choose to obfuscate.

My app isn’t untrustworthy at all either. It’s an experimental app which attempts to let users create an iOS app on iOS. My suspicion is that people choose to obfuscate because it’s what’s selected by default.


It's also likely that 99% of users have no reason to share their email with you. Also, your app is extremely untrustworthy. It sounds like a random app you find by searching for key words. You're not Microsoft or Google, you have no reputation or credibility. They have no relationship with you, they don't know you, they likely have never interacted with your company before this.

If I need an email to verify I'm not a bot, that's fine. But if a trusted 3rd party can verify I'm not a bot, then the only reason you would want my email is to do something unethical with it: namely, use my data in a way that I never intended gave you permission to use it.

Being default probably helps, because most people don't know they're doing with software and just accept the defaults assuming they're best practices. If the default were to share the email, you might see more people sharing email, but I would argue it's because people don't know they can and should obfuscate it.


> If I need an email to verify I'm not a bot, that's fine. But if a trusted 3rd party can verify I'm not a bot, then the only reason you would want my email is to do something unethical with it: namely, use my data in a way that I never intended gave you permission to use it.

This was addressed in the article. If the service provider does not have your email address, they are severely hampered with regards to customer support.


> If the service provider does not have your email address, they are severely hampered with regards to customer support.

No, they're not. They're just relying on email as a user verification methods as it's the easiest approach. Other methods are possible.


> No, they're not.

Did you read the article? It seemed very clear to me that they had significant issues with customer support past just verification.

And what would you suggest as an alternative way to identify the user, anyway? Any alternative method of authentication seems doomed to fail - using a real name runs into issues with duplication, requiring users to set a username would likely require significant changes to the platform to support it and lots of people would forget it when they couldn't get their preferred username, and having a customer support code inside the app wouldn't help when the user loses access to their account.

It seems like there are alternatives, but none that the average user who signs in with Apple and needs to contact support will be able to get past on a consistent basis.


A simple "let me email a 6 digit alphanumeric code to your icloud email" 2fa style identification would cover anybody who is able to open their mailbox. Not perfect, but gets around some of the problem.

I actually think the customer experience of "I switched from apple to android and now I dont know any of my usernames" is a bigger issue. If apple wants Sign in with Apple to work, it needs to behave a bit more like an agnostic 3rd party password manager, work on every platform, and have ways to interact with it on any device. They should release Keychain as an Android app and Chrome extension, and allow you to use it to see your Sign in with Apple data.


Verification is only one part of the problem. The other is communication.

If I can't contact my customers, how do I support them (e.g. report a security problem)? If my customers can't communicate which account is theirs, how do we help solve problems? Email addresses and/or phone numbers make this a lot easier.


Simple, have them create a user id, and/or expose a "support id" somewhere in the system that lets you tell the support person which account record is yours.

I never want "communication" from an app developer unless I initiate it.


What about when you lose access to the account and don't remember what string of numbers you had to use after your preferred username because it's not a universal identifier that only you can use? In the case of the support ID, you'd need to be able to access the account to even view it.

tl;dr email isn't needed, people are just used to it.

It's a fair point, and perhaps its one that the likes of Apple SignIn should solve. On the one hand, even Microsoft and Apple send me heaps of spam under the guise of "communication" and I don't want them to have my email address if I can avoid it. The OP says they have trouble with support, but they can (and it sounds like do) tell people to just check their Apple email. Most places that I contact for support require me to put in a contact email for that ticket because people use throw-aways anyway. As for security problems, well I'm glad you're one of the few companies to actually disclose security breaches. But if the information on the website is actually sensitive, then there should be additional checks to begin with. If it's CC info, you should contact the CC company, there should be 2FA, there should be more than an SSO service, which already prevents the biggest and worst security breach of leaked passwords. In short, I doubt the need to contact a customer unsolicited is so great, common, or difficult as to require that a user disclose a non-obfuscated email address, which people already commonly have throwaways for. And the reason they have throwaway accounts is because 99% of the time, when I give someone a ...@spamgourmet account or whatever, that address gets spammed, even though I told them not to put them on the mailing list (because they share the email with third parties, or just plain ignore it).

The tradeoff is a bad one. I do not have sensitive information on Reddit that is not public. A private investigator could probably deduce who I am by looking at my Reddit posts, figuring out where I live, where I went to school, what family members I have, what my job is. They don't need to contact me urgently about a security breach. You can say when I sign on and lock my account until I acknowledge it, but it's not urgent. Even a website that might need sensitive information and, for some reason, doesn't want to require I actually verify my identity for real to upload that sensitive information, that doesn't mean I'm using the website in that capacity and should give up identifying information in case I need to give up identifying information later and you need to contact me that my information has been leaked.

The perspective is worth thinking about, but I'm unmoved that it amounts to pushing the needle to "you need my real, primary email address." I believe the tiny, tiny minority of companies that actually need that and shouldn't just rejigger their system to better security and privacy practices to start with can find reasonable workarounds or resort to mild inconveniences like requiring a callback number on support.


This is anecdotal but if I could chose not to share my email with things I sign up for, I wouldn’t have a gmail address used solely for signing up to things. I can’t think of a single thing that I’ve ever signed up for that I actually wanted to have my email.

So sure, it’s default, but unless I’m unique some people will see the default and go “why isn’t every 3rd party login like that?”.


My recollection is the first time I used Sign In With Apple it forced me to choose (no default), and after that it defaulted to my last choice.

I expect 99% are obfuscating because that’s the sensible choice to make. Giving an app my real email should only be done if there’s an explicit need for this, such as being able to log in from non-Apple devices.


You make a good point, and in general I agree, but it introduces additional headaches if I think about logging in from a non-Apple device later.

You actually can support Sign In With Apple from arbitrary platforms, using the JS API.

https://developer.apple.com/documentation/sign_in_with_apple...

This is obviously the most useful for websites, but Apple’s developer site links to this with the descriptor “for web and apps on other platforms” so clearly they’re ok with Android apps using it too.


I agree with the sibling in that defaults are powerful.

However, I've never built anything directly used "by the public", nor am I very familiar with how Apple Sign in works.

So I'm wondering, as the developer of a trustworthy app, what's the drawback in the user giving an obfuscated address?

Is it not possible for you to contact the user using this address? Does the user have to manually allow getting mail to this address or somehow jump through some hoops to read it?


As explained in the article a lot of people use the iCloud mail for their apple account and they don’t check it because they use another provider main mail address. Furthermore if they contact them from their email for support they have no way to associate it with the mail registered in the system, so they can’t help them. If you ask me they seem both very valid points.

Can't they just ask the user to open the app and send them some identifying number they can find in the ui?

Not if they have no ability to reply to the user in the first place. The user may also be contacting support because they lost access to their account and not be able to access the identifying number.

If the user emails them they can certainly reply. It's just a matter of showing their email somewhere. The ID can be shown before the user logs in. That would not be less secure then relying on the email to reset the password. If someone is able to access the user's unlocked phone, they probably can access their email account too.

> if they contact them from their email for support they have no way to associate it with the mail registered in the system, so they can’t help them.

Thanks for the clarification, I didn't think of this scenario.

This looks like a pretty big problem, as I can imagine a situation where the user doesn't have access at all to the app and may not have kept the initial email with any identifying info.

Isn't there an easy way for the user to know which obfuscated address was used for which app?


Do you have a number for “a lot of people”? I am very skeptical of this data point.

This email address is used for a lot of communication with Apple, e.g. receipts from App Store.


Receipts from the app store go to my gmail account.

I bought my iMac on the Apple store, and the receipt was also sent to my personal account.


Why do you need my email address? I wouldn't give it to you just so you can have bad database security and then have my email dumped somewhere.

Why is it a problem for you?

Most likely. Never underestimate the power of defaults

>My app isn’t untrustworthy at all either.

That's up to the user to decide. For me trustworthy = something like Basecamp, Amazon, etc, not some random small app.


> That's up to the user to decide.

> trustworthy = [...] Amazon

Good point, because your example includes one of the few companies I don't trust at all.


different types of trust.

Trust not to misuse.

Trust not to leak in a breach.

Realistically, my email address is something I trust Amazon with both of, because email isnt how they spam me, they are smart enough they can identify me without my email address, and I expect their security to be more hardened and battle tested.


Yes i obfuscate by default but as a user it’s also not immediately apparent to me that this would cause unintended side-effects. It’s really up to both the app developer and Apple to enable good user experience by designing around human behavior, rather than trusting the user can always make those decisions.

"My app isn’t untrustworthy at all either. It’s an experimental ..."

There is a big contradiction in there...

Everything experimental is by definition untrustworthy.


I choose to obfuscate because I don't want every app I download to have my email address.

There's two kinds of "obfuscation" at play with Sign In With Apple.

One is true obfuscation - "hide my email". That would be a poor choice for use with any app you hope to have an ongoing relationship with, I'd think.

The other is just the use of iCloud email addresses, detailed in the post, which seemed like a very good and concerning point. It's also much less likely to be a problem with FB or Google login.


I can have an ongoing relationship with an app without that app’s developer having an ongoing relationship with my inbox.

Sure you can. But they explain why it's not applicable for their use case.

And I would literally blow up at Apple, if they forced this on TripIt... Sharing trip information is done using registered email. And iCloud email is crap.


Sharing trip information is done using registered email.

Could you provide any details? How is such "registered" email different than any other email?


"by using the email account you registered with"

not GP but like, ok, why can’t that be sent from any other email (user-provided or otherwise)?

My guess is that it's being send to the email the user registered with. And 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, so I think it'd be unreasonable to ask a developer to implement a whole second place to put an email just to work around Apple denying access to that information in the first place.

At the very least Sign in with Apple needs to support a request for the user to enter the real email they want to use to be contacted by the app after-the-fact for cases where someone obfuscates their email but then wants access to functionality that explicitly requires their real email.


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. blahblah@gmail.com 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.


Your primary iCloud email address is meant to just be your main email address, including non-Apple email addresses.

"Meant to" doesn't mean "is", and even if 99% of people do what they are "meant to", that still leaves millions of people doing it the "wrong" way.

Yep. I rarely run into people who use their iCloud email, and that goes for both the technically inclined and the average users.

Locking things down like this seems to have some serious negatives that Apple needs to reconsider their approach for.


But you don't need to have your iCloud mail set as the primary mail for your AppleID. You don't even need to create an iCloud mail when you create an iCloud/AppleID account, it's an optional step. I recently created another iCloud test account and it's also not shoved in your face or anything, it's a small little button called "Don't have an email address?" somewhere.

So I don't even really understand how people get into this situation.


The biggest problem is that Apple insists on tying the fake email with your iCloud email, which the vast majority of people don’t use.

If they tied it instead to what people’s normal mail was, a lot of issues would be averted.


They tie it to whatever your Apple ID primary email is. This is only your iCloud email if you've deliberately made one, which isn't the default.

So... I'm having a bit of a hard time as seeing this as not a problem with Apple more than this app company. Apple is obfuscating your email address by default (great!) but is then forwarding that obfuscated email address to an address that they select without asking the user.

It seems like this entire complaint would be solved if Apple prioritized "obfsucated email works for our paying users" (i.e. deliver mail to an address they select) over "create a strong incentive to use our email service if they want to get their precious emails".

I use obfuscated emails all the time, everywhere, by default. But I selected what email address they forward to when I set it up. How does an app maker get the blame for Apple not doing this?

Edit: Now, the app relying on un-obfuscated email addresses for finding contacts I have less sympathy for. There are many other good options for this, and they should work with obfuscated email address IMO. Seems like everyplace I use has no trouble with usernames...


I dunno about that. I literally choose it every time, because why not? It's my default.



Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: