3 ms·

The point is that many developers would prefer to have a “real” email address. If you’re using Google or Facebook ads the email data point allows them to track

The point is that many developers would prefer to have a “real” email address. If you’re using Google or Facebook ads the email data point allows them to track you across apps and target advertising that data goes back into your personalized profiles. Apples solution of an anonymous email breaks this personalized tracking which is good for privacy concerned users but potentially “harmful” for app developers, particularly those that are ad supported. There are many who wouldn’t see the value in adding Apple Auth and may actually see it as harmful to their businesses model and chose not to implement it which would deprive users of that choice. This isn’t about a large section of app developers who just use social auth in a benign way, like the author, to ease app sign ups it’a about those that use social auth more insidiously to track users, frequently without their knowledge. There’s not a feasible way for Apple to enforce this selectively so used a heavy hand. I feel for author with respect to the button guidelines but as a privacy minded user I’m glad he’s being forced to add the option.

CivBase 5y ago
Thank you! That makes sense. A malicious dev would be okay with implementing Google's and Facebook's SSO solution because it allows them to continue accessing the user's email. However, Apple's policy gives malicious devs an obvious way out: just don't support any SSO solutions. So this policy doesn't really do anything to stop malicious devs at the end of the day. It stops them from taking advantage of alternative SSOs, but I wouldn't expect that to have much effect. I guess maybe the policy is intended to mitigate the potential damage caused by negligent devs? As in devs who are not malicious, but risk allowing malicious actors to access user data through negligent design? That feels more like stretch to me, though.

CivBase 5y ago

Thank you! That makes sense. A malicious dev would be okay with implementing Google's and Facebook's SSO solution because it allows them to continue accessing the user's email. However, Apple's policy gives malicious devs an obvious way out: just don't support any SSO solutions. So this policy doesn't really do anything to stop malicious devs at the end of the day. It stops them from taking advantage of alternative SSOs, but I wouldn't expect that to have much effect. I guess maybe the policy is intended to mitigate the potential damage caused by negligent devs? As in devs who are not malicious, but risk allowing malicious actors to access user data through negligent design? That feels more like stretch to me, though.