Is Sign In With Apple Better Than Google & Facebook?
Apple introduced “Sign in with Apple” feature in iOS 13. It enables users to sign up apps using apple id. Apps mostly ask users to sign in using their mobile number or email or google account or Facebook account. Apple wants to protect users personal information like mobile number & email id. So they have introduced the “Sign in with Apple” feature.
What is the problem with Google & Facebook sign in?
Google Sign in
Google provides an option for the apps to ask for users Google account details for sign up. It shares unique user id, email, first name, last name, language, gender and photo of the user to the app developer/company. It doesn’t share password of your Google account with anyone.
App can use the data provided by the Google for various purposes. They can use the email id to communicate with you for providing support and for better service.
Facebook Sign in
Facebook provides wide range of options for the app to select from your Facebook profile. It provides details like your profile photo, email id, photo gallery, friends list, likes and many more. You can decide whether to share all these details or only some details with the app.
The details you have shared from your Facebook account can be used for variety of purposes. Apps can analyze your behavior or contact your for support and many more.
Problem with Google & Facebook
Google & Facebook primarily share your email id with the app. It might help the app provider to facilitate better services. But not all apps require your email id. And the app developer/company might sell your data to third parties. Apple tried to solve this problem by providing “Hide your email id option” in “Sign in with Apple”.
Apple’s Sign in with Apple
The idea to hide the user email and provide a random email id with the app works very well in saving users privacy. When you select “Sign in with Apple” option it will ask you whether to hide the email id or not. If you select to hide your email id then a random email id is shared with the app instead of your actual email id.
For example your Apple id is “email@example.com” then apple will share @privaterelay.appleid.com with app hiding your actual id.
The unique private email id can be used for communications. Apps or websites can contact you by sending mails to the unique private email id. Apple relay servers will forward those emails to your actual email id. This will prevent apps or websites from knowing your actual email id.
Apple servers doesn’t read your email contents but checks for any spams. You can also reply to the mails you received from private relay servers, apple will handle them and deliver to app or websites.
Disadvantages for Developers
Apple has not provided any documentation for using sign in with apple on android platform. Many apps are present on both Android and iOS platforms. So to keep the user data in sync app developers should enable “Sign in with Apple” option on both the platforms. But many users doesn’t have apple accounts as they don’t use any of apple devices or services. Providing “Sign in with Apple” option doesn’t help developers much and they increase amount of work to be done for integration and changes in future.
Many Apple users use their iCloud id [@icloud.com or @me.com or @mac.com] as their Apple id. So when app or websites sends important emails they will be delivered to iCloud Mail box. Sometimes users miss those emails and get frustrated on app developer unnecessarily. In order to avoid these you need to integrate your iCloud Mails with your favorite Mail app.
Masking actual email id and providing a unique private email id to apps and websites is a very good idea. Hope Facebook and Google implements this idea. But they might not implement as they mainly depend on user behavior to provide relevant ads. Ad revenue is very critical for both Facebook & Google. Let’s see if they come up with any other better solution in securing users personal information.
Links for developers – Website Configuration – click here & iOS App Configuration – click here.