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

What makes you think people would bother with your service rather than using Apple’s service?



I don't understand the question.

I run a large regional forum (10-15k active users per day) and our business model (such as it is) does not rely upon having as many randoms as possible getting user accounts.

We are quite selective when it comes to approving new memberships. We look at numerous subtle signals to decide whether to allow an account to be approved instantly, approved with limits, delayed or rejected. Email, ASN, browser behaviour, user's actions prior to the registration page, and numerous other things which strongly predict whether someone is an authentic new contributor, or a sock puppet/astro-turfer/troll/spammer/abuser etc.

This saves us an astronomical amount of pointless work for our moderators and makes our environment more conducive to constructive and useful contributions. (In a way it's like Hacker News comments except we're not as pedantic about chatty contributions so long as they're good natured.)


Presumably because they'll most likely provide additional login mechanisms that are at least just as convenient (Google / Facebook Sign-in to start?)

User privacy is a great thing, and most of us smaller developers have nothing against it. However, it needs to be done in a way that doesn't threaten our business continuity.


I’m saying if you refuse to support Apple’s sign in because you want more user info, your company is not that special that users are going to hate quit Apple in outrage.

If your business is dependent on giving away user privacy to Facebook or Google unless you are doing something that integrates with them - it deserves to fail.


I don't know what any of you are talking about. You are taking my observations and making wildly incorrect assumptions about my motivations.

I don't want to know who someone really is.

I don't care how little information I get through these systems. I don't want it.

What I do want to know is that I can exclude throw-away Google/FB/Apple accounts made five minutes ago specifically to establish a new whitewashed identity on my site.

Right now I don't offer Facebook or Google login at all—specifically because I think the consequences (both privacy and the further entanglement of powerful entities) are not worth it.


You can make a throwaway email account anywhere in five minutes.


Correct but irrelevant. For aiding the registration of legit users, verifying an email address is beneficial as a way for them to ensure they are able to recover their password.

For dealing with non-legit users the email address itself isn't so important. We don't ignore it—we happily reject attempts from ~10k throwaway domains and also some whole TLDs—but it's only one in a set of signals. The reason why the click-link-in-email process is so useful is mostly because it's a way for me to inject confusing and uncertain failures to the process to make it incrementally harder to game/predict our registration system. And it lets us inject plausible yet artificial slowness so that a persistent arsehole is never able to move faster than our people.

(Far more important are the subtle signals, particularly how the user behaves prior to registration. For example if a totally clean browser goes straight to the registration page it's likely to be an arsehole in a private browsing window. Legit users almost invariably browse content immediately prior to registering.)


Correct but irrelevant. For aiding the registration of legit users, verifying an email address is beneficial as a way for them to ensure they are able to recover their password.

You can still verify their email address for password resets. You send the link with the email address to the alias and Apple forwards it to the user.

But the whole purpose of using SSO is that you are not responsible for passwords - the IDP is. You should just be able to store the user id.


How is this a relevant reply? I offered further details about my fine-grained strategies and multi-faceted custom solution, and your response is to offer a random set of blindingly obvious facts about SSO and SIWA.


Well. Seeing that you were arguing that you didn’t want to use a “random email” that could be created in five minutes. Your whole spiel about not wanting to use a random email created by Apple as if a troll couldn’t create a random email on at least a dozen different platforms makes your whole argument against using Apple’s randomly generated email kind of nonsensical.

Besides, why use any third party identity provider if you are still managing passwords? You said that you needed an email address to send a password reset link.


Again you’re making assumptions and responding to something I didn’t say. Not interesting any more.


You didn’t say this?

Correct but irrelevant. For aiding the registration of legit users, verifying an email address is beneficial as a way for them to ensure they are able to recover their password.

Why do you need to help them recover their password if you’re using a third party?


Your question is invalid because it assumes facts that I have already explicitly refuted. Not interesting.




Registration is open for Startup School 2019. Classes start July 22nd.

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

Search: