461–470 of 485 posts
Earlier quoted context omitted.
I think Apple does allow apps to limit social sign in options where it makes sense. So for example, an email app could have sign in with Google, Microsoft, and Yahoo! but not Apple.
Icloud mail is a thing
Earlier quoted context omitted.
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…
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 fin…
Earlier quoted context omitted.
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?
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.
Earlier quoted context omitted.
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.
I can't answer that. However, if you go to appleid.apple.com to create a new AppleID, you must use an existing email address. When I create a new user account on the mac, it asks the new user if they want to create an AppleID. The default is to use their existing email address. You must specifically select an option to get an iCloud account. If you purchase an Apple device, you again have the option of an iCloud acco…
There are tons of people with @icloud.com email addresses that they never use who will fall into the login / customer support traps described in the article.
But sure let's not even acknowledge those very real problems, deny Apple's role in this, and blame users. That will surely solve the issues.
Earlier quoted context omitted.
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.
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.
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"
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
Earlier 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.
Earlier quoted context omitted.
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…
> 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 priv…
Earlier quoted context omitted.
Sign in with Apple asks for your normal iCloud email address. It's Apple's servers that look up your app-specific obfuscated relay email address if you've used one for the app.
duh ! I blame my sleepiness for missing that. Still pretty meh that it is the only solution of its kind without an sdk
Any OpenID Connect (or OAUTH2) library of the devs choice is the SDK.
The Facebook/google SDKs are simply there to add trackers and bloat.