5 ms·

If Apple doesn’t place some guarantees around the emails, then yes, I’ll be blocking the relay domain. I don’t care to know a user’s true identity, I just want

If Apple doesn’t place some guarantees around the emails, then yes, I’ll be blocking the relay domain. I don’t care to know a user’s true identity, I just want to ensure that the same person can’t use the system to trivially create unlimited new anonymous accounts on my system. I’d like to see these: 1. Restricted to people who have associated a physical Apple device, and 2. No ability for the user to re-scramble the anonymous identifier once it is assigned to a service. If these two criteria are met, I won’t consider it a throwaway email service.

scarface74 7y ago
What makes you think people would bother with your service rather than using Apple’s service?
- Wintereise 7y ago
  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.
  - scarface74 7y ago
    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.
    - sjwright 7y ago
      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.
      - scarface74 7y ago
        You can make a throwaway email account anywhere in five minutes.
        sjwright 7y ago
        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.)
        scarface74 7y ago
        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.
        sjwright 7y ago
        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.
- sjwright 7y ago
  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.)
eridius 7y ago
The email address isn't the user identifier. If you don't want email, don't ask for email. When you make the request, you can ask for email and/or full name, or ask for neither if all you want is the opaque token that identifies the user (and the one bit that says whether Apple thinks it's a real person).
- sjwright 7y ago
  That’s great—as long as that token can’t be trivially re-randomized and huge bonus points if that “real person bit” is a thing. I haven’t investigated Facebook or Google SSO in depth (I always considered it a bit distasteful to participate in making these behemoths more indispensable) but if they offer some useful metadata that allows me to exclude G/FB accounts which are inauthentic or freshly created, I might look into it too.
  - eridius 7y ago
    Re-randomizing the email wouldn't make sense, as it's not the user identifier. It's literally just an email address, unique to the combination of your app and the user. If it could be re-randomized that wouldn't affect your ability to identify the user. The "real person bit" is a thing. It's the sole bit of information Apple gives for free, which is either that Apple thinks it's "highly likely" that the user is a real person (the bit's absence doesn't mean Apple thinks it's a bot, it just means Apple can't be confident it's a real person, which might simply mean Apple doesn't have enough information to make that call).
wtmt 7y ago
> I don’t care to know a user’s true identity, I just want to ensure that the same person can’t use the system to trivially create unlimited new anonymous accounts on my system. People can and have been trivially creating “unlimited new anonymous accounts” by creating new and multiple email accounts on Gmail, Yahoo, Outlook, Protonmail, Tutanota and many other “free e-mail” providers. Unless you have a list of all “free” email providers around the world and are blocking them, this stand against Apple doesn’t make sense to me.
dwaite 7y ago
If the App Store guidelines say you need to implement Sign in with Apple, and you implement it such that proxy email addresses are rejected, you'll likely be told by Apple to fix it per the developer agreement. These proxy email addresses are supposed to be pseudonymous, one per apple id + app team, and are set to relay to a verified email address associated with that apple id. Authentication will tie back to an associated physical apple device, although you can have one device associated with more than one Apple ID.

scarface74 7y ago

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

Wintereise 7y ago
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.
- scarface74 7y ago
  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.
  - sjwright 7y ago
    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.
    - scarface74 7y ago
      You can make a throwaway email account anywhere in five minutes.
      - sjwright 7y ago
        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.)
        scarface74 7y ago
        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.
        sjwright 7y ago
        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.
sjwright 7y ago
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.)

eridius 7y ago

The email address isn't the user identifier. If you don't want email, don't ask for email. When you make the request, you can ask for email and/or full name, or ask for neither if all you want is the opaque token that identifies the user (and the one bit that says whether Apple thinks it's a real person).

sjwright 7y ago
That’s great—as long as that token can’t be trivially re-randomized and huge bonus points if that “real person bit” is a thing. I haven’t investigated Facebook or Google SSO in depth (I always considered it a bit distasteful to participate in making these behemoths more indispensable) but if they offer some useful metadata that allows me to exclude G/FB accounts which are inauthentic or freshly created, I might look into it too.
- eridius 7y ago
  Re-randomizing the email wouldn't make sense, as it's not the user identifier. It's literally just an email address, unique to the combination of your app and the user. If it could be re-randomized that wouldn't affect your ability to identify the user. The "real person bit" is a thing. It's the sole bit of information Apple gives for free, which is either that Apple thinks it's "highly likely" that the user is a real person (the bit's absence doesn't mean Apple thinks it's a bot, it just means Apple can't be confident it's a real person, which might simply mean Apple doesn't have enough information to make that call).

wtmt 7y ago

> I don’t care to know a user’s true identity, I just want to ensure that the same person can’t use the system to trivially create unlimited new anonymous accounts on my system. People can and have been trivially creating “unlimited new anonymous accounts” by creating new and multiple email accounts on Gmail, Yahoo, Outlook, Protonmail, Tutanota and many other “free e-mail” providers. Unless you have a list of all “free” email providers around the world and are blocking them, this stand against Apple doesn’t make sense to me.

dwaite 7y ago

If the App Store guidelines say you need to implement Sign in with Apple, and you implement it such that proxy email addresses are rejected, you'll likely be told by Apple to fix it per the developer agreement. These proxy email addresses are supposed to be pseudonymous, one per apple id + app team, and are set to relay to a verified email address associated with that apple id. Authentication will tie back to an associated physical apple device, although you can have one device associated with more than one Apple ID.