
Why we won’t be supporting Sign in with Apple - dirtae
https://blog.anylist.com/2020/06/sign-in-with-apple/
======
crazygringo
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.

~~~
rahimnathwani
"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.

~~~
AnonC
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.

~~~
sudoit
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.

~~~
c3534l
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.

~~~
undreren
> 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.

~~~
iuguy
> 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.

~~~
indymike
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.

~~~
zchrykng
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.

~~~
thomaslord
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.

------
no_wizard
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
> address, our systems will believe that you don’t have an account

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? Of course this should be opt-in but you can
always Under good faith explain benefits there in.

It’s more work, but I don’t believe that it’s going to run issue with Apple
and provides end users with flexibility.

Of course this may not be worth it, at all. This is just a consideration worth
thinking about as an app developer

edit: Of course another alternative here is they just make users aware of what
their sharing email is and allow users to optionally change that, if they want
to. This most definitely wouldn’t run counter to this I’d think

~~~
duxup
I wonder if Apple would be ok with asking them to give up their email?

Apple clearly likes the idea of the hide option... personally I would expect a
less than positive reception from Apple.

I get where both AnyList (if they asked) and Apple (if they didn't like it)
would be coming from here.

It does seem to be a shortcoming here where outside of a user one time sign up
situation... you don't want to have to burden the user with coming up with
silly names and codes to use social like features that require someone else
knowing an identifier for you that isn't email.

I don't want to go back to a time where we have to remember / pass along
everyone's ICQ number. ...

~~~
crispyporkbites
Why should Apple be allowed to dictate if an app asks for an email address?
They should not become the defacto law makers of our society

~~~
kinkrtyavimoodh
That ship sailed long ago. Apple basically has apps and app-developers by the
balls, not to mention the 30% extortion money they try to get not just for app
purchases but any transaction done within the app, so much as even banning an
app from telling the user that they can do the transaction elsewhere.

It makes my blood boil but from the discussions I see on HN about it, most
people here seem to be more or less ok with it.

~~~
scarface74
It’s not _any_ transaction. It’s any digital transaction. You can sell
physical goods and services either without giving Apple any cut, or by using
Apple Pay and Apple just gets your standard credit card processing fee.

Does Walmart let you sell your product in their store and say you can look at
it there but get it cheaper from Amazon?

~~~
kinkrtyavimoodh
My app is not the App Store. The user has already paid to download my app from
the App Store and Apple has gotten 30% of the cut. What users do on my App
after that is none of Apple's business, though of course Apple would like to
claim otherwise.

Similarly, once I have bought something from Walmart I can use it as I wish.
Our business transaction ends there, so your analogy isn't really apt.

> Does Walmart let you sell your product in their store and say you can look
> at it there but get it cheaper from Amazon?

Funny you say that, because Walmart and many other brick-and-mortal retailers
will happily price-match Amazon and each other. You know why? Because they are
not a monopoly or pseudo-monopoly and so need to do good by their users to
compete.

Of course you can justify Apple's behavior any way because you can claim that
I am on an iPhone so I am on their property or something and so they are my
overlords but that is precisely what users here are trying to argue against.

Or to be honest, you don't even need to justify it that way. The magical
market justifies it because the fact that these apps are on the Apple
ecosystem means that staying on it is better for them than staying off it. And
no other justification is necessary. And you would not be wrong.

But people have a moral intuition about these things based on how they see the
world work, and so they have an intuitive sense for when something seems
'off', even if the market seems like it's working. That's why they complain
against things like exorbitant pay-day loans despite them too being an example
of a market that seems to be working.

Last I checked, I did not get an iPhone on lease from Apple. This attitude
where just because I am on an iPhone means I owe Apple in perpetuity needs to
die.

~~~
SquishyPanda23
> once I have bought something from Walmart I can use it as I wish.

Not if it's a movie, music, or video game. I.e. anything with digital content.

~~~
IntelMiner
Providers of digital content seem to be absolutely all over the place with
this stuff

Comcast of all people offers the ability to buy movies on demand. Not just
rent but outright purchase. If you leave Comcast as a customer, you can have
every purchase mailed to you as either a DVD (SD) or Blu Ray (HD) purchase

Steam has provisions in place that if its service ever gets terminated to
allow users to continue to use games they've purchased on the platform. They
also allow users to continue to download and play games either removed from
the store or no longer sold (Alan Wake and Deadpool being two examples in my
own library)

Conversely Microsoft's Xbox will de-list titles and make them excruciatingly
hard to download, such as Marble Blast Ultra. Requiring you to find the game
in your account history and then use that to navigate to a download page

Sony's Playstation is downright malicious with their digital store. Konami's
"P.T" was offered as a free download as a teaser for an upcoming Silent Hill
game

Once Konami changed their mind however, the game was not only removed from the
store but actively wiped from the users console! If you connected to
Playstation Network the game would be forcefully deleted from your device

~~~
crispyporkbites
You don’t own any of these things, you own a license to the content and the
physical disc.

It’s completely different to owning something.

Steams provisions are helpful in practice but ultimately meaningless because
you don’t own any of the actual games, you merely have a license to run the
code under their terms.

------
WorldMaker
> 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.

The easy answer is: they should just support "Sign in with Apple" on every
platform. (That absolutely works. Sign in with Apple is a [mostly] standard
OpenID Connect provider and has a web frontend that should work on every non-
Apple platform just fine, just like FB/Google/etc.)

You wouldn't think to only support "Sign in with Google" only on Android
devices? Maybe "Sign in with Facebook" should only apply to web browsers?

It's an interesting misconception or miscommunication that so many developers
think "Sign in with Apple" should only show up on Apple devices.

~~~
tech-historian
Sure, except there is no documentation for it. From the article:

"For example, Apple vaguely states that you can implement Sign in with Apple
on Android, but there is no direct documentation on how to do it. We
understand that Apple probably doesn’t care much for Android, but if they are
going to provide a login system, and are going to force developers of multi-
platform apps to adopt it, then providing no real support for a major platform
that these multi-platform apps run on is not acceptable."

~~~
lstamour
[https://developer.apple.com/documentation/sign_in_with_apple...](https://developer.apple.com/documentation/sign_in_with_apple/sign_in_with_apple_js/incorporating_sign_in_with_apple_into_other_platforms)
is more “direct” than most of the documentation I’ve seen on how to implement
“OAuth” with other providers. (Trying to figure out how to integrate with
“Microsoft 365” is particularly painful...)

Eventually you might realize it’s based on an open standard
[https://openid.net/2019/09/30/apple-successfully-
implements-...](https://openid.net/2019/09/30/apple-successfully-implements-
openid-connect-with-sign-in-with-apple/) and that it’s relatively similar to
other such standards, except with the option to mask your email, etc.

As an geeky end user, the only way I trust these services for login is if I
can link more than one, or even more than one email from the same provider.
That way I know I’ll have a backup in case I lose access to the social network
or email address that I signed in with... it’s annoying when I can’t add a
password or set an email just because I also want to login without a password
sometimes...

~~~
draven
It was way worse when I had to implement it a few months back.

It's still incomplete, their implementation deviates from the standard or use
some lesser used mechanism like the form_post response_type, requiring custom
code.

Implementing this was not a pleasant experience.

------
alister
> _Apple reserves the right to disable Sign in with Apple on a website or app
> for any reason at any time._

Holy cow, how is this acceptable to _any_ app developer or software company?
This is reason enough for me to never use Apple/Facebook/Google sign-on as a
developer -- huh, or even as a user. Apple/Facebook/Google could lock out all
your users and literally destroy your business in a split second for an
arbitrary policy violation, without explaining why, with no way to contact a
human being. Haven't we seen enough HN headlines where an independent
developer or a small software company is begging for help because
<LargeCorporation> canceled their account or locked them out of something with
no recourse?

EDIT: I know that AnyList is dependent on Apple's app store. This is still no
reason to give Apple (or Google or Facebook) even more power over you.

~~~
nexuist
You know the reason. It's on the front page of HN today even. Apple will
support Sign in with Apple until it is co-opted by "white nationalists" or
other scary characters, at which point they will disassociate with that
website or app and prevent their services from working with them.

Which is their right of course, but at the end of the day it means we get
changes like these in the fine print. Gatekeepers like Apple and Google gain
more control over what is allowed on their platforms, and subsequently what is
allowed for the majority of the population to see.

~~~
TazeTSchnitzel
Why have you put that term in scare-quotes?

------
czzr
Buries the lede. They’ve chosen to drop support for Facebook login rather than
also support Apple login. So working as intended!

~~~
mikeryan
I'm going to be fascinated to see what this does for conversions. My company
built the Neil Young Archives, when doing so we initially launched with Social
log ins and at one point Neil decided Facebook and Google were evil and wanted
to remove the access. According to our logs a full 2/3s of all users were
registering with a social account and we were having great success getting
folks to log into a free service (We had 250k sign ups over the first weekend,
we thought Auth0 might turn us off as we started on a tier capped around 40k)

We assumed this success would quickly taper off if it wasn't "one click" to
sign up with your Google/Faceboook account an talked Neil off the ledge.

~~~
goliatone
This escenario seems an clear candidate for A/B testing since I would be
conflicted by wanting to provide privacy but understanding it might impact
user signups.

Seeing some actual numbers would help me in making that decision.

~~~
mikeryan
I don't disagree with you and it was proposed. However we didn't have A/B
infrastructure in place then and on a project that may never make money it
just wasn't a high enough priority to justify the spend.

~~~
goliatone
Fair enough, sometimes you have to make a decision with what you have. A/B
testing adds complexity and specially when doing contract/agency work you
don’t have either the time nor the budget to pull it off. Been there myself.

Personally I would have considered to hack something on my own time just out
of curiosity :D

------
djrogers
This makes perfect sense from their standpoint - especially since they've had
similar problems to what they outline with Facebook sign-in and are now
dropping that as well. This is also a win for Apple & end-user privacy, as
there's one less app using FB's login feature now.

I think Sign in with Apple is a great step forward even if all it does is
eliminate apps that _require_ Facebook and/or Google accounts to log in. I
hate that - I actually ran into a feature on my mesh router system that
required a FB/G login, which made it a useless feature for me. Fortunately I
didn't need it..

~~~
muro
I've never seen an app that required a FB or Google login. It was always
possible to use email+password.

~~~
dheerendra73
Lucky you! I've run into lot of these apps offering only FB/Google sign in. Or
offering mobile number only login. For e.g. I like playing scrabble and
Scrabble Go only support FB login so I'm playing only as Guest user for months
now.

Mobile number login is even worse! Why do I need to share my mobile number for
something where you don't need to have it!

~~~
rmorey
I think a lot of services use mobile number login as a way of bot-limiting;
harder to create lots of phony email addresses than phone numbers. But it's
still a pain in the butt :(

~~~
thekyle
> harder to create lots of phony email addresses than phone numbers

I think you got this the wrong way around.

------
intellirogue
Worth noting that AnyList automatically subscribed me to a marketing list
without double opt-in or any kind of consent, which is exactly the kind of
behaviour that makes me not want apps to have my real email address.

~~~
mxcrossr
They mention customer support so many times in that article, but it's a
grocery list app! When is the last time I asked for support for the sticky
note attached to my refrigerator? I don't doubt that there are indeed
customers who need support from time to time, but surely it's a small
minority.

These seem to just be contrived arguments to protect their customer data
selling bottom line.

~~~
temporarysdwvit
Yep, my feelings exactly after reading. All this whining happens only when
your business is very dependent on specific information that gets taken from
you.

------
persona
This seems to be a common problem, made more visible when using third-party
authentication, that your application has taken the concepts of "Account" and
"Authentication Method" as if they were the same thing.

It appears that the "account ID", "preferred contact method+address" and
"authentication ID" are all the same here - which then creates the "account
management code into a rat’s nest" scenario they describe in the post.

If an Account is, by design, it's own entity - you should be able to have 100
different authentication methods linked to that same account without impacting
any other flow or part of the application.

Turn on and off authentication methods would also allow for seamless
transition for users, without worrying about when one method is about to be
killed.

~~~
dahfizz
I feel like they address this in the article. What you say makes sense in a
technical UML diagram point of view, but that's not how people work.

The examples they give are getting support and sharing things with another
person with an account. As a user, both of those things are easier for me if
there is an email associated with the account.

Said another way, the Account needs some human friendly global identifier. The
email you use to log in is an obvious choice, and anything else would require
extra work from the user to set up. You could have usernames, for example, but
that complicates the signup process and still makes sharing things hard. I
know my friends emails already, but I don't know what username they ended up
with on this site.

~~~
persona
I'd argue that this makes more sense in the real world than in a diagram,
after being burnt in multiple real life experiences :)

The assumption both you and AnyList are making is that an email is "THE
obvious choice". From a user experience perspective perhaps this "global
sharing identifier" should be defined by them.

You'll notice that different generations have different online behaviors. For
some, email is their main id. For others, it's their phone number (they don't
know most of their friends' e-mail, but know their phone). For others, it's
either online handles or nothing at all - think about the device set up for
grandma with her daily To Do list.

Of course, having this approach would add some upfront dev work to them but
allow them to navigate this much easier later on. And for anyone starting to
develop their new app/site/product thinking about this early on can reduce a
lot of future headaches.

~~~
JAlexoid
That's a very idealistic opinion.

People don't care about usernames and other crap. They want an easy option -
enter email, communicate over email and be found using email. This isn't their
banking app or anything that important.

~~~
filleduchaos
Nobody "wants to use their email". They just want to start using whatever app
or service they're trying to connect to as quickly as possible - why exactly
do you think "Sign in with X" became so popular in the first place?

------
zaroth
In my experience the “Sign on with Apple“ option makes it totally risk free to
click and I don’t even think twice before clicking to create an account
whereas a typical registration page will definitely raise the possibility of
me bouncing.

Sign-in With Apple is perfect for those accounts that you basically never
wanted to have anyway. If it’s something where I want a “real” login,
especially one that I might want to share, then I’ll go through the trouble of
actually registering and picking a shared secret that my wife and I know.

But for the average app that needs a way to keep a user profile for me, it’s
just right, and from a UI perspective on iPhone it really is magic. Two taps
and I’m just _in_ with zero mental baggage and an email relay to eliminate the
possibility of spam.

------
TheArcane
> 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.

Ironically, this is also why I use Sign Up with Apple at every opportunity I
can

~~~
renewiltord
How is this ironic? It is by design and obviously they know why people do it
because the very next sentence says that. Why on Earth would you'd want to use
a list-sharing app that uses email as the addressing system and then not share
your email.

~~~
swagonomixxx
The anonymous e-mail that Sign-In with Apple generates forwards to the e-mail
used to set up your Apple ID. So it's not like it's a random e-mail that acts
as a /dev/null.

This is by far the biggest selling point of Sign-In with Apple for me and I
will continue to use it, and continue to not use apps that don't support it. I
have plenty of e-mail aliases, but having an alias auto-generated for you is
very convenient, and not having to generate a secure password is also very
convenient.

The day AnyList gets hacked (not saying it will - but it's highly likely, the
way security has taken a backseat due to "features") then at least my personal
e-mail and password won't be there for every hacker on Earth to see and try to
spam passwords to get into all of my other accounts.

~~~
renewiltord
Perhaps you don't use AnyList? It doesn't make sense to use with a private
mail relay because they use email as an addressing system. And honestly, few
users will go look up their per-app address and tell people to add them.

~~~
KeepFlying
This is where their article lost credibility with me. Their decision to base
their sharing and addressing system on email was their mistake, and Apple is
just the first to force them to face their mistake.

I don't want to share my spam email with all my friends to get them to share
with me. And I don't want to give my primary email to an app that will spam
me.

If I want to share something, I'll send a link and the recipient can connect
to me that way. I don't need to search them within the app to get in contact,
that's useless.

> 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.

This is a trivial part of the problem to solve. Why am I being asked to create
an account in an invite email? Why not "log in or create account" and having
the link itself be the piece that connects the share to me.

~~~
JAlexoid
It's not a mistake, by any means.

It's dead clear that you don't work with consumers. Your technical bias shows
what you care about and you're(an me) are an utter minority.

If you want security, btw - you should have multiple passwords for different
things. And ideally not even use a password manager.

~~~
mahnouel
Why should he not use a password manager?

~~~
JAlexoid
You're storing all of your password in one location. Behind just one password.

What's the point in password manager, if all you need is one time auth - and
you're in!

------
ThePhysicist
We've implemented a bunch of third-party login solutions on our platform, but
in retrospect I think it was not worth it for us. I think integrating third-
party logins makes sense if you know that most of your target users come from
a given platform or your application wants to interact with a specific
platform (e.g. a Github integration).

Otherwise the points the author makes seem painfully correct from our
experience. Adding third-party sign-in immediately complicates the frontend as
you need to support OAuth/OpenID-Connect workflows that are much more
complicated than sending a password & e-mail combination (and possibly an OTP
token) to a backend and reading the result. In addition, even though
OAuth/OpenID-Connect are standardized it seems that almost every provider has
decided to add its own quirks to it, so you can almost never just reuse the
same code for integrating e.g. Github and Gitlab sign-ins.

What we currently do is to always add an e-mail using the third-party provider
and use that to allow a password reset or password creation. You have to be
quite careful with this as well though unless you want to open new security
isues. Incorrectly implemented sign-in workflows via third-party providers can
open avenues for account takeovers if you implement e-mail validation or
account reconciliation incorrectly (e.g. an adversary might register an
account with the victim's e-mail on a third-party platform and try to use that
to sign into the victim's account; if the sign-in flow is configured
incorrectly [happens a lot] the system will recognize the e-mail and sign the
attacker into the victim's account).

Also, don't trust any validated information from third-party providers
(especially e-mail addresses), as this can provide another attack vector.
Always do your own validation.

------
lowmemcpu
> One problem is that most Apple IDs are tied to an iCloud email address. So
> most accounts created via Sign in with Apple will use an iCloud email
> address. But many of those iCloud email addresses are unused and unchecked,
> because a customer’s “real” email account is their Gmail, Yahoo, or Hotmail
> account.

Wow, this is a really good point. I just checked and yup -- my AppleID is
directly linked to my icloud email, and I've never once checked my icloud
email account. I wonder what's in there. Meh, too lazy to go check it

~~~
mns
This seems strange to me. My iCloud account is my Gmail address (even though I
also have an iCloud one on the account) and when I use Sign in with Apple I
get an option to redirect all emails to Gmail.

But the system is indeed weird, I signed up for an account in an app with bike
routes and wanted later to check it in the browser and had no idea what or how
to find out what my account is or how should I sign in (could be also the
app/website didn't implement this properly).

~~~
tzs
Things may differ from person to person depending on when they created their
Apple account(s).

At first, before they had cloud services, you created an Apple account to
purchase things from the iTunes store. You could use any email address.

Then they created MobileMe (which was rebranded to .Mac), and that came with
an email address @mac.com. (I believe there were a couple of other domains you
could choose instead, but don't remember what they were).

That was eventually discontinued, replaced with iCloud, and .Mac accounts were
migrated.

Somewhere in all there Apple loosened requirements so that you could use an
outside email address as your cloud ID, and made it so a cloud account could
could also work as an iTunes account.

For those who created their accounts after that point, it's all sane. Create
your Apple account using your outside email address if you want, or using an
Apple provided address if you prefer, and then that one account can be used
for all your Apple stuff. Buying music, buying or renting video, buying apps,
and the cloud stuff.

For those of us who created our accounts before all that, we ended up with an
account using our outside address which has our music, video, and app
purchases on it, and an account using our @mac.com address that has calendars,
photos, and the like.

When they changed it so all Apple accounts could be used for everything, it
got even more annoying for us. Whenever we'd see some dialog asking us to sign
in to our Apple account, we'd have to guess if it wanted our music/video/app
account or our cloud account. If we guessed wrong, we could end up
accidentally purchasing apps or media on the cloud account.

Apple does not provide any way to transfer purchases between your accounts, so
if you end up with media or app purchases on both accounts there is no way to
consolidate other than purchasing duplicates.

If you are willing to do that, or if you have avoided duplicate purchases, you
can kind of manually consolidate accounts. You can export calendars, contacts,
and the like from your original cloud account, and import them into your
original iTunes account. Same for photos, online disk space, and anything else
you have on the original cloud account.

Once you've got it all in the original iTunes account, delete everything from
the original cloud account, and then just make sure to never again sign into
that account. Any time you see the Apple account login dialog, give the
original iTunes account.

~~~
X-Istence
Even if you have alternate email addresses associated with your iCloud
account, you are free to update it to have your external email address be the
default for your iCloud/Apple ID.

Visit
[https://appleid.apple.com/account/manage](https://appleid.apple.com/account/manage)
to make those changes.

Help article: [https://support.apple.com/en-
us/HT202667](https://support.apple.com/en-us/HT202667)

Although I will note that it says you can't change your Apple ID email address
if you choose an @me.com, @mac.com, or @icloud.com email address for your
Apple ID, which is the first time I've seen that warning.

------
danpalmer
Another issue with Sign in with Apple is the fact that their private relay has
a pre-set allow-list per app for sending email to relay addresses.

This means that you must either prove ownership of domains, or pre-add email
addresses to Apple's systems. I understand why they have done this, it will
reduce spam considerably, but the private relay system is already designed to
empower users to do this and this extra step may be impossible for some
developers.

Take for example a retailer – they need to dispatch goods and use different
carriers in different countries. When the user buys something they very likely
want email notifications about delivery, a feature that most carriers provide.
For the carriers to send those notification emails you'll need to pre-add them
all to Apple's systems. You can't prove domain ownership because fedex.com
isn't your domain, but where are those emails going to come from? Better hope
your carrier doesn't change sending address at some point or the email goes
into a black hole.

Apple also limits the number of domains and addresses you can send from. In
the original documentation it was "10 domains and addresses" (not sure if 10
of each, or 10 total). This was raised to 100 I believe, but that's still
probably an issue for larger multi-national companies, or those who
necessarily have to integrate with many external services.

The really hard-line privacy stance is that the retailer shouldn't share the
emails and should do the notifications themselves, but for many this is
prohibitively difficult to do, or at least detracts from places where the
retailer can actually add value. The benefits are also very small, as the
contracts with carriers typically protect user data, require deletion quickly
after delivery, and retain most privacy benefits while allowing for a good UX.

~~~
rossjudson
That's a good point, but I'd be surprised if Apple doesn't have (or is
building) a mechanism to allow certain well-known domains to be trusted
sender, in the circumstances you note. Like, have "enter your custom domain",
but also "checkboxes for fedex.com, etc".

------
blakesterz
That was an interesting read. Also, they close with...

"These are both excellent points, and it’s absolutely true that some of the
arguments above apply to creating an account via Facebook. That’s why we’re
also announcing that we’ll be removing the Facebook Login from AnyList."

~~~
dilap
Well, that, and also if they don't remove FB login, then the would be required
to also implement Sign in with Apple.

They didn't want to implement Sign in with Apple, so they had to remove FB
login.

~~~
disgruntledphd2
Which is a pretty anti-competitive move on Apple's part.

They're essentially using their control of the iOS ecosystem to benefit
unrelated products.

I seem to remember that those kinds of actions didn't work out well for
Microsoft :)

~~~
JohnTHaller
Apple takes many anti-competitive and consumer-hostile actions. They can
freely get away with it, though, as they aren't a monopoly.

~~~
scarface74
How is this _user_ hostile - forcing app developers to give users a choice
that doesn’t give the app developer your real email?

~~~
JohnTHaller
I said "Apple takes many anti-competitive and consumer-hostile actions. They
can freely get away with it, though, as they aren't a monopoly." I did not say
this action was consumer-hostile.

------
stickfigure
If you implement Sign In With Apple, you don't have a relationship with your
customers anymore. They're Apple's customers, and Apple can take them away at
any time.

~~~
danudey
It's good that you read Hey's blog post and are repeating it here, but it's
not very accurate in this case.

Specifically, if you implement Sign In with Apple, then they are still your
customers as much as ever, they just might choose to hide their information
from you because they don't trust you, which means that the power in the
relationship is transferred to the user instead of the app developer.

~~~
blendergeek
> "Apple reserves the right to disable Sign in with Apple on a website or app
> for any reason at any time."

I think GP is absolutely right here. Apple can take the customers at any time
_for any reason_. Apple could ban you from using Sign in with Apple simply
because Tim Cook doesn't like what food you eat for breakfast. So, I have to
agree with GP that these are Apple's customers at this point.

~~~
no_wizard
The check on this is that you are now putting an inconvenience on that apps
users. Maybe it’s okay in some isolated circumstance however, I imagine this
won’t sit well if it becomes a reoccurring theme for iOS users, as they will
come to view Sign In With Apple as unstable/unsafe (like Google and it’s
graveyard). It would quickly render Sign In With Apple useless if the trust
that it will continue to work whenever used is not there

I actually think this wouldn’t really happen in practice as consumers are
quick to respond negatively to this behavior, so I’d be shocked if Apple
actually did this without some darn good reason (I imagine it will also
include removing said app)

~~~
wvenable
> The check on this is that you are now putting an inconvenience on that apps
> users.

That hasn't stopped Apple from remove apps or preventing updates -- clearly
inconveniences on users -- for whatever reasons they want. It has happened and
it will happen again.

There is no check on this unless your app's audience is
Netflix/Spotify/Facebook _huge_. If you're just an average developer you can
be killed off at any time.

~~~
no_wizard
I’m not exactly sticking up for Apple as much as I’m trying to demonstrate
practical thresholds that would realistically limit this behavior. I don’t
think Apple wants 100,000 upset customers let alone millions.

Hardware requirements for software is a decades old concept, and it’s true
they deprecate and obsolete supported software and hardware on for older
platforms, but it’s rare I’ve seen Apple taken a user hostile approach here
within supported lifetimes though it has happened yes it is rare.

Their developer experience on the other hand does not see the same care and
attention a lot (most even) of the time. That’s because, and I believe this
strongly, Apple never wants 3rd party software to have platform influential
power over them again, like Microsoft and Adobe did for decades. It’s sad but
not unsurprising that their platforms can be very developer antagonistic if
you don’t take their happy path (and sometimes even then). To them though, it
doesn’t matter until it affects a large quadrant of the Apple consumer base
and in some occasions yes not even then, but largely it’s the consumer who has
the biggest voting block with Apple in terms of pressure on the platform, as
I’ve watched it play it they never had a history particularly after the iPhone
came out of having the best developer relations relative to say, Microsoft,
who provides a very positive experience in comparison

It’s just not in their DNA because of the fear of having too powerful of
vendors putting pressure on the platform that they otherwise control outright.
When you look at their policies in this context they make a heck of a lot more
sense (even if you don’t agree. I certainly do not always)

------
qwerty456127
There are 3 major problems with this kind of sign-in from the user perspective
they apparently omit: whenever you sign-up for a service B with an account at
A (usually Google, probably applies to Apple, Facebook and the rest as well)
1. A will block your account at B at any time as soon as its (A's) algorithms
realize they don't like you for some stupid reason they won't even tell you
(which is icky but understandable given how many users they serve) 2. A tracks
your usage of B (obviously). 3. _The most overlooked_ \- A discloses many
additional details about you (like your contacts, your location, your birth
date, your real name etc.) to B. Sign up to some shitty website once and they
immediately have enough data on you to apply a wide range of social
engineering / identity theft attacks with ease.

I actually can consciously accept the 2 in many specific cases but 1 and 3,
each alone, are enough for me to avoid using this kind of sign-in.

~~~
lrem
Why is 2 so obvious? I imagine many implementations would do that, but
basically once you exchange your SSO token for the site-specific token, you
could stop making any requests to the SSO provider. The only part of your SSO
provider's offering that inherently needs to track you is running detection if
you're a bot.

------
tboyd47
There's a subtle sense of exuberance shining through in this article that
makes it a gratifying read, even if you've never heard of the company before.
Kudos to them for their decision not to bow to Apple's demands. Please tell us
how it goes!

~~~
ogre_codes
> bow to Apple's demands.

Apple "demanded" companies either add their privacy friendly sign in option,
or give up on the data-slurping Facebook google sign-ups. This company gave up
FB sign in, which they acknowledge is pretty gross and bloated.

------
Angostura
> One problem is that most Apple IDs are tied to an iCloud email address.

Is that actually true? None in my household are.

~~~
withinboredom
It depends mostly on the demographic in my experience. For example, my parents
have icloud email addresses that they occasionally email me from and never
reply to for the reasons mentioned in this post.

~~~
scarface74
My anecdote is similar. I first created my Apple account when the iTunes music
store was introduced in 2003.

But, when I setup the account for my mom and my wife, I just created an iCloud
email address.

My wife never uses her iCloud email address. I don’t think she uses the
default mail client - she uses the gmail app.

------
artichikin
Last year we pulled all social logins (facebook, google, yahoo) out of our
app, after supporting them for years. The UX / customer service issues
mentioned in this post are absolutely legit, a complete PITA. While we were
nervous about adding the extra signup friction, a year later I can easily say
it was worth doing.

------
TheRealDunkirk
> We’re a small company that makes money when people like our app and pay for
> it. We do not make money with creepy tracking or by selling your
> information. When you provide us with your email address, it is never sold,
> shared, or used to invade your privacy.

You're the only one, then.

What's happening here is another revolution. Email spam got so bad, that
Congress actually passed a law. Which, of course, did almost nothing. People
got so tired of spam, that they avoided email, and allow the services to
silently remove 90% of the crap.

This has now spilled over into voice calls, where it got so bad, so quickly,
actual legislation was considered again. But people quickly realized that
their phone contained a curated whitelist. Now, I never answer unless the
number is recognized, and I think most people are doing the same.

Texting is also similarly whitelisted.

At this point, email systems and clients need to start with the assumption of
whitelisting. Instead of just a "spam" folder with obvious crap, and controls
to flag or unflag messages in that folder, we also need a "questionable"
folder, with controls to mark as "known" or "unknown", as well as "spam".
Emails shouldn't make it to my inbox unless they pass BOTH the whitelist AND
the spam check.

------
scarface74
Your iCloud account does not have to be paired with an iCloud email address.
Mine is paired with my regular email address.

~~~
snazz
Yes, but many are. This app in particular needs an email address that is
actually checked.

~~~
scarface74
From what others have said, they also need it to add to their marketing
list....

------
floatingatoll
Apple's developer docs on the Private Email Relay Service are relevant to
those evaluating the technicals of AnyList's position. Three specific
highlights from that doc are relevant when considering AnyList's objections:

[https://developer.apple.com/documentation/sign_in_with_apple...](https://developer.apple.com/documentation/sign_in_with_apple/sign_in_with_apple_js/communicating_using_the_private_email_relay_service)

 _After the user has shared a private relay email address with your app, they
can find, view, and manage it in their account settings at Settings > Apple ID
> Password & Security > Apps Using Your Apple ID._

 _The relay server transforms your email address so it’s readable to the user.
For example, sales@xyz.com may become sales_at_xyz_com_
<something>@privaterelay.appleid.com instead of a random email address.
Replies from the user are still routed back through the service to preserve
the user’s privacy._

 _To send emails to users with private email addresses, you must register your
outbound emails or email domains and use Sender Policy Framework (SPF) to
authenticate your outbound emails._

------
mojuba
3rd party logins have the advantage that sharing content from within your app
on those social platforms becomes less of a friction unfortunately - if that's
what your app relies on.

Email-only logins work fine with technical users, but non-technical ones
absolutely suck at maintaining their logins and passwords. You lose users
because they can't login for whatever stupid reason - one of the thousand
stupid reasons - and they turn away to never come back, or they register
afresh. This is the reality and yes, 3rd party auth is beneficial for popular
(non-techie) services.

As for Apple Sign-in, haven't tried it on the development side yet but I can
imagine it reduces friction even further and makes the user experience even
nicer. This may be such a big bonus for your service that you may ignore the
fact that you can't always collect your users' real email addersses. Find
other ways to communicate: in-app messaging for example. If the user deletes
your app then retargeting via email won't help much anyway - they will mark
you as spam and overall it will probably do more harm than good, I think.

------
fulldecent2
I usually uninstall apps with a 1-star review if they provide zero
functionality until you provide your email address.

Apps and devices serve me, not the other way around.

~~~
t0astbread
So you don't use social media on your phone?

------
oramit
After reading the article and comments i'm honestly a bit baffled.

Why is email address obfuscation an important component of online privacy?
There are so many other more invasive and pernicious privacy concerns to worry
about. It seems like we're spending an enormous amount of time to build far
more complex authentication systems that are brittle and confusing just to
avoid sharing an email address. Why?

Email addresses are supposed to be semi-public. If I share it with you I want
you to contact me. People do abuse this, of course, but the open nature of it
is exactly its best quality. I can sign up for new services easily, they can
contact me, and if they bother me I block them.

I've had the same email address for almost 20 years now and have never had
issues managing it. I cannot say the same for Facebook connect and Google
Auth. I actively avoid signing up for services if I have to use a 3rd party
auth service.

~~~
ric2b
An e-mail address is as close to a unique id of a user as you can get online.

It makes cross-site/service tracking very easy.

------
Reason077
> _" One problem is that most Apple IDs are tied to an iCloud email address."_

Is this really true? I've had Apple IDs for pretty much as long as they've
existed, but I've never had an iCloud email. Any email address can be an Apple
ID.

(...in fact, early on, it didn't even have to be an email address. I still
have one of those old-style Apple IDs.)

------
njsubedi
In a rat-race of adding a bunch of (Sign in with xyz) buttons everywhere in
the login forms, this news feels good in a weird way. Most developers use
OAuth login support using several other services to reduce the friction of
signing up, but this article made me think about this for a while. I've been
in a situation where I could not remember whether I signed up using a
provider.

Password managers and 2FA options are getting popular in the mainstream media,
and most people know about it after their financial service providers are
mandating 2FA. It's probably time we figure out an easy way for users to sign
in using a random alias of their email address to sign in to any service.
Something that is generated using their real email address, the service
provider's domain name and some kind of salting. This is the time the plain
old username-password login came back.

------
AnonC
The only authentic point I saw in this entire article was the one about the
lack of documentation by Apple in implementing this across different
platforms.

Everything else applies to logging in with Facebook (or can be dealt with in
other ways), which the company has supported for years and is now forced to
remove it because of Apple’s restrictions. Without Sign In with Apple, I doubt
if they would’ve chosen to remove the Facebook login anytime soon, thus
putting more users into privacy hell holes despite making statements like
this:

 _“At AnyList, we respect your privacy.

...

When you provide us with your email address, it is never sold, shared, or used
to invade your privacy.”_

If the documentation had been good enough, I’m sure they would’ve implemented
it and also retained Facebook login for a longer time. Seeing Facebook login
being removed gives me some comfort and a sense of “all’s well that ends
well”.

------
kerkeslager
Given all these third-party sign-ins are a fairly transparent grab for power
by the central company, I'm not sure why anyone would implement any of them.
By doing that you're giving up power over your sign-in process, which is a
pretty enormous concession.

------
gramakri
Not an Apple use but I had a question. If one signs up with Signin with Apple,
how can that user move over his stuff to say an Android app? Or even Desktop
app? (Or does the Apple ID keep track of all this anonymous id to app
mapping?)

~~~
faet
You still have your apple account on your PC/Android phone/etc. You just login
on apple's website with your apple account and it passes the token/id to
whatever app needs it.

For example you can goto dropbox on your pc/whatever and click signin with
apple to see how it works.

------
Razengan
I had never heard of AnyList and this makes sure I will never use them.

Before Sign in with Apple, I uninstalled most apps that required me to sign up
before I could even try them at all. Now I specifically look for apps that
support it.

I don't want to give my email to 100 different companies (I get spam on the
aliases that I did hand out long ago to apps that aren't even around anymore).

Though, all these hitherto obscure companies jumping into the spotlight just
by setting themselves up as the underdog against the Apple world tree gives me
an idea of what to do when I want a quick boost in popularity.. :)

------
HenryBemis
> your email address, it is never sold, shared, or used to invade your
> privacy.

This is ambiguous. "..to invade your privacy". They should have stopped at
"sold, shared. The "to invade your privacy" is a bit doublespeak. One can say
"we do not invade privacy, we merely inform of new products and services (aka
marketing).

I know I am being pedantic, but hey.. it doesn't write "never" it writes
"never for A".. we never wrote "never for B", so B is allowed by our T&C
(which I haven't read so I may stand corrected).

------
mssio
Developer should just ask for user's email after new sign up using third party
provider. Even Facebook does not require email for user to sign up. They
should separate the email used for the account & the email used for third
party sign in. Because 1 user can have multiple third party sign in, all with
different email.

I think they did not need to care about customer who did not check the reply
email from support, because customer can also have multiple email and did not
use their primary email to sign up to your service.

~~~
esperent
What's to stop someone signing up with a fake email and sharing it on a forum
so that many people can sign in with it?

Yes, I know that there are ways to reduce this by scanning IPs and so on, but
by using third party auth you offload that onto the auth providers.

------
jbarches
Recently went through the same debacle. Our hope was that we could solely rely
on Magic Link instead of email/password ... but it turns out many users don't
really understand it [1]. So your options are:

1) Email/Password Sign In

2) Bite the bullet and add Apple / the "full auth stack" (FB/Google/etc.) &
deal with account linking issues.

[1] [https://snaphabit.app/blog/password-less-
login/](https://snaphabit.app/blog/password-less-login/)

------
axilmar
I wonder why we still have passwords. Couldn't we have a simple USB device
that is encrypted, cooperates with the native O/S in an encrypted manner, and
then allows remote login to sites also in an encrypted manner?

The 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
:-)).

------
SergeAx
Side note: there's (almost) no problem implementing Apple sign in on Android.
It is basically the same OAuth flow as Facebook or Twitter, with couple of
minor quirks.

------
NorwegianDude
I seriously hope I'll see the day when OpenID takes off. It doesn't seem to be
going the right way, but it would solve most of our login problems.

One way to sign in, used everywhere, decentralized, set up 2FA for everything
in one place, switch providers with ease or be your own provider.

Apple could promote a decentralized solution instead of forcing the sign in
with apple shit on people, but clearly they want all your data so they can
lock you in.

------
jeffrogers
I dunno. There are simple solutions to the issues raised in the blog post,
many good ones here in the comments. Seems likely they wanted to get rid of
third party logins and oddly chose to throw it on Apple. And I’m not sure
anyone, including Apple, cares if they adopt Sign In with Apple. In the end, I
think everyone just wants to end creepy sign-in practices. Facebook login
deleted from Anylist... that’s a win for everyone.

------
ascotan
Love it. I hate it when I'm presented with a "sign in with Google". I feel
pressured to have a Gmail account or a Facebook account (which I honestly
don't want).

I get the fact that login is broken across the web and there is no centralized
login authority, but sorry Google/Facebook are not it imho.

We can/should look at other ways to authenticate, but thats a larger
discussion.

------
kolla
It's a grocery list app, how much customer support do they have to do!? Feels
like they just really really want to have my email.

------
mikece
The larger problem is trying to get the average Facebook and Instagram user to
care about security (if they cared about those things they wouldn’t be on a
Facebook product but I digress).

I applaud Apple’s _intentions_ but as this article proves, if the user isn’t
driving the push to be more private then initiatives like Sign In With Apple
cause little more than support headaches.

------
dred_prte_rbrts
Is it just me or do these sites not realize that "We will never sell your
email" does nothing for me? It's not that you'll sell it's that you will get
hacked or lose a laptop or have an admin email everyone and then I will get
spam. How do others at HN deal with this (disposable emails and prefix/suffix
are a huge pain)

------
fiddlerwoaroof
It’s pretty user-hostile to refuse to support the authentication provider the
user wants to use. If I’m already in the Apple ecosystem, using Sign In with
Apple, a service that doesn’t implement Sign In with Apple but could is
preventing me from doing what I want, just as much as Walmart not accepting
Apple Pay.

------
temporarysdwvit
Why do you need to log in in this app? All the problems indicate that app is
used on one device only

------
Orlan
All of them good points. I'll add another wrinkle; for some reasons I can
barely remember, I have 2 different Apple IDs. I was a paid .Mac user when it
was a thing, but I also had a different account to make iTunes purchases back
in the day. Currently I need to log in with both in my devices; one of them is
used for purchasing in iTunes/App Store, the other one is used for iCloud
Photos/iCloud Drive. However you can also make purchases in the Books app
(which I use it to sync PDFs), so this always trips me up. There's no way to
merge two Apple IDs, and setting up a new device is always an adventure.
Knowing when to use which Apple ID can be confusing (don't get me started on
2FA, I'm afraid that having 2 Apple IDs will eventually lead to me getting
locked out!).

I liked the concept of Sign in with Apple when I first heard about it, but at
this point it might be too confusing (I also never check my "main" Apple ID
email).

------
GoblinSlayer
Identifying users by email is a bad practice anyway. Such systems usually
don't provide a way to change the email address, because it's literally your
id. This makes it unnecessarily difficult to migrate between email addresses.

------
ianamartin
Apple having a major flaw is a pretty bad mark against this. But in my
experience, companies doing it themselves are far worse.

The correct response to "Yo, they fucked up." is not "Oh screw it. We'll just
do it ourselves."

------
ccktlmazeltov
I find Apple's Sign in approach shady (forcing apps to have it, and have it
first on the list), but this response is also about not liking the privacy
features of Apple Sign in so... I wouldn't read much into it.

------
asasidh
This is a war between apps and platforms on who gets direct access to
customers.

------
afro88
Makes sense to support it and respect users privacy. If they forget their
login, they can just sign in with apple again? And if they contact you for
support they can provide their email address to you then.

------
huslage
Some of this can be solved by asking a user for their email when they open a
support ticket. Also allowing them to link accounts from multiple login
providers. These are largely "solved" issues.

------
LockAndLol
How long till it becomes mandatory by Apple? I give it a year. Then they'll
say "our users expect it, so now we do" and it won't matter if that's true or
not.

------
surround
What about vendor lock-in? Apple forced many apps on the App Store to use Sign
In with Apple for increased “convenience” but it also makes it very
inconvenient for people to switch to Android.

~~~
scarlac
Yes, that's mentioned in the article:

> 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.

------
ocdtrekkie
I mean, if this is pushing them to remove Facebook login, Sign in with Apple
and the resulting requirement to use it has been a net positive for privacy
for AnyList as well.

------
m3kw9
The convenience and supposed privacy of signing in with Apple ID out weights
the cons. People will still have problem remembering which email they used
down the road.

------
neop1x
I support their decision. They shouldn't be dictating developers which SSO
services to use or not. It's developer's app not Apple's.

------
forrestthewoods
> 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.

I’m an avid iOS user with a Windows desktop. I will never use “Sign-In with
Apple” for this reason. It’s not useable unless you exclusively use Apple
devices. Which I don’t.

~~~
WorldMaker
Sign-In with Apple is a (mostly) standard OpenID Connect provider that works
_everywhere_ (and works just like sign in with FB, Google, et al from a
technical implementation), including the Web and Android. It's an interesting
miscommunication or misunderstanding (and I was not surprised to see it in
this article) that applications and developers think the "Sign in with Apple"
button should only show up on Apple devices. It should show up on the web and
in Android apps, Apple only _requires_ it on Apple devices because that's the
only devices that they control.

I wish Apple communicated that better and/or developers better understood that
Sign in with Apple really is a FB/Google/social login button like all of the
others and should be supported everywhere, not just Apple devices.

(I'm in the iOS/Windows dual mode user team myself these days and find that I
trust Sign-In with Apple, but I've definitely had to already email developers
to request that they add the Sign-In with Apple button to websites and explain
why they would/should.)

~~~
tech-historian
If you read the article, you'd see they address the reason they cannot
implement it on Android yet. Apple hasn't provided documentation for it. Apple
doesn't seem to be taking it seriously.

~~~
WorldMaker
To keep my reply in a single place:
[https://news.ycombinator.com/item?id=23684452](https://news.ycombinator.com/item?id=23684452)

------
musicale
Well, that's another app I won't be using.

------
rorykoehler
I’ve got a new sign in flow I’ll be using for all my indie apps. It solves 2
problems I have with Apple.

1) no PWA support for notifications

2) forcing stuff like this on everyone

I use a telegram chat bot. After signing up via the bot that sends you a link
to set your password, you then also request a short expiry sign in link
everytime you wish to sign in. The chatbot doubles as a notifications channel.
I’m thinking of enhancing notifications do you can interact with them directly
from the chatbot interface too.

The signin flow is great as it has 2fa built in by default.

~~~
kergonath
I am pretty sure I would never create an account on a website that wants me to
chat with a bot on Telegram. This sounds particularly user-hostile.

~~~
rorykoehler
Why is it user hostile? Maybe you're misunderstanding what it is but for
signup it's just a wizard and for login it sends you a link. Pretty seamless
experience. To signup you click a deeplink button into the chatbot follow some
simple steps and then get logged into the app. Otherwise the notifications
work just the same as you're used to except it leverages the chat platform
instead of the developer hostile native platform.

~~~
kergonath
Sorry, hostile was probably too much.

I understand after having read the explanation. However, my experience with
chatbots is that they are unreliable, unhelpful and obnoxious, and I tend to
go out of my way to avoid using them. I don't think a conversation is a right
model for this. I also don't think it looks good when a website or app wants
me to install a messaging app to create an account (though of course some
people already use Telegram). It would have to be very enticing for me to
overcome that friction.

The platform (Apple's, in this case) might be hostile to developers to some
extent, but the whole web is hostile to users, in no small part thanks to
websites slurping as much PI as possible and then leaking it one way or
another. I get spam and phishing attempts every day, as do all of us, and I
regularly see some of my burner emails show up on haveibeenpwned. Any service
that helps me separate my accounts from me is some progress.

~~~
rorykoehler
Well I also have no intention of slurping PII beyond the bare minimum. I
understand there may be some added friction for some users but as a one man
show I can’t deal with the maintenance necessary to be on the mobile app
stores. I look at it as a constraint to encourage creativity. As I develop
ideas I am exploring more and more how to make the ux and the approach gel in
a seamlessly natural manner. I guess I’ll find out if I’m successful after
launch...

~~~
kergonath
It certainly is creative, and not abusing data is commendable (and I am
sincere). We would not be in this situation if websites were better behaved
overall. However, I necessarily use heuristics informed by my experience,
because I cannot afford the time or money to do a background check for every
site or app.

------
doggydogs94
AnyList does not like Sign In with Apple (and others), but they helping with
the sign on jungle.

------
rickyc091
If you disable your account through Apple's website the email is no longer
valid. Does anyone know if they recycle the emails?

------
Mave83
Why not just bind the sso Mail to an local Account, then it doesn't matter
what identity Provider gets used by the customer. In addition, add a check
that prevents Account creation of ...@privacyrelay...if you have a problem
with it or nag the user to provide a real mail for this account if you detect
this type of mail. This way you would have a user friendly implementation
without giving up on sso.

------
mahnouel
Wouldn't their problem be solved by using usernames?! Usernames are easy to
remember, share and setup.

------
olliej
Um, it doesn’t forward to their iCloud email address, it forwards to the email
they use for their iCloud login - eg the primary gmail or whatever address.

Users have the option to provide their personal email address, but given the
track record of these being sold it’s reasonable to expect users to not trust
you.

You can email them correspondence because as above that goes to their primary
email.

What you lose is the value of the email address as an asset.

------
ludditetech
Well opined piece, as a customer of Anylist for over 3 years you have my full
support in this decision.

------
dcow
I'd like to see Apple allow users to use "Sign in with Apple" to maintain
Apple ID account and purchase hardware/software? Imagine if they had to go
through what they're asking all the services on their platform to go
through... yeah... never gonna happen. Bravo AnyList for calling Apple out for
pushing immature software ecosystem harmful software agenda.

------
amelius
As a user, I won't be supporting them either.

Just give me sign in without involvement of a third party.

------
thealistra
For me it sounds like they didn’t like the additional work Apple made them do,
that would actually benefit the end user - I love sign in with apple, the best
part is the unified workflow without typing on a phone.

I dream of a world when I won’t have to type passwords on a phone anymore.

~~~
tech-historian
Their blog post is well written and explains point by point why implementing
it would be problematic for them AND for end users. Strange that you arrived
at the conclusion "they didn’t like the additional work Apple made them do"

~~~
thealistra
They describe and edge case of someone not getting the email or wanting to
login on another platform.

I’m talking about the most common happy path that they don’t want to optimize
- the user registration/login

I hate typing a secure password on a phone and I want to evade this process
whenever possible. Using Sign in with Apple you don’t have to type a thing and
you confirm using FaceId.

It seems like the problems they were facing require different UX solutions
than they already had or some bug reports to Apple (if the feature is really
missing something).

For me it is much better to use Sign in with Apple as the user as the flow is
simple, unified and Apple has a track record of caring about privacy, where it
is often not the case for randomservice.io

------
vmception
so all of this could be fixed by AnyList just asking the user to type in their
email address instead of tying it to a data mining operation from their login
name

well at least they are honest!

------
onyva
>> Third-party login systems like Sign in with Apple cause many user
experience and customer support headaches.

It’s not. It’s perfectly slick , simple and powerful and even non technical
user can use. Please enable.

------
jonplackett
What a well written and forceful argument.

------
martini333
cry me a river

------
Avamander
They will get removed. They don't have the power to fight Apple.

~~~
dilap
No, they're fine -- if your only login is first-party, you don't need to
support Sign in with Apple. (They're taking out FB login to comply.)

~~~
muro
I do wonder, though, whether the requirement for Sign in with Apple is coming
in a few years. As in, if you allow users to sign in with email/password, you
must allow users to sign in with "sign in with apple". It might be more
subtle, like suggested auto-fill to create a new account.

~~~
Karunamon
That sounds like a bridge too far even by Apple standards. I can get on board
with "if you support Facebook, you have to support us as well", but not
allowing _any_ kind of escape hatch feels particularly scummy. At some point
it's none of Apple's business how people sign up with my service.

~~~
muro
I don't understand how "if you support Facebook, you _have_ to support us as
well" is ok. Only by holding the relationship between the user and the
developer "hostage".

------
camillomiller
Well, though titty. Honestly, as a user, I don’t give a damn about the pains
this can cause to developers. The amount of spam and unsolicited email crap
this is gonna save me from is worth it 100% for the users. And as a developer,
I honestly think that Third party sign ins are lazy solutions that empower
data-hungry companies way more than they deserve. If your business model
relies on people giving you their data or reselling their email or using it
for unsolicited purposes (these are the only reasons you would be affected
financially by a privacy-driven solution like SIWA) then your business model
is bullshit. Suck it up.

EDIT: I really love the downvotes from developers that are perfectly aware
this is how the things are.

------
AshamedCaptain
I found it jarring that Apple would present themselves as the vanguard
defenders of privacy by announcing what is basically an email relay service.
Most privacy-conscious people wouldn't exactly think of their emails going
through Apple as any particular win in privacy.

And even for the "general user" I find the argument very weak, since it
doesn't look as being any easier than using any other email relay, and there
is a huge obvious conflict of interest for Apple here (they get data they may
not have had otherwise PLUS have yet another tool to bind you to their
services).

It reminds me of the days where everyone in the www was making OpenID
providers but no one was actually willing to do an actual OpenID _consumer_.
So that I could actually use _my_ identity provider on a server of _my_ choice
instead of going through the hoops of yet another large company for no reason.

~~~
WiseWeasel
How is it anything but a win to have an additional easy option to use a more
trusted relay rather than not? Many people have never heard of a relay, and
wouldn’t understand its benefit if the option wasn’t presented to them like
this.

