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

As they point out at the very bottom, all their arguments apply to all third-party sign-ons, so they're removing Facebook as well.

So there's nothing specifically against Apple, despite the title seeming to imply it -- just that they're taking the move right now because of Apple's new policy coming into effect.

I've got to say, I really wish there were a way to know whether I already used Facebook, Google, or Apple to log into a site or app before. My password manager is usually pretty good at letting me know if I've got a "normal" account with user/password, but it doesn't do anything to remind me if I ought to log in with one of the other services.

Every time I'm occasionally asked to sign into Spotify, Pinterest, Medium, Quora, etc. -- it's like, I'm pretty sure I've signed up with something before, but who even knows which one, or multiple?

If password managers could start saving that you've got accounts associated with Apple/Facebook/Google and highlight the relevant button on sign-in, it would be a big feature improvement.






"all their arguments apply to all third-party sign-ons"

No they don't. Other sign-on options don't obfuscate the email address.

They are likely removing FB login as otherwise their next app update will be rejected by Apple for supporting third party login but not Apple 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.

That may be a reason in the future, but they did specifically mention a couple really good reasons to dump Facebook login now:

> "That’s become even more true as time goes on, since Facebook constantly seems to be upping the ante with creepy privacy practices. We use the Facebook SDK to provide login functionality, and every new release of the SDK seems to add new tracking options that are turned on by default, which we have to take action to disable. Furthermore, the Facebook SDK has quality problems, and recently caused a huge number of iOS apps to crash due to a misconfigured server."


As a user I can't see why any random app needs to know my true email address.

From the article:

> If a customer contacts us asking for support, and we need to look up something in their account, typically we can just ask them for the email address on their account. But with “Hide My Email” that wouldn’t be easily possible, because the customer would have to figure out the privaterelay.appleid.com email address used for their account.

> Furthermore, if there are platforms where AnyList doesn’t support Sign in with Apple, like Android, and someone wants to log into their account, they’d have to know their privaterelay.appleid.com email address. (And that certainly won’t be easy to find if you no longer have an iOS device.) And then they’d have to create a password with us, since they wouldn’t be able to sign in using Sign in with Apple.

> Finally, for a service like AnyList, which is heavily focused on sharing lists with other people, the “Hide My Email” option greatly complicates collaboration. Typically, customers share a list by typing in the email address of the person they want to share with. If that person already has an account, the list is instantly shared. But with the “Hide My Email” option, your spouse or friends obviously won’t know your privaterelay.appleid.com email address, so when they enter your email address, our systems will believe that you don’t have an account. At that point, you’ll get an email from us asking you to create an account. If you accidentally create a new account, it won’t include the work you’ve done in your existing account created via Sign in with Apple. And if you manage not to make that mistake, then there would be a link between your email address and the account you created with Sign in with Apple, negating the value of hiding your email address.


For the first point, the app can explicitly tell the user what their login is, or otherwise assign some unique identifier the user can use when contacting support. The app can also offer to contact support for them, which can pre-fill the user identifier.

For the second, that’s entirely the user’s choice. Your app can also allow them to associate a new email address for this purpose (which strikes me as exactly what you actually want since the real unstated motivation here is getting the user’s email).

For the third, don’t make me type in someone’s email. The exact same issue as described happens if they have multiple email addresses too. Just let me use my OS’s sharing mechanism to send a special link that they can open to establish the sharing connection. An invite to share, as it were. Not only does that solve the problem, it’s significantly more user-friendly.


> For the second, that’s entirely the user’s choice. Your app can also allow them to associate a new email address for this purpose (which strikes me as exactly what you actually want since the real unstated motivation here is getting the user’s email).

So the solution here is for a developer to add a bunch of code to their codebase on at least 4 platforms just to get to the same exact functionality and level of privacy, but with a worse user experience?

> For the third, don’t make me type in someone’s email. The exact same issue as described happens if they have multiple email addresses too. Just let me use my OS’s sharing mechanism to send a special link that they can open to establish the sharing connection. An invite to share, as it were. Not only does that solve the problem, it’s significantly more user-friendly.

As a user, I find that functionality to be incredibly clunky by comparison (on all platforms). It may be moderately better on iOS than Android, but even then Anylist and others are running multiplatform apps. If I'm using a computer and I need to manually copy a link, open my email client, compose a new email, type the subject and a message, paste the link, and hit send, that feels dramatically more cumbersome than just entering an email address and hitting "share". It also takes a good amount of new code to implement something like that on an existing system that uses email-based sharing, which I don't think developers should have to deal with just because Apple built a lousy login system.


> So the solution here is for a developer to add a bunch of code to their codebase on at least 4 platforms just to get to the same exact functionality and level of privacy, but with a worse user experience?

You need to support letting the user change their email address anyway. Letting them change it from the privacy forwarding email to something else is no different. And that shouldn’t even interfere with using Sign In With Apple going forward because surely you’re using the user’s unique identifier from Apple to associate the sign-in with your service’s user.

Also FWIW you can use the Sign In With Apple JS approach on non-Apple platforms. This is obviously useful for web, but Apple’s developer site says it’s “for web and apps on other platforms” so you could use this from Android too, it will just take some more work.

> As a user, I find that functionality to be incredibly clunky by comparison (on all platforms).

As a user, I have never connected with someone on a service by typing in their email address. Not only do people routinely have multiple email addresses (e.g. work and personal), but people also often use unique addresses for services (e.g. plus addresses), so it’s not at all a reliable mechanism.

> If I'm using a computer and I need to manually copy a link, open my email client, compose a new email, type the subject and a message, paste the link, and hit send

Why would you do all this? The service can offer a mailto: link that pre-fills the body, so all you have to do is click it, type in the recipient’s email address, and hit Send. And this lets you customize the message as appropriate. Better yet, on Apple platforms you can use the built-in share functionality, including on web with the Web Share API[1].

And if you really don’t want to do all of that, you could have me enter an email that you send a special link to rather than looking up in your user database. That’s still not great for me as a user because it means I’m giving you someone else’s email address, which I don’t want to do, but it’s better than nothing.

The simple fact is, if your sharing mechanism requires me to know the email address someone else has already used to sign up for your service, it’s a crappy sharing mechanism.

[1] https://caniuse.com/#feat=web-share


What kind of solution should apple have made then, that would protect user privacy to the same degree?

> For the first point, the app can explicitly tell the user what their login is, or otherwise assign some unique identifier the user can use when contacting support. The app can also offer to contact support for them, which can pre-fill the user identifier.

as thomaslord said, this is an enormous overhead, where a lot can go wrong.

> For the second, that’s entirely the user’s choice. Your app can also allow them to associate a new email address for this purpose (which strikes me as exactly what you actually want since the real unstated motivation here is getting the user’s email).

Even more overhead, and more data to manage.

> For the third, don’t make me type in someone’s email. The exact same issue as described happens if they have multiple email addresses too. Just let me use my OS’s sharing mechanism to send a special link that they can open to establish the sharing connection. An invite to share, as it were. Not only does that solve the problem, it’s significantly more user-friendly.

For native only apps, this would also add an additional overhead, as you need to develop a server to handle this.

The point is simple: if you want to protect your email address, that's on you. I personally use a different email address for each service, because it's important for me. But I don't expect everyone will bend over backwards to accommodate me, and neither should you.


And when you're using the web app on a desktop? There's no easy sharing mechanism there.


Email, Telegram, WhatsApp, etc, etc. Lots of them.

Because it's your identity. Login systems have moved away from the 'username' concept that we used to use, because it was another thing we could forget. Email addresses are inherently unique and allow identifying a person for support calls or login or whatever.

I'm not saying this is necessarily a good thing, but this is how things work and I don't have a better suggestion.


It used to be true that during a Facebook Connect session the user was asked if they wanted to share their email or not. I faintly remember you could even choose a proxy fb e-mail aka "fake email". Did they remove that feature?

A party in OAuth authentication can request some obligatory information, and if email is part of it, you won't be able to deselect it.

In general, sites use email as an indication of a unique, real person. I imagine most of them do not really care about it afterwards, which is why the SSO systems even work (though, they can demand an email too).


It was not that Facebook allowed the user to deselect the e-mail address from what would be shared. Rather, it allowed them to randomly generate an e-mail address to share with the other party. I think messages sent to this address were forwarded to the user's Facebook inbox.

And to answer scarlac's question, yes, they removed this feature a very long time ago.


Ah, thanks for the correction! :)

They don't obfuscate the email address you use with them.

I don't share my "real" email address with Facebook.

My Google account isn't my main account, it's a throwaway I use for things that require email to sign up.

This is a general problem for all OAuth IdPs.


> I don't share my "real" email address with Facebook.

Don't worry, they know it anyway.


My gf googled a Mexican restaurant neither of us had been too on her phone and when we got in my truck literally 5 minutes later android auto maps on my phone suggested it as a destination. If they can do this, they can get your other email addresses.

Wait, why? If both of you have your location info turned on then this seems like a trivial correlation to make, especially since both of these are Google's own services.

You don't find this creepy at all? She googles something on her phone. Gets near me, and my phone suggests driving to the location she googled? We aren't on the same account or anything. Google just assumed that I wanted to go where she wanted to go and shared her private searches with me. What if she had gotten in the car and planned parenthood had come up as suggestion?

Esp so since Android Auto is just your phone on your car's screen.

Also other login providers haven't done massively stupid things like not authenticate the actual email address when issuing tokens... like common who in their right mind would want to adopt a new service with a piss poor security reputation for a critical security sensitive leg of their stack?!

Nor do they demand you implement their SSO system if you use any SSO or your app would not be available.

That's a pretty big argument specifically against Apple!


Additionally many other 3rd party login systems have been around much longer than Sign in with Apple, which was another strike against Apple for the author.

Surely you can’t hide your email from apple itself.

You can't; the design behind Sign in with Apple is that you've already trusted them with your email as you're using it to buy apps from the App Store.

Trusting them to protect your arbitrary data is a completely different scenario; there’s just more concentrated risk (i.e. your identity is just gone when Apple gets taken).

Having had this same problem multiple times, I actually made it a point to save a “login” for those sites that when I autofill it reminds me which auth service I’ve used.

Username: Log in with FB

Password: <blank>


Neat trick. Some websites don't even bother giving you any choice for traditional username/password input though.

It's just a further example of the software / online experience being so...fluctuating as a whole. Which has its pros and cons. Pros being freedom of visual and interactive expression. Cons being lack of expectation.

My router doesn't accept a username at all, which actually makes a bit of sense since there's only one 'account' on it. Unfortunately, this means that neither the browser nor LastPass will save the password. My previous router allowed me to change both the username and the password, then pre-populated the username field with whatever I'd entered (but didn't disable the field), which I always thought was odd...

In that case, I just click the icon for my pw manager (1Password in this case), and the modal shows me the same message.

Some places require no additional info from you.

There are good use cases where third party logins are good enough.


I do something similar with a generic password manager.

I've tried pinging the developers to support the idea directly, but I've been met with incomprehension.

Not sure if I'm explaining it wrong, or if it's way more work than I'm anticipating.


Try linking them to this thread? I feel like it sums everything up in a way that a dev would understand.

Perform an audit on yourself. Both Facebook [1] and Google [2] have pages where you can check third-party apps that you have connected with. You might be surprised what you find.

[1] https://www.facebook.com/settings?tab=applications&ref=setti...

[2] https://myaccount.google.com/security


> As they point out at the very bottom, all their arguments apply to all third-party sign-ons, so they're removing Facebook as well.

Nope, some of them also apply to Facebook, and Facebook has the additional destruction of privacy concern. They have to remove Facebook or support Apple too because of the policy and have chose neither instead of both.

Some of their concerns specifically don’t apply to Facebook/Google/anything directly tied to your real email that you’d otherwise choose to sign up with. You add a bit of complexity to your database to record different login types, but you can easily reconcile them to an existing user if the emails match, and provide the features they want like searching for a user by email.


I cope with this confusion by avoiding third-party login whenever possible. Why volunteer additional information about myself to Google or Facebook?

Because you can frequently avoid account creation, setting a new password etc if you click “sign in with google.” It’s a tradeoff but if you don’t see any value in it you maybe haven’t used it- it’s convenient.

With a password manager though, I avoid having tradeoffs in the first place. I get some amount of anonymity by separating my accounts, and it's trivial to login to sites with the same amount of clicks as with third party sso.

Password manager doesn't stop you from having to fill in a bunch of stuff. Like yeah, it's only a couple minutes, but if it's for an app you'll use a handful of times in your life, just hitting that G will be much nicer.

Most of them have a hotkey for fill out + submit form.

Registering a new site on PC browser with password manager is fine but on mobile with password manager is bother. It won't register new ID/password automatically.

Chrome on Android is persistently annoying about wanting to save new IDs, and will also try to save logins for apps. That gets turned off fairly quickly, as I use Bitwarden, which _also_ prompts to add new accounts when I sign up or log in.

It's not foolproof, but given I'm generating the password in Bitwarden anyway, it's not the end of the world if it doesn't catch it.


It's convenient right up to the point where I need to get back into an account but forgot if I used it or not - which is exactly the point of the parent.

I too have struggled to remember which third party sign-on I used (or if I used a native sign in), so now I avoid them every time, too.

They're literally only convenient if I want to have an account that I'm happy to 'throw away' or, to accidentally create duplicate accounts for the service.

For anything where I'm actually paying, they're a nightmare. Oh, did I sign into this with one of my google accounts? Was I crazy enough to use facebook? Or which of my emails did I use?


I don't have any metrics to back this up, but I would assume most websites that use these third-party login systems, still pull down your email address and create an account for you based on that. So it stands to reason, you if you used the same email for all Facebook, Google, Apple, you could sign in with any of them and maintain one account.

I suppose that's a huge assumption, but that's how I would do it if I was developing against them. That said, it doesn't help w/ the "Hide my Email" or the default icloud.com email addresses people don't realize they're using.


Spotify is a PITA for this. And there is no easy way to migrate to a "non facebook" account your playlists and stuff.

That is why my mom and my grandma use "sign in with facebook".

But if you have a Password Manager, then it is literally a single signon solution in and of itself, without the sacrifice of privacy.


Also there are services that log you out after some time. You aren't doing anything wrong, you're simply using the service, but at some point you open it and see a login form. Now, I don't understand why do sessions have to have a lifetime at all, this is terrible UX, but clicking one button to log back in instead of actually typing stuff on the keyboard is much more convenient.

Isn't that what a password manager is for?

I guess a lot of times it’s for security or to minimize storage over time. Sometimes you are only logged in for the browser session, so if you close it, it removes your session. Most smaller sites do have the remember me button to opt in for longer sessions and do not implement a session renew feature.

> Sometimes you are only logged in for the browser session, so if you close it, it removes your session.

Probably, and this shouldn't be a thing. Except maybe for banks, but even then, it's debatable. Here's a handy list of cases when I want to be logged out:

1. I click the log out button.

Which I don't ever do either, because it's my personal device.


I use third party identity providers for all webservices I offer. Not that many because I am not web dev. People love it but I wouldn't use it myself. Of course the identity provider could extract information about the services you use, I wouldn't like that for most platforms to be honest not for the net as a whole.

Account creation sucks, but I prefer it to letting an ID provider know about it. Although I would trust real third party ones like auth0 more than Facebook or Apple, even if they have a more focused business model.


I've had services ask me to create a username and password after I "log in with Google". I usually give up at that point.

I think that's the entire point of the parent's (and my as well) position: the so-called convenience of not having to type a few more things to set up an account is not worth giving more data and control to FB/Google/whomever.

They're likely just answering the question you posed... An explanation for _why_

Yes! Especially once you start juggling multiple accounts for different companies and projects. Becomes a guessing game, and each wrong guess creates another account magically. Infuriating

Time to create a new service to unify all your SSO accounts! One single SSO!

OpenID would have done it, but Facebook and Google neutered it in favour of OAuth so they could cement themselves as primary players.

It's been some time last I checked, but isn't OpenID Connect provided anymore by Goog/Fb? Why wouldn't that be a reasonable choice if you wanted a protocol that, from the dev side of things, allowed you to uniformly target external auth providers, or your own?

OoenID Connect is different. Its basically just OAuth2, and google/fb require the ap developer to register their app with google/fb in order to authenticate users.

Whcih is pretty bad for both developers and users, as a user I cant run my own identity provided and as a developer I have to spend time setting up accounts with ever identity provider i wish to integrate.

Original OpenID just let me as a user use a URL as my identity, so I could use any identity provider I wanted, including running one myself.

EDIT: There is a specification for dynamic client registration but nobody implements it as far as I've been able to tell.


Here comes SSSO! I can hardly wait!

Of course, there may be competing SSSO solutions...


We could have a Simplified Experience Single-Sign-On, or SESSO. Italian developers would adopt it enthusiastically.

If only there was a decentralized option that has already solved this... We could call it OpenID or something like that... Oh, wait..

You also have IndieAuth that is slowly gaining more adoption.

https://en.wikipedia.org/wiki/IndieAuth

https://indieauth.net/


Yes! and then I just sign in once into my single SSO signon!

And if you create an account accidentally, there’s often no way to undo that.

Next, if you don’t add a second-factor with to it, it becomes a ticking countdown until the account is compromised.


> So there's nothing specifically against Apple, despite the title seeming to imply it

From the article...

> In addition to these customer experience problems that are common to all third-party login systems, Sign in with Apple introduces several more that are unique to it.


I create dummy logins in my password manager for sites that use external auth. Username of just “LOGIN WITH GOOGLE”. Hacky but it makes me smile every time it gets filled in.

> So there's nothing specifically against Apple

The one thing that is specifically against Apple is the new App Store policy that if an app uses google/Facebook sign in, the app _must_ also use Apple Sign In.


>My password manager is usually pretty good at letting me know if I've got a "normal" account with user/password, but it doesn't do anything to remind me if I ought to log in with one of the other services.

Doesn't it somewhat defeat the purpose of using a password manager if you use one account to sign into multiple sites?

Sign on services from main accounts seem like security flaws. If you use one main account resonsible for all your 'main things' to sign in to all the 'other things' that gives one vector of attack to enter or compromise 'all the things'.

Password managers exist to make the management of many things as easy as one thing, not to adapt to using one thing for everything, that's pretty much the opposite of what a password manager does.

Sign on services don't exist for convenience, despite being marketed that way, they exist to increase data collection abilities. Password managers exist to make using multiple accounts as easy as using a sign on service, that's the point. They should be separate from existing providers. They are an alternative to them.


First of all, you need a password manager no matter what even if you use Facebook etc., because not everybody supports Facebook etc.

Second, it often still takes a lot of work to create a new account on a site, even with a password manager. Selecting a username, discovering it's taken, selecting another one, generating a random password, pasting it into a second field to confirm the password, unchecking "send me updates", going to my email to find the confirm link, blah blah blah.

If I just want to do something quick on a site (like see a Quora answer or Medium post), it can be far easier to just click "log in with Google" and see the content in 5 seconds rather than 5 minutes while you wait for the damned account confirmation email.


The username dance is why I often use a random string as a username. I was delighted to discover that my first name was an available username at my bank, until my login kept getting locked due to too many failed login attempts. I had a 15-character random password, so no danger there, but repeatedly calling to have my account unlocked was a pain. I changed my username to a different 15-character random string, no problems since.

Tangent: I signed up for a US TD account recently (in person). They had me write down the username I wanted, so I used LastPass on my phone to generate another random username. They obligingly made me an account with username "ajdgsbrjcobsdhfwvfk" - and password "tdbank123". Yes, I was required to change it on first login, but no, there was no attempt to verify that I was the one doing the changing (birthdate, SIN, etc).


> Doesn't it somewhat defeat the purpose of using a password manager if you use one account to sign into multiple sites?

Yes. Password managers exist to solve the problem of credential reuse; third-party login exists to implement credential reuse. They are fundamentally opposed.


The credentials are at least not in multiple databases and stand some chance of being more secure, so it’s not as bad as with direct credential reuse, but yes, if you do compromise that one identity provider you’re in big trouble.

With Social SSO, you essentially are passing the trust from some random company getting hacked and revealing your re-used password, onto the shoulders of internet giants like Facebook, Google, Twitter, Apple, etc and putting the trust on them, that they know what they are doing in terms of security.

I still agree that they are variants of the same fundamental problem (a single credential protects all of your logins) and that Password Managers are a vastly superior solution to this problem.

But it is worth pointing out that for the layman, using Sign in With Facebook/Apple/Google, is better than single credential re-use.

When I say "layman", I mean people like my mom and grandma. I have tried to get my mom to use a password manager (went as far as to set it up for her, and pay for it) but she just reverts to a simpler solution (which is Social SSO). If she weren't using Social SSO, she would be using her same Facebook password for every site on the internet. So as much as I personally loathe Facebook, I do trust Facebook for securing my Mom's credentials far more than the random scrapbooking website she is creating an account for. In this case, I am grateful that she is using Sign In With Facebook, even though I would never consider such an action for myself. So it is a small step in the right direction.


Aren't password managers, especially cloud-based ones like LastPass, also the same thing: they hide all your passwords behind a single master password (and a MFA optionally).

Granted, their only job is to secure your passwords, but it's effectively equivalent to a single SSO service from a protection standpoint (if all your accounts would accept that SSO login).


Did you actually bother to read the post? The post specifically explains the headaches associated with Apple sign in. In particular -

"Another issue is Sign in with Apple’s “Hide My Email” feature. With this feature, if you create an account with us, Apple will generate a special email address just for that account. So rather than your email address being john.doe@icloud.com, we will see your email address as something like dpdcnf87nu@privaterelay.appleid.com. While this is an intriguing idea that provides a measure of privacy, in practice it creates numerous support and user experience headaches..."


> I've got to say, I really wish there were a way to know whether I already used Facebook, Google, or Apple to log into a site or app before.

Bookwalker (from Japan) draws a big red box around the login you used last on a given device. Presumably they store a cookie/sharedpreferences with it. It doesn't look pretty, but it helps.


That's useful, but on any device of mine I'm usually logged in anyways. What would be really useful is knowing this when I log into a new computer.

This happened to me recently where, in a hurry and distracted, I logged in with one or another third party auth service then realised that wasn’t the correct login as it displayed a new account.

Not all.

1. Apple obfuscate email - this complicates the support system, and as per them Apple hadn't thought about it thoroughly. Collaboration is obstructed. Password recovery is not an easy process. 2. Cross Platform - The post states that Apple vaguely says that sign in on Android is possible, but doesn't state how it is to be done.


>Apple vaguely says that sign in on Android is possible, but doesn't state how it is to be done.

They do?

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


> all their arguments apply to all third-party sign-ons

What about the argument that users check their gmail addresses regularly but rarely check their icloud email addresses?


> "I really wish there were a way to know whether I already used Facebook, Google, or Apple to log into a site or app before"

You can. On each of the places you mention (Google and Facebook, certainly), somewhere in a settings page/window, you'll find your list of 'authorised apps'.

These will be a list the login systems to the third-party sites you've used to log in with.

You should then see a way to 'revoke' their access to your data.


That doesn't solve the problem. You would have to go to every method to figure out which one it might be listed under. It needs to be in the browser/password manager to tell you which service was used.

TBF if single sign on is implemented correctly and you use the same email address across your accounts then it shouldn't matter which SSO you're using.

When you log in for the first time it should request permission to "see your email address". Then you authenticate with your provider and get redirected back at which point the website should create an account for you on behalf of that email address. If next time you log in again via a complete different provider which has the same email address then it should just work. I mean that is the whole point of this...


> As they point out at the very bottom, all their arguments apply to all third-party sign-ons, so they're removing Facebook as well.

Nope, not all their arguments. Only some.


This is as close as we got trying to do it from the app itself: https://www.lukew.com/ff/entry.asp?1906

I absolutely agree that password managers could remember this stuff. Single-signon is pretty easy to identify and you could setup the relationship.


As I would liked your approach in other times, wouldn't it be a bad one in today"s privacy matters/GDPR and being able to enumerate your database?

Paperspace has this with their Google integration. And I've implemented this pattern before in web dev.

You return to the site and if you have logged in with social media site before, and it detected you are still logged in, it will auto login for you.


I worked on a product that can do that (Google Smartlock for Passwords) but these “identity provider” hints were extremely confusing to both users and developers. The UX definitely could have been better but overall I just don’t think it works.

I don't support social login anymore. It's better for the customer.

> As they point out at the very bottom, all their arguments apply to all third-party sign-ons, so they're removing Facebook as well.

That section of the post was surprising. If they're not supporting Sign in with Apple, then obviously they're going to remove support for all other third-party sign-ons, because those third-party sign-ons are what trigger the obligation to support Sign in with Apple.

Ending their post about "why we won't be supporting Sign in with Apple" with a note that they're also ending Sign in with Facebook on the merits of third-party sign-in is quite disingenuous. It doesn't matter at all what they think about the merits of Sign in with Facebook; those thoughts are completely irrelevant to their decision.




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

Search: