A lot of the points they make here are real points, and I think AnyList has validity in their actions. I also think it’s not as unmanageable as it seems. Let’s analyze this quote, from the article, as it highlights what I imagine are a big crux of this issue: > 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 addres…
Why we won’t be supporting Sign in with Apple
361–370 of 485 posts
Re: Why we won’t be supporting Sign in with Apple
#362Earlier quoted context omitted.
"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.
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?
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).
Re: Why we won’t be supporting Sign in with Apple
#363Earlier quoted context omitted.
> Since you know this to be the case, why not have an onboard if flow they Sign In with Apple where you have them A) choose a visibility email used for sharing/communication etc. and B) allow for this email to be their backup email? So if they forget their login or whatever you could just transfer the account to this email instead? I'm fairly certain that detecting someone hiding their e-mail from you and then making…
> making them pick a different e-mail I think it's more about _letting_ them pick a different email. While I can understand that AnyList (or any other app for that matter) would want to, on occasion, send marketing emails to users, I don't think any app would, in their right mind, _require_ the user to provide a 2nd email address. But by allowing them to optionally give that 2nd address, they can provide a path forwa…
Re: Why we won’t be supporting Sign in with Apple
#364The device could be programmed to automatically generate new passwords/keys/whatever needed for remote authentication.
It would also have a 'disable' functionality that would render it useless if stolen.
(Perhaps this thing already exists. I am too lazy to google it as I type this :-)).
Re: Why we won’t be supporting Sign in with Apple
#365Earlier quoted context omitted.
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.
Re: Why we won’t be supporting Sign in with Apple
#366Earlier quoted context omitted.
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.
There is a big contradiction in there...
Everything experimental is by definition untrustworthy.
Re: Why we won’t be supporting Sign in with Apple
#367Earlier quoted context omitted.
You can create an iCloud account with your own email address. That avoids getting another email address. When using Apple login, Apple offers the choice of providing an anonymous email to the third party or your actual email. It's up to you. Its about user choice. More privacy or less. Apple wants you to have a choice. Use it or not.
Then why do most of my non-tech relatives have an @icloud.com address that they never needed and never read? Blame the user all you want, but their "choice" was guided by Apple designed UI and Apple provided defaults. Whatever it is, it's producing optimal outcomes for Apple and no one else.
Either way, Apple could definitely do something with regards to make it easier/more obvious to replace it with a useful email address, especially now as it becomes a federated identity provider.
Re: Why we won’t be supporting Sign in with Apple
#368Re: Why we won’t be supporting Sign in with Apple
#369As 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 t…
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.
They do?
https://developer.apple.com/documentation/sign_in_with_apple...
Re: Why we won’t be supporting Sign in with Apple
#370Earlier quoted context omitted.
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.