Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why we won’t be supporting Sign in with Apple

blog.anylist.com

Post reply on HN
Print view View original

291–300 of 485 posts

Re: Why we won’t be supporting Sign in with Apple

#291

Post by JAlexoid »

scarface74 wrote: post #107
kinkrtyavimoodh wrote: post #93

Earlier quoted context omitted.

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 w…

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?

Actually, you're free to add "check out our online store" in the packaging of the product sold at Walmart or Amazon.

So Apple is being extra controlling here. They consider all Apple users property of Apple, so they take a cut off all digital transactions.

Re: Why we won’t be supporting Sign in with Apple

#292

Post by JAlexoid »

threeseed wrote: post #276
dahfizz wrote: post #221

Earlier quoted context omitted.

I think you're missing the point. Part of the problem is that android is an "other platform" in the first place. Sign in with apple is supposed to be a cross platform feature, but Apple can't be bothered to even write out some decent documentation for a platform with over 2 billion devices. Compare, for example, the Google sign in for iOS[1]. They provide a working example project and full documentation. If you are a…

> This is not something that you just copy paste from some half baked blog post. It is amazing to me you think that's acceptable. Have you ever actually implemented a proper sign-in process e.g. with OIDC, JWT, SSO etc ? Because half baked blog posts is the industry standard.

Hardly a surprise that they're so crap, then.

Re: Why we won’t be supporting Sign in with Apple

#293

Post by sky_rw »

imron wrote: post #270
rswail wrote: post #257

Earlier quoted context omitted.

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.

Re: Why we won’t be supporting Sign in with Apple

#294

Post by JAlexoid »

dahfizz wrote: post #258
no_wizard wrote: post #236

Earlier quoted context omitted.

Not surprised the documentation that highlights the Apple Platform is better, however, give. That said, it’s a REST API you query and you get a well defined payload: > A successful response contains the following parameters: code A single-use authorization code that is valid for five minutes. id_token A JSON web token containing the user’s identity information. state The state contained in the Authorize URL. user A J…

To repeat myself, I know that this is more than possible to implement. But you're also hiding a lot of complexity about redirecting from your app to a browser, managing state, custom url schemes, etc. If you want to turn your curl request into an actual app, there's some nontrivial code you have to write and test yourself. And this code is important - if a user can't sign in, your entire app is broken. And to what be…

And even with that - they are not going to use Google.

Even though there is way more value in supporting Google, than Apple. Google SSO is widely used in small businesses, unlike Apple ID.

Re: Why we won’t be supporting Sign in with Apple

#295

Post by IggleSniggle »

duxup wrote: post #218
KeepFlying wrote: post #168

Earlier quoted context omitted.

I think it would come down to user hostility here. If I sign in with Apple and opt out of giving my email only to be faced with a prompt demanding I give up my email address, I'll be upset. I JUST told the app (via checking the box in Apple) that I don't want to give my mail, so why is it now suddenly required? However if the app allows me to sign in and only asks for my email when I try to interact with a feature th…

I think the problem is that once you want to be found, like for a grocery shopping app, most folks think you search and just find them and when it doesn't work....they don't know to go find some settings and figure it out.

Yeah but I dont want to be found. That's why I don't share my email. If I want to share with someone, I don't want the use that app to establish a link between us, because I don't want the app to know anything about us except what it must to do it's job.

"Go find some setting and figure it out" is a UX fail. When I share eg a Dropbox link or a Google Photos link, you can get to it whether you have an established account or not. If there's something special about an app that requires an account before interaction is possible, then you can still make it a one-time share.

Yes, it does make user support more complicated. Yes, that's what I want and expect. I hope when I come asking for help, you can't help me because you have no clue who I am and have no way to get in touch with me because I used some email obscuring service. That's on me.

Re: Why we won’t be supporting Sign in with Apple

#296

Post by paledot »

crazygringo wrote: post #238
grawprog wrote: post #196

Earlier quoted context omitted.

>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 reso…

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 upda…

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

Re: Why we won’t be supporting Sign in with Apple

#297

Post by scarface74 »

JAlexoid wrote: post #291
scarface74 wrote: post #107

Earlier quoted context omitted.

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?

Actually, you're free to add "check out our online store" in the packaging of the product sold at Walmart or Amazon. So Apple is being extra controlling here. They consider all Apple users property of Apple, so they take a cut off all digital transactions.

I have never seen a product at Walmart advertising that you should buy the product online at another retailer to avoid the “Walmart tax”.

Re: Why we won’t be supporting Sign in with Apple

#298

Post by JAlexoid »

judge2020 wrote: post #103
stickfigure wrote: post #30

Earlier quoted context omitted.

For my last two companies (both B2B), I implemented login via Google accounts only. Google login has a number of advantages: 1) Identity is an email address. If I wanted to rip out Google, or Google kicked me off the platform, all I need to do is add passwords and put a "forgot my password" link and my customers continue business as usual. 2) It's not a google-specific email address. You can create Google accounts fo…

point 3 is only true for G Suite customers - if someone is on O365 and signs up for Google normally with their company account, they can access that email after their company turns off access to the email unless they also specifically reset the Google password.

To be fair - you end up with G Suite, Okta or O365 endpoints for B2B. Apple isn't even on the radar there.

Re: Why we won’t be supporting Sign in with Apple

#299

Post by JAlexoid »

persona wrote: post #174
dahfizz wrote: post #153

Earlier quoted context omitted.

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

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…

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.

Re: Why we won’t be supporting Sign in with Apple

#300

Post by dev_tty01 »

nikitaga wrote: post #250
persona wrote: post #139

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…

With rare specialized exceptions, pretty much nobody needs all this complexity. Certainly not a simple app like AnyList. All this flexibility is not free, it comes at the cost of obviousness, as they described. It's not worth it much of the time. The real problem is Apple shoving their proprietary, poorly designed services down everyone's throats. No, I don't want to use icloud email, I already have an email address.…

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.

Post reply on HN