Sign In with Apple [video](developer.apple.com)
developer.apple.com
Sign In with Apple [video]
https://developer.apple.com/videos/play/wwdc2019/706/
450 comments
Completely agree. There needs to be some concept of a marketplace that doesn't have monopoly power, and a list of "fair play" rules around those. The only difference between Apple's actions and 90's Microsoft is marketshare. It's a similarly anti-competitive in intent.
European Union has some regulation for financial markets that have had similar issues in the past. The regulators must approve a rule book for market place, in this case of trading venue, which including onboarding and listing rules. Those rules must not discriminate against anyone - one cannot do arbitrary decisions to block or hinder someone. Everybody must access the markets fairly.
We already seen the regulatory outreach coming to app stores when EU ruled that Google was hindering the distribution of Aptoide store for Android.
We already seen the regulatory outreach coming to app stores when EU ruled that Google was hindering the distribution of Aptoide store for Android.
> There needs to be some concept of a marketplace that doesn't have monopoly power
The Web?
I've seen reports that Apple is finally starting to fix issued related to adding PWAs to the home screen as well.
The Web?
I've seen reports that Apple is finally starting to fix issued related to adding PWAs to the home screen as well.
can you share the source please ?
I’m not sure if this is right approach. In fact in the 70’s, the US basically went through this back and forth, largely influenced by one book:
https://en.m.wikipedia.org/wiki/The_Antitrust_Paradox
Essentially, the book advocates that the only goal antitrust laws should have is to protect consumer welfare, not competitors.
IMO, Apple’s requirement doesn’t feel like it would harm consumer welfare.
https://en.m.wikipedia.org/wiki/The_Antitrust_Paradox
Essentially, the book advocates that the only goal antitrust laws should have is to protect consumer welfare, not competitors.
IMO, Apple’s requirement doesn’t feel like it would harm consumer welfare.
A well run company could build an arbitrarily large technological and financial moat on the back of consumer welfare, until it amasses enough power to completely subjugate regulatory bodies. (This is all theoretical, I don't think Apple is at that point). OTOH, anticompetitiveness is an easier thing to detect and act upon before it gets out of control.
It seems like an absolute win for consumer welfare, to be honest.
> I don't like that it's required for developers to include if they include any other third-party sign-in.
Curious, why not?
Because if i understand correctly it's designed so that Apple cannot see any of the data... So for what reason would you want to provide another third-party provider, but not Apple Signin?
To me it seems a huge win for consumers privacy wise, and Developers have nothing to loose.
Curious, why not?
Because if i understand correctly it's designed so that Apple cannot see any of the data... So for what reason would you want to provide another third-party provider, but not Apple Signin?
To me it seems a huge win for consumers privacy wise, and Developers have nothing to loose.
developers definitely have something to lose. If nothing else, it takes time to implement a new process that you already have working.
not a win for privacy, but i'm sure there are some that would be unhappy about not getting the data the other providers are giving them.
not a win for privacy, but i'm sure there are some that would be unhappy about not getting the data the other providers are giving them.
This isnt a monopoly.
As someone who has never bought an Apple product, I can safely say their monopolistic practices don't affect me.
Stop buying Apple products. Its that simple.
As someone who has never bought an Apple product, I can safely say their monopolistic practices don't affect me.
Stop buying Apple products. Its that simple.
The OP's point is that a monopoly is not necessary in order for abusive anticompetitive behavior to occur.
I don't buy Apple products (well not exactly true I have a MacBook but only because I'm forced to use that to build for iOS). But for my app which uses 1st party login or Facebook as an alternative I am now forced to provide Apple login. If Google follows suite I'll be forced to provide Google login on Android, etc. Probably I'll just end up removing all third party login too much of a hassle, although I'll definitely lose users.
I’m not trying to be a dick, I’m genuinely interested. Why would you make a product for a platform you don’t support? Feels like a vegan owning a hamburger shop.
Is it the market size that keeps you in the iOS space? Are you on other platforms? What are the revenue/cost/effort ratios for each? Does it make sense to focus on non-iOS options?
Is it the market size that keeps you in the iOS space? Are you on other platforms? What are the revenue/cost/effort ratios for each? Does it make sense to focus on non-iOS options?
probably because it's the most profitable platform. iOS easily makes more money than Android even though it has less users. In my experience, it's not close.
Shocker. I heard you are also forced to buy a Windows PC to write software for Windows!
You aren't, you can now do that on Linux with .Net core (sans testing it).
Well if you’re happy with that then you can write your app with Xamarin Mono for iOS in Visual Studio. You can do it all in C# without even learning Swift or Objective C.
Or could cross-compile it with mingw-w64.
This is my biggest fear btw, I am making an App, and I realize I am getting close to needing to buy an Apple product to hit compile (Javascript) and fix bugs.
The only thing you can do is educate consumers on the evils of Apple and hope they make better decisions in the future.
The only thing you can do is educate consumers on the evils of Apple and hope they make better decisions in the future.
What better decision can they make?
Buy a competing product; that will help to erode the Apple monopoly.
That's similar to what happened to Windows Phone. They opened up development towards the end since they could no longer justify forcing developers to behave the way they wanted; they simply didn't have the market share to enforce it.
That's similar to what happened to Windows Phone. They opened up development towards the end since they could no longer justify forcing developers to behave the way they wanted; they simply didn't have the market share to enforce it.
They have a monopoly on the hundreds of millions of people who have an iPhone, which are typically the wealthiest mobile consumers (Sorry Android guys). If I have a software service I need to deliver to my customers smartphone, and they happen to own an iPhone, then Apple has full control over how I can do business with them. All they have to do is allow sideloading of apps with big warnings as an option and they can run the app store however they want. Until then, it's bullshit.
Do you ever wonder if Apple attracts the wealthiest mobile consumers because of the controlled user experience they provide?
The idea that a company has a monopoly on its own customers seems tautological to me. Doesn’t that mean every retail store has a monopoly on their customers because you can’t walk in and sell your own goods without their permission?
That’s not what a monopoly is. It isn’t a misuse of market power to have a lot of customers.
It’s ok to not like Apple or any company that doesn’t match your values, but it’s important to argue using the right terms and definitions, otherwise you sell yourself and your argue short.
There are alternatives to offering an app for iOS. Web apps are an example. Releasing only for Android is also a valid choice.
I don’t like paying for using a toll road, but if I want the benefit of a nice road, and a shorter travel time, I have to pay. If these benefits aren’t worth the price, I can use an alternative.
It’s ok to not like Apple or any company that doesn’t match your values, but it’s important to argue using the right terms and definitions, otherwise you sell yourself and your argue short.
There are alternatives to offering an app for iOS. Web apps are an example. Releasing only for Android is also a valid choice.
I don’t like paying for using a toll road, but if I want the benefit of a nice road, and a shorter travel time, I have to pay. If these benefits aren’t worth the price, I can use an alternative.
An important distinction is that Apple is not forcing consumers to use Apple Sign In. They are only requiring developers to offer it as an option.
Welp, there we go. I was surprised to see Apple introduce a feature that improved things for their customers without some ridiculous restriction and here we are: mandatory inclusion for app developers.
Good job Apple, you raised your image only to crush it again with anticompetitive bullshit.
Good job Apple, you raised your image only to crush it again with anticompetitive bullshit.
The killer feature here is the anonymous email address forwarding. It shows Apple actively ceding an opportunity for exchanging marketing data in favour of user privacy. It does feel like Apple are taking privacy seriously and positioning it as more than just a marketing campaign.
I am tired of seeing my email address popping up on leaks and I don't want to rely on spam filters any more. The best spam filter out there is built into gmail, but they are no longer interested in actually preventing spam, instead they want to control it. Now Google shows me ads that look exactly like emails in my inbox, inside the iOS app.
I wasn't happy with this so I built https://idbloc.co, which is basically equivalent to the disposable email element of Sign in with Apple, now that Apple built it into their Sign In, I guess now it exists for users who don't want to or can't use Apple.
I am tired of seeing my email address popping up on leaks and I don't want to rely on spam filters any more. The best spam filter out there is built into gmail, but they are no longer interested in actually preventing spam, instead they want to control it. Now Google shows me ads that look exactly like emails in my inbox, inside the iOS app.
I wasn't happy with this so I built https://idbloc.co, which is basically equivalent to the disposable email element of Sign in with Apple, now that Apple built it into their Sign In, I guess now it exists for users who don't want to or can't use Apple.
It also gives Apple far more control over the ecosystem. By not providing 3rd parties access to email, Apple makes themselves not only the controllers of the physical devices and also over the full identity of their users. My viewpoint is one of decentralization, and I don't see this move as being a long term beneficial one.
It's not a stretch of an imagination that Apple might cut a developer out of the app store for some abstract-defined violation of terms (as they do now) and now ALSO cut that developer from the identity/contact with their users. In total, this is almost the ultimate kill switch to push companies to adhere to their policies or risk a total shutout. This scenario might be considered overblown, if it wasn't that Apple already exercises pushy monopoly(esk) control on their ecosystem. The new identity system expands that control to now outside the Apple hardware ecosystem, possibly affecting platforms like Android.
I'm ranting here a little, but I think we should be cautious of accepting privacy as the sole reason Apple wants to enforce all app authentication to use.
It's not a stretch of an imagination that Apple might cut a developer out of the app store for some abstract-defined violation of terms (as they do now) and now ALSO cut that developer from the identity/contact with their users. In total, this is almost the ultimate kill switch to push companies to adhere to their policies or risk a total shutout. This scenario might be considered overblown, if it wasn't that Apple already exercises pushy monopoly(esk) control on their ecosystem. The new identity system expands that control to now outside the Apple hardware ecosystem, possibly affecting platforms like Android.
I'm ranting here a little, but I think we should be cautious of accepting privacy as the sole reason Apple wants to enforce all app authentication to use.
> By not providing 3rd parties access to email, Apple makes themselves not only the controllers of the physical devices and also over the full identity of their users.
No they're not. They're preventing third parties from accessing your data. You can communicate with your customers just fine; it's just that if you sell their data (or get hacked) the email you get is useless.
No they're not. They're preventing third parties from accessing your data. You can communicate with your customers just fine; it's just that if you sell their data (or get hacked) the email you get is useless.
> it's just that if you sell their data (or get hacked) the email you get is useless.
The parent commenter is correctly pointing out that Apple would be able to disable the email for other reasons as well.
The parent commenter is correctly pointing out that Apple would be able to disable the email for other reasons as well.
Also, this is probably ment to further lock users into the Apple ecosystem.
It's not like you can ask Apple to forward emails to your own email server if you decide that you no longer want to use Apple.
It's not like you can ask Apple to forward emails to your own email server if you decide that you no longer want to use Apple.
Which is provably false. (1) AppleID email address doesn’t have to be iCloud mail; they’ll be forwarding to my mail server in the first place. (2) iCloud account is free, whether or not you decide to stop using Apple devices doesn’t affect that. (3) They said Sign in with Apple will be available on non-Apple platforms. (4) I doubt third parties can’t offer an option to decouple Apple entirely if you so choose.
You can also provide your own email address. The choice is yours. Which threat do you think is greater?
I think Apple shutting down your access is a legitimate concern. Yet Apple is the only one who has taken any steps to protect the customer here. The reality is we are unlikely to see other major competitors to Apple find a better alternative because their entire business is built on exploiting user data.
And 3rd parties who create a similar system are unlikely to be successful because they don’t have the clout to convince websites to incorporate them.
I think Apple shutting down your access is a legitimate concern. Yet Apple is the only one who has taken any steps to protect the customer here. The reality is we are unlikely to see other major competitors to Apple find a better alternative because their entire business is built on exploiting user data.
And 3rd parties who create a similar system are unlikely to be successful because they don’t have the clout to convince websites to incorporate them.
Until they remove the forward to your inbox?
If you can see the forwarding address, then you could probably somehow contact the company to switch your account. Not extremely secure and would require more validation than simply knowing the random bits of the address, but doable.
Your gmail, Hotmail, yahoo inbox ! Who can disable your account for some undisclosed slight
You can access iCloud email through IMAP/SMTP on any operating system you want, just like you can access the calendar through CalDAV and the address book through CardDAV. Apple isn’t Microsoft.
By that logic Apple can disable your iPhone for other reasons etc etc
They absolutely could technically. The more important questions are:
- Is there a big enough reason to motivate them to do so?
- If given a "legitimate" justification, would they?
If either of those are "yes" then the question we need to know is: "Is there any appeal, oversight, etc?"
- Is there a big enough reason to motivate them to do so?
- If given a "legitimate" justification, would they?
If either of those are "yes" then the question we need to know is: "Is there any appeal, oversight, etc?"
This is how it starts.
I think the concern is that Apple could exert influence over third party apps/networks because they control access to all Apple users. That problem doesn’t really exist when it comes to Apple disabling entire iPhones of certain users.
This would be a customer action — it affects one person. Unless you’re implying they’d disable the phone of every user of a certain app or something to that effect.
With these emails they could trivially, and surgically, cut off a developer from every customer. It is a one-to-many action that also has no obvious other side effects (unlike bricking users phones).
Not sure where I stand with this, but wanting to point out that the added powers this gives Apple are very real and different from the ones they had before (again, maybe this is a good thing, but it’s undeniable that it is a different thing).
With these emails they could trivially, and surgically, cut off a developer from every customer. It is a one-to-many action that also has no obvious other side effects (unlike bricking users phones).
Not sure where I stand with this, but wanting to point out that the added powers this gives Apple are very real and different from the ones they had before (again, maybe this is a good thing, but it’s undeniable that it is a different thing).
”it's just that if you sell their data (or get hacked) the email you get is useless.”
It’s just that whenever Apple decides so, the email you got becomes useless.
Apple is judge, jury and executioner, and it makes the laws. That is problematic.
It’s just that whenever Apple decides so, the email you got becomes useless.
Apple is judge, jury and executioner, and it makes the laws. That is problematic.
Only if the customer wants them to be. If the customer wants to give you their real email address, they are free to do so. If they choose not to give that to you, but you want to contact them anyway because you think you know their desires better than they do, well... that’s exactly why this is needed.
If Apple decides to cut off a developer, it doesn't matter what their customers want. Unless they had the foresight to bypass the default and use their real e-mail, there is no way for users to prove their accounts belong to them without Apple's co-operation. Their access to their accounts is entirely at Apple's mercy and there is (by design) nothing the developers can do to avoid this.
Right, there’s nothing the developers can do to avoid this. Because it’s the users making the choice. They choose to give Apple this power, or not. You are essentially arguing that they will choose incorrectly, and that developers should be able to force them to choose correctly because users won’t think it through. By a strange coincidence, the “correct” choice is also the one that allows developers to track and spam users.
Here’s a crazy idea: if you don’t want your users giving you a private forwarding address, give them some reason to trust you with their real one, instead of saying they’re idiots who don’t know what’s best for themselves.
Here’s a crazy idea: if you don’t want your users giving you a private forwarding address, give them some reason to trust you with their real one, instead of saying they’re idiots who don’t know what’s best for themselves.
You're advocating for the users to make their choice at the worst possible time. There's no reason to give a new app special trust when you sign up with it.
But if you come to trust the app, and Apple excommunicates it, should you need to rely on Apple to help you reestablish your own contact with it? That won't work -- Apple already demonstrated that they don't like that app.
That's why makomk's complaint is
> there is no way for users to prove their accounts belong to them without Apple's co-operation
rather than "I should be able to get customer emails from Apple regardless of what the customers want".
But if you come to trust the app, and Apple excommunicates it, should you need to rely on Apple to help you reestablish your own contact with it? That won't work -- Apple already demonstrated that they don't like that app.
That's why makomk's complaint is
> there is no way for users to prove their accounts belong to them without Apple's co-operation
rather than "I should be able to get customer emails from Apple regardless of what the customers want".
You could always allow users to provide their real email address later on so they can establish ownership directly.
The authentication using OATH and the email forwarding of aliases are two separate but related services.
If Apple for some reason doesn’t allow the app maker to use the OATH service, I doubt very seriously that they will cancel the email forwarding without the user specifically turning off the forwarding.
At that point both the user and the app provider both have generated email address.
If Apple for some reason doesn’t allow the app maker to use the OATH service, I doubt very seriously that they will cancel the email forwarding without the user specifically turning off the forwarding.
At that point both the user and the app provider both have generated email address.
> I doubt very seriously that they will cancel the email forwarding without the user specifically turning off the forwarding.
Where's this confidence coming from? If Apple sees it fit to prevent you (the developer) from accessing your Apple specific userbase for any reason / violation, other people seem correct in their theorization that there's nothing you can really do as the developer.
Not implementing this new "Sign in with Apple" will also probably be interpreted as not being privacy friendly by the users, a developer can't really have that either.
Pretty much the definition of being stuck between a rock and a hard place.
Where's this confidence coming from? If Apple sees it fit to prevent you (the developer) from accessing your Apple specific userbase for any reason / violation, other people seem correct in their theorization that there's nothing you can really do as the developer.
Not implementing this new "Sign in with Apple" will also probably be interpreted as not being privacy friendly by the users, a developer can't really have that either.
Pretty much the definition of being stuck between a rock and a hard place.
How is this not completely true of every service?
If Facebook sees it fit to prevent you (the developer) from accessing your FB specific user base for any reason / violation there is nothing you can really do.
If Google sees it fit to prevent you (the developer) from accessing your Google specific user base for any reason / violation there is nothing you can really do.
Worse
If Gmail sees it fit to prevent you (the developer) from accessing your Gmail specific user base for any reason / violation there is nothing you can really do. Gmail already does this occasionally by quickly blacklisting non Gmail senders in their spam filters.
If Facebook sees it fit to prevent you (the developer) from accessing your FB specific user base for any reason / violation there is nothing you can really do.
If Google sees it fit to prevent you (the developer) from accessing your Google specific user base for any reason / violation there is nothing you can really do.
Worse
If Gmail sees it fit to prevent you (the developer) from accessing your Gmail specific user base for any reason / violation there is nothing you can really do. Gmail already does this occasionally by quickly blacklisting non Gmail senders in their spam filters.
Not really a completely fair comparison. With FB / Google, most people at least have the hope of migrating away using setting the email / phone (Google provides this, FB doesn't) as username.
If Apple tells you to take a hike, and then subsequently disables the email redirect -- you're completely SOL. You'd have no way to reach out to the user anymore, unless you took other identifying bits of info. And if you did that anyway, that defeats the purpose of AppleID to begin with.
Most users will probably not even be tracking what autogenerated email they're using, hence you no longer have a way to reliably reconcile what user had which account.
Regarding the GMail specific case though, I fully agree. Being banned by GMail is a company ending thing.
If Apple tells you to take a hike, and then subsequently disables the email redirect -- you're completely SOL. You'd have no way to reach out to the user anymore, unless you took other identifying bits of info. And if you did that anyway, that defeats the purpose of AppleID to begin with.
Most users will probably not even be tracking what autogenerated email they're using, hence you no longer have a way to reliably reconcile what user had which account.
Regarding the GMail specific case though, I fully agree. Being banned by GMail is a company ending thing.
Apple said that they are going to allow the user to disable an auto forwarding address. I’m assuming there would be some way for the user to see a list of app -> email address associations.
> Where's this confidence coming from?
Probably from the fact that disabling these email addresses would be a distinctly user-hostile move. If Apple determines that the developer is actually a malicious entity who slipped malware past the App Review process, then it might be reasonable for them to disable the forwarded emails as well as a malware vendor has no legitimate reason to talk to "users", but beyond that specific scenario, cutting off the email address harms the users who signed up for that service. For example, if the app actually represents a web service, and Apple determines that the app shouldn't be in the App Store for whatever reason, blocking "Sign In With Apple" (which is distinct from removing the app from the app store) and cutting off the email address means the user has no way to recover their account even though the service is still active, just without an app. There is no reason for Apple to take this step as it benefits nobody and only serves to harm Apple user.
Probably from the fact that disabling these email addresses would be a distinctly user-hostile move. If Apple determines that the developer is actually a malicious entity who slipped malware past the App Review process, then it might be reasonable for them to disable the forwarded emails as well as a malware vendor has no legitimate reason to talk to "users", but beyond that specific scenario, cutting off the email address harms the users who signed up for that service. For example, if the app actually represents a web service, and Apple determines that the app shouldn't be in the App Store for whatever reason, blocking "Sign In With Apple" (which is distinct from removing the app from the app store) and cutting off the email address means the user has no way to recover their account even though the service is still active, just without an app. There is no reason for Apple to take this step as it benefits nobody and only serves to harm Apple user.
I agree, the move is user hostile and the bad PR wouldn't likely be worth it for Apple. Social media shaming is a real thing, and I'm glad for that.
I'll even go one step further and say that I personally don't think Apple will do it unless under extreme circumstances.
The thing is though, business continuity assessment still points to adopting Apple login to be a bad idea. You never really know when you'll find yourself in hot water with one of your vendors, especially a vendor who's a LOT more powerful than you.
I'll even go one step further and say that I personally don't think Apple will do it unless under extreme circumstances.
The thing is though, business continuity assessment still points to adopting Apple login to be a bad idea. You never really know when you'll find yourself in hot water with one of your vendors, especially a vendor who's a LOT more powerful than you.
The aliased email address is assigned to the user. Saying that Apple would take away the users email address would be like saying that Apple would delete user data for an app it banned.
Whether Apple will exercise the power or not is another debate entirely.
I agree with the group that's (rightfully, imo) concerned about handing over this amount of power over their business to any 3rd party. There's a real potential for abuse.
I agree with the group that's (rightfully, imo) concerned about handing over this amount of power over their business to any 3rd party. There's a real potential for abuse.
And handing over your users data to known privacy hostile companies like Facebook and Google who have abused their power isn’t?
How is that different from signin with FB or Google?
FB and Google allow the app to request the user's email. If the user is happy to provide it, then they can then tie the user's account to that email, and allow the user to log in with that email even if FB or Google cuts the application off.
How is this any different from Google or Facebook or Twitter cutting off access to any site/application? Do you believe the developers in those cases would have a much better chance of resolving the issue than with Apple?
That sounds like a great feature. I would love for the ability to make an email address inactive after I sign up.
The percent of times I want to recieve email communication from something I have to sign up for is very close to 0.
The percent of times I want to recieve email communication from something I have to sign up for is very close to 0.
Get your own domain through someone that has an email service that supports aliases. Every sign up can have a different address. It's like $10 per year and you're email is not at the mercy of whatever mega-corporation owns your email.
Any suggestions on which provider to use?
As the people above mentioned, look for one that supports a catch-all address. It makes it very easy to manage. You can even respond using a real "DoNotReply" account and the alias as the "replyto" address for the rare occasions you do want to reply. Yes, Google Apps does this well, but there must be others.
Google Apps works great for this. You can also setup a catch-all account and not need to pre-configure the aliases in advance.
I use FastMail like this. They support both catch-all ([email protected]) and user-specific forwards ([email protected] -> [email protected]) for domains with multiple users.
IMO, it depends on how many mailboxes and aliases you need. Providers like Fastmail charge by the mailbox (with up to 600 aliases for each). Same with Runbox, Mailbox.org, etc. (the number of aliases varies). Migadu provides unlimited domains, mailboxes and aliases for a fixed price that decides how many outgoing mails you can send everyday from all mailboxes in that account.
What about resetting your password?
Every big company has their own laws. G,F are abusing and Apple is providing the solution and I think it is far better than what we have.
I think the question is, is it more problematic than the current situation, whereby users wholly distrust companies with their data, because those companies have shown again and again that they can not be trusted with it? I’d say no.
That’s one possible question. Another is whether an even better remedy exists.
For example, do we need the ability for Apple to delete the link between a company and all their users in one sweep, or is it sufficient to make it easy for individual users to cut such ties?
If the latter, could we remove that giant master switch, or move control of it to a third party?
(I haven’t watched the video, so, possibly, that giant switch doesn’t exist. Skimming https://developer.apple.com/sign-in-with-apple/get-started/ didn’t tell me that, either)
For example, do we need the ability for Apple to delete the link between a company and all their users in one sweep, or is it sufficient to make it easy for individual users to cut such ties?
If the latter, could we remove that giant master switch, or move control of it to a third party?
(I haven’t watched the video, so, possibly, that giant switch doesn’t exist. Skimming https://developer.apple.com/sign-in-with-apple/get-started/ didn’t tell me that, either)
> That’s one possible question. Another is whether an even better remedy exists.
There is, it's called IM2000 where email becomes a pull-based system instead of push-based (so users would have to consent to spam, and spammers have to store their spam to send it in bulk). Unfortunately, despite many attempts to switch over we're still stuck on the current incarnation of SMTP.
There is, it's called IM2000 where email becomes a pull-based system instead of push-based (so users would have to consent to spam, and spammers have to store their spam to send it in bulk). Unfortunately, despite many attempts to switch over we're still stuck on the current incarnation of SMTP.
Looking it up, it removes so many advantages of email, such as I don’t lose old mail when your now defunct IM2000 ISP goes out of business.
There also isn’t an easy transition from now — I can see exactly why we’re “stuck” with what’s actually a pretty great last bastion of decentralization on the Internet, for all its warts.
There also isn’t an easy transition from now — I can see exactly why we’re “stuck” with what’s actually a pretty great last bastion of decentralization on the Internet, for all its warts.
You could always use IMAP to sync your email as normal. The advantage of IM2000 is that it just changes the server-to-server protocol (with some changes for how clients send emails).
But yes, the transition would require replacing SMTP so once again we're stuck on a system that is terrible enough to grumble about but not terrible enough to change.
(I would also argue that Matrix is becoming a new decentralised system for the internet, as well as ActivityPub depending on who you ask.)
But yes, the transition would require replacing SMTP so once again we're stuck on a system that is terrible enough to grumble about but not terrible enough to change.
(I would also argue that Matrix is becoming a new decentralised system for the internet, as well as ActivityPub depending on who you ask.)
If a better remedy exists someone else can build it. Nobody is forcing us to use Apple products/services.
The commenter is saying that Apple controls the email address and forwarding too, so you cant actually communicate with your customer if they don't want you to.
If you trusted the company enough to give them your email address directly, I'm sure you would've done that. This is a great move. I get so much spam and I'd like to be able to not get it if I don't want it. Long after I've moved on from a service they are still sending me emails to get me back or to do some other transactions with them.
Yes, and that's simply not true (if you want to be communicated with). You can communicate with the address just fine if you configure your email properly. The only "issue" is that there's a shortlist of valid from emails that you as a company need to configure before sending me an email. Dunno about you but insofar as I'm concerned: please f'ing sign me up for the same everywhere else! And just for clarity in case anyone reading thinks I'm some privacy concerned lunatic: I'm a marketer.
This is not about configuration. Apple provides a proxied email and controls the forwarding. They can disable that and prevent the company from sending anything to a customer. What part of that is not true?
It’s not true in that this is not mandatory. Users are free to provide a non-private or even a non-Apple email. Apple only has as much control as your users give them. If you think that’s bad, maybe you should consider why those users don’t trust you.
By that logic, Google controls Gmail and they can control access to your email.
As I understand the original commenter's position it is that:
1. when your business is on the app store it can be difficult not doing whatever Apple wants you to do because not doing what they want you to do can come close to destroying your business. This has often been compared to being a hostage of Apple.
2. If you suddenly decide to stop paying the Apple tax or if Apple decides to ban you - cutting you off from new business - it can certainly be problematic and can kill many businesses but you could theoretically keep going because you could have a customer base you inform of your decision and tell them to download your app from your homepage instead of the app store etc. In short - in the event of Apple not liking you anymore you can communicate with your customers.
3. In this new setup if Apple does not like you anymore you cannot tell your customers hey Apple doesn't like me anymore.
Thus Apple increases its ability to hold your company hostage and thus I do not believe it is the same logic as Google controls Gmail unless when selling an Android app Google only allows you to do so if your customer has a Gmail account.
1. when your business is on the app store it can be difficult not doing whatever Apple wants you to do because not doing what they want you to do can come close to destroying your business. This has often been compared to being a hostage of Apple.
2. If you suddenly decide to stop paying the Apple tax or if Apple decides to ban you - cutting you off from new business - it can certainly be problematic and can kill many businesses but you could theoretically keep going because you could have a customer base you inform of your decision and tell them to download your app from your homepage instead of the app store etc. In short - in the event of Apple not liking you anymore you can communicate with your customers.
3. In this new setup if Apple does not like you anymore you cannot tell your customers hey Apple doesn't like me anymore.
Thus Apple increases its ability to hold your company hostage and thus I do not believe it is the same logic as Google controls Gmail unless when selling an Android app Google only allows you to do so if your customer has a Gmail account.
Yes, that's also a problem that people have brought up several times in other stories. Google/Gmail has outsized control, is a major source of spam, and changes or breaks email standards whenever they want.
Centralization of communications is not a good thing and it's worth discussing whether we're going in the right direction.
Centralization of communications is not a good thing and it's worth discussing whether we're going in the right direction.
Not the same:
Google does not have a mapping between an application and email address the customer used in that application. Also Google is not really enticing a customer not to provide the service provider any email address other than the ones in the mapping.
Google does not have a mapping between an application and email address the customer used in that application. Also Google is not really enticing a customer not to provide the service provider any email address other than the ones in the mapping.
FastMail, ProtonMail, or an AWS server upon which your run your own email can also be disabled by the owner of that service. Unless you run your own on-premise server, that risk always exists. And even then, your ISP could block your server. There comes a point when the paranoia gets unreasonable.
You can switch your DNS and move your mailbox, but you have no control over Apple's proxying service.
I suspect that GP originally wrote "so you cant actually communicate with your customer", to which I answered in the next minute, and later added "if they don't want you to." (If not, my mistake for misreading.)
This version is deplatforming is going to be oh so much fun.
Is that true? If the only email address that a company has for a user is a forwarding address created through Sign In, wouldn't Apple banning the company from the App Store presumably also cause them to get rid of the email forward, meaning that nothing the company sends will actually reach the customer?
If a company is abusing Apple's users I'm sure that they could?
But you're right, it does give Apple power, just the same power that has already ceded to Facebook and Google through their logins.
The reality is that companies need to understand that user's are sick and tired of being spammed, and are rightly annoyed by needing to provide every company with their email address for no good [to the user] reason.
But you're right, it does give Apple power, just the same power that has already ceded to Facebook and Google through their logins.
The reality is that companies need to understand that user's are sick and tired of being spammed, and are rightly annoyed by needing to provide every company with their email address for no good [to the user] reason.
I think the difference is that with a Facebook or Google login, companies could also easily just require that they get permission to see the user's email address (which isn't super uncommon to see with OAuth logins), so they wouldn't need continual access to OAuth after the first login (unless a user switched to a new email address and stopped checking the old one, which I think is somewhat rare).
I totally agree with your point that this is arguably a good thing, though; although I don't personally own or use any Apple products, there are fairly few services I'd want to sign up for that I'd want to ensure that they had my real email, and I'd be happy to make sharing my email address an opt-in choice rather than the default.
I totally agree with your point that this is arguably a good thing, though; although I don't personally own or use any Apple products, there are fairly few services I'd want to sign up for that I'd want to ensure that they had my real email, and I'd be happy to make sharing my email address an opt-in choice rather than the default.
Or, you host a video site like YouTube, you’re not aggressive enough in controlling “hate speech,” and Apple boots you from the platform. How, as a user of this app, am I supposed to re-establish control over my account?
Apple holding the ID information and all that that pertains is the only company I would like to hold that data. I can see no reason why Facebook or Google or any company that profits on the sale of information should have my data. I appreciate that advertisers want to maximize their ad spends but ad-tech has gotten so creepy ... Apple’s move here I fully support. I look forward to seeing apps using it more often and perhaps eventually all the apps I use as well so that I can move all my logins via it.
Apple sells me thousand dollar phones and services. Until they start selling my data to ad brokers and becoming a Google I’ll support Apple on this going forward.
Apple sells me thousand dollar phones and services. Until they start selling my data to ad brokers and becoming a Google I’ll support Apple on this going forward.
The reason it got so "creppy" is because that is how Google makes money; meaning that if this Apple-sign-in or anything else truly messes with their revenue Google will stop accepting Apple email addresses (or any kind of circumvention to their tracking), and they are fully in their right to do so.
Google would be stuck here. Apple users are some of the most valuable users on the internet. Pushing them away would also hurt Google's bottom line.
I know. And I’m sure they know it, too. They and the rest of the industry will just have to find new business models that respect privacy. If they can do that and this privacy first kick doesn’t fade out of favor they will be on top still printing money like always but if not they’ll get left behind. I think the thesis that Apple is going with is hardware and paid for services are the future and free to use things like the open web are going out of favor or must if you want to be secure and anonymous online.
Google doesn't sell your data. They sell adds to companies that they show to you. The companies never see your data, and it's effectively Google's most valuable resource. They have far more reason to keep it safe than Apple. Doesn't Apple sell ads as well, btw?
Also, you may want to check the news about Apple selling data ...
Also, you may want to check the news about Apple selling data ...
The big difference is that Apple does not have the incentive to collect user data in the first place. This is why Apple's ML strategy has tended to lean towards on device, while Googles has been in the cloud. Apple has taken the stance that the best way to keep a users data safe is to never have access at all.
Google aggregates all its data points about me and sells that as a service to advertisers. It makes sense. Advertisers want to pay for ads that will lead to sales.
Yes Apple sells ads on its AppStore and allows ads in apps. But what they sell is the chance to be in front of a billion affluent iOS owners which is different than using every bit of data from every Google property to create a profile of a user so as to target ads even more effectively or show you even more extreme videos to keep you ever more engaged a la YouTube.
Yes Apple sells ads on its AppStore and allows ads in apps. But what they sell is the chance to be in front of a billion affluent iOS owners which is different than using every bit of data from every Google property to create a profile of a user so as to target ads even more effectively or show you even more extreme videos to keep you ever more engaged a la YouTube.
You're welcome to add non-social logins. The constraint is that if you add any social logins, you also have to support Apple Sign-In.
There is no requirement that you only support apple sign-in, you just aren't allowed to require user's to sacrifice their privacy to use your app.
There is no requirement that you only support apple sign-in, you just aren't allowed to require user's to sacrifice their privacy to use your app.
This is a big deal. One of the reasons services are so keen to require e-mail addresses from users with social logins is so that, if they drop that login service for whatever reason, users can recover access to their accounts using their email address. (A few major sites have done this recently, if I remember rightly.) This effectively eliminates that safeguard. They're not just forced to implement Apple Sign-In, but to make themselves dependent on it forevermore in a way that cautious companies have avoided.
What's a social login, though. At what point is Instagram using facebook a social login or not (it's the same company).
This isn’t a fuzzy abstract line-in-the-sand thing; social logins are specific libraries, and either you’ve got those libraries in your app or you don’t.
If Instagram is using https://developers.facebook.com/docs/facebook-login/ with the little “log in with Facebook” button, it’s a social login. If they have their own proprietary way to do it in-house, it’s not, and not subject to Sign In With Apple.
That easy.
If Instagram is using https://developers.facebook.com/docs/facebook-login/ with the little “log in with Facebook” button, it’s a social login. If they have their own proprietary way to do it in-house, it’s not, and not subject to Sign In With Apple.
That easy.
It's not that easy. Instagram belongs to facebook. So logging in with facebook is not strictly a "social login". Same with Tinder, IIRC they only had facebook login, to piggyback on the fb profile. That's not really social as in "chose one of those providers".
If it "chose provider" then yes, apple could shove in their own with the pretense of user privacy, while it is painfully obvious that it's just leveraging their appstore control to grab market.
Not even OAuth can be unambiguous. I can have a single OAuth login. That could be myself as provider, or leveraging some other provider, which could be more or less connected to my app.
If it "chose provider" then yes, apple could shove in their own with the pretense of user privacy, while it is painfully obvious that it's just leveraging their appstore control to grab market.
Not even OAuth can be unambiguous. I can have a single OAuth login. That could be myself as provider, or leveraging some other provider, which could be more or less connected to my app.
I'm guessing olliej meant OAuth provider. FB and Google are the leading ones, so people implement those. Sign in with Apple is one as well.
The comment is saying you're free to implement your own auth mechanism using plain ol email or a phone number, but you also have to support Sign in with Apple
The comment is saying you're free to implement your own auth mechanism using plain ol email or a phone number, but you also have to support Sign in with Apple
Indeed, technically it's any OAuth provider, but in reality how many
a. actual users have a non-FB/Google OAuth identity
b. apps have something other than google or facebook login?
I've literally never encountered an app that had anything other than google or facebook for their oauth login. The only site I ever encountered that used something different was stack overflow a decade ago, and I recall them killing it off or at least complaining about it.
I suspect that the reality is that in a regular user's experience Google and Facebook login are the only ones they've ever encountered.
a. actual users have a non-FB/Google OAuth identity
b. apps have something other than google or facebook login?
I've literally never encountered an app that had anything other than google or facebook for their oauth login. The only site I ever encountered that used something different was stack overflow a decade ago, and I recall them killing it off or at least complaining about it.
I suspect that the reality is that in a regular user's experience Google and Facebook login are the only ones they've ever encountered.
We also offer LinkedIn, GitHub, Yandex and (soon) WeChat. Most users actually use LinkedIn, but we are a recruitment firm so the stats are biased, but it's not true that only Google and FB are the options offered everywhere, at least not in this part of the world.
GitHub is a provider that I use to sign in to some sites.
By not providing 3rd parties access to email, Apple makes themselves not only the controllers of the physical devices and also over the full identity of their users
Third party apps don't have to use e-mail for logins. They can use user names.
Backers of e-mail based sign-in often call it a "frictionless" method for the users to sign up. What it really is, is a frictionless method for them to collect information about their users.
Third party apps don't have to use e-mail for logins. They can use user names.
Backers of e-mail based sign-in often call it a "frictionless" method for the users to sign up. What it really is, is a frictionless method for them to collect information about their users.
As a user, I'd much rather use my email than have to make up a new username for every site. Emails are already public, it's not always some cynical conspiracy.
Uh, email addresses aren't already public - there isn't some magic email directory in the cloud (I mean aside from those aggressively hoarded by trackers, advertisers, and marketers because you had no choice but to use your real address once).
But this is also specific to "social" logins - eg ones where you aren't intentionally providing your email address.
But this is also specific to "social" logins - eg ones where you aren't intentionally providing your email address.
They're a public endpoint designed to intake communications from anybody. Identity is an outcome from people using the same email, and that's a valid reason for using a proxy, but the address itself has always been public.
More in-depth article about it: https://www.troyhunt.com/im-sorry-but-your-email-address-is-...
More in-depth article about it: https://www.troyhunt.com/im-sorry-but-your-email-address-is-...
If you just have a username and password, what do you do for account recovery after a forgotten password? If not an email address, would a cell phone number be any better?
For accounts that really matter (not throwaways), someone needs to know a fair bit about the user's identity to ensure recovery works. It can be delegated (and probably should be), but that moves the identity problem rather than eliminating it.
Maybe someday we'll all have two Yubikeys (one for backup) and register with each website using them, but that's not how things work today for most users.
For accounts that really matter (not throwaways), someone needs to know a fair bit about the user's identity to ensure recovery works. It can be delegated (and probably should be), but that moves the identity problem rather than eliminating it.
Maybe someday we'll all have two Yubikeys (one for backup) and register with each website using them, but that's not how things work today for most users.
You obviously provide an E-mail address in your user profile. You don't have to log in with it.
This "problem" has been routinely solved by free forum software and other systems for decades now.
This "problem" has been routinely solved by free forum software and other systems for decades now.
Yes, but traditionally we didn't mind sharing our E-mail address with random Internet forums.
(I still don't. My email address is public. But some people apparently do.)
(I still don't. My email address is public. But some people apparently do.)
The only accounts that really matter to me are:
- financial accounts: they would never use a third party login anyway.
- social accounts: None of them are going to let you login with third party accounts anyway.
- work accounts: Again they arent going to use social media accounts. They are going to use some type of ADFS federated account.
- My AWS account: I use Google Authenticator for that.
- financial accounts: they would never use a third party login anyway.
- social accounts: None of them are going to let you login with third party accounts anyway.
- work accounts: Again they arent going to use social media accounts. They are going to use some type of ADFS federated account.
- My AWS account: I use Google Authenticator for that.
Google lets you set a backup email for account recovery.
I lost my original Reddit account because I never gave them my email address and it was hacked. (Using a throwaway password set back when I didn't care about Reddit.) I contacted support and they shut it down, but without some other way of knowing it belonged to me, wouldn't give me my account back.
I lost my original Reddit account because I never gave them my email address and it was hacked. (Using a throwaway password set back when I didn't care about Reddit.) I contacted support and they shut it down, but without some other way of knowing it belonged to me, wouldn't give me my account back.
My comment was directed more to using “Sign in with Apple” for accounts “you care about”. None of the accounts I care about, use third party logins.
Apple not only gets more power over the app developers, they also get more power over the users. If you want to leave apple devices behind, you'll now need to change your e-mail addresses for every service.
You can have and use an Apple ID/email without owning an Apple device.
And you don’t need an Apple email address to use an Apple ID.
Didn't know that, interesting. Thanks.
If I want to switch away from Gmail or Facebook, it's the same exact process. This is a problem, but not any worse than the alternatives.
You don't need to leave your icloud behind even if you're leaving Apple devices.
I agree that Apple's intentions are not beneficent, but that's also not the point. There is a strong bias in tech/geek culture towards "decentralization" (it's even become something of a marketing buzzword thanks to recent technologies), but decentralization does not always result in more power for the individual. Look at the Android ecosystem. Do you feel like you're in control on your Android device? I used to think that. Maybe 2-3+ years ago. Today? Not so much. I feel like an Android device is just a means for any number of third parties to gain access to the most private details of my life. That does not make me feel like I have power. It makes me feel powerless.
> Do you feel like you're in control on your Android device?
Absolutely. I have hundreds of different independent ROMs to choose from many of which are completely FOSS. I get to add or remove any app I want and don't even have Google Play services installed.
The only software I don't control on the device are the proprietary drivers and boot loader. But that's no different from my Linux desktop.
Absolutely. I have hundreds of different independent ROMs to choose from many of which are completely FOSS. I get to add or remove any app I want and don't even have Google Play services installed.
The only software I don't control on the device are the proprietary drivers and boot loader. But that's no different from my Linux desktop.
While this is entirely true, it’s not effectively true for the average non-technical user. Balancing control of one’s personal content in a way the average user can take advantage of is something Apple, whether benevolent or not, has been an effective champion of as of late. And I (and many others) would argue that therein lies an important distinction at iPhone scale.
I couldn’t agree more. It’s quite easy for more technically adept users to forget how scary and daunting something like custom rom installs can be. Just because something is technically feasible, doesn’t mean it’s accessible to many or even most users.
Wow cool
Rather than complete decentralization, maybe what we're looking for is having opposing large organizations, as popularized by John Kenneth Galbraith?
https://en.m.wikipedia.org/wiki/Countervailing_power
https://en.m.wikipedia.org/wiki/Countervailing_power
It’s a very good point.
I think you are right that it will be an issue in the long term if things stay the same. Somewhere I hope this forces the other players in the field to react, to avoid Apple getting too much power.
I don’t see anyone else right now that can force app devs to support this scheme (for instance I saw countless signup pages that reject gmail’s + syntax, companies clearly don’t want to be filtered), nor that would be trusted for now by users to not abuse the situation.
Perhaps Microsoft could ? barely, as they for instance were sticking ads in their browser.
So, in a way I see Apple doing what only them can do, and hope it creates enough precedence for other minor identity managers to step in and being a more sane solution for the long run.
I think you are right that it will be an issue in the long term if things stay the same. Somewhere I hope this forces the other players in the field to react, to avoid Apple getting too much power.
I don’t see anyone else right now that can force app devs to support this scheme (for instance I saw countless signup pages that reject gmail’s + syntax, companies clearly don’t want to be filtered), nor that would be trusted for now by users to not abuse the situation.
Perhaps Microsoft could ? barely, as they for instance were sticking ads in their browser.
So, in a way I see Apple doing what only them can do, and hope it creates enough precedence for other minor identity managers to step in and being a more sane solution for the long run.
Microsoft already tried a single login platform. They were one of the firsts. It’s a hard product to land.
https://en.m.wikipedia.org/wiki/Microsoft_account
https://en.m.wikipedia.org/wiki/Microsoft_account
It's a hard product to land if no-one trusts you.
Maybe, but I trust Microsoft more than Google. The trust list, Apple > Microsoft > Google > Facebook.
It's a pretty easy product to land when you control the hardware, the OS, the developers, and to a large extent, the users.
Could this make accounts less transferable between platforms? Eg, an audio book app account?
They said "you must implement sign-in with apple if you implement other third party logins". The inference is
A) You (app developer) can build your own login - then this is not an issue
B) You (user) can switch login - developer has to provide this switch feature, but if they do, it is not an issue
Why are we calling the service you want register with for the third party?
You are the 1st party, the service you want to use is the 2nd party and Apple is the 3rd party.
You are the 1st party, the service you want to use is the 2nd party and Apple is the 3rd party.
Yes but as a user I don’t care. If a developer gets booted then it’s probably because the developer didn’t do something that was in the best interest of the user. Probably frustrating for developers, but again, not my problem. I also highly doubt Apple would do this without a good reason, so again, this is pro-user. As a user, I don’t care if it’s annoying to implement some feature or other or computer with onerous requirements. If a developer doesnt want to comply, then shut down the company.
I don’t understand this complaining. Everyone who has a business has to deal with these sorts of things. That’s why people pay businesses, so we don’t have to deal with the hassle. This is the essence of running a service, such as developing apps.
I don’t understand this complaining. Everyone who has a business has to deal with these sorts of things. That’s why people pay businesses, so we don’t have to deal with the hassle. This is the essence of running a service, such as developing apps.
> that was in the best interest of the user
Or in the best interest of Apple.
Or in the best interest of Apple.
As a user, why should I care if it’s also in the best interest of Apple? As a user, I want to use my phone and use services on that phone. The business position of Apple does not concern me. Users only care about what’s best for them. Apple stopping companies from screwing me over sounds great from my perspective. As far as I’m concerned, Apple can make as much money as they want, it’s no skin off my teeth.
“But then Apple will be a monopoly and you’ll get screwed anyway”. Maybe. But no more than I’m already being screwed by every other cable provider, cell phone company, data broker...etc. I like Apple products. I will continue to spend too much money on them. I’d rather be screwed by Apple in exchange for some pro-user policies, than screwed by every other company that’s already screwing me in exchange for...oh right, nothing.
“But then Apple will be a monopoly and you’ll get screwed anyway”. Maybe. But no more than I’m already being screwed by every other cable provider, cell phone company, data broker...etc. I like Apple products. I will continue to spend too much money on them. I’d rather be screwed by Apple in exchange for some pro-user policies, than screwed by every other company that’s already screwing me in exchange for...oh right, nothing.
When the best interests of Apple and the best interests of its customers diverge sufficiently, the customers will leave. This is their entire pitch, so they better get it right. At least people need not worry that advertisers would be Apple's true customers.
>If a developer gets booted then it’s probably because the developer didn’t do something that was in the best interest of the user.
This is not true with Apple. They often ban superior apps to force their users to use Apple's inferior apps.
Once you understand this, you will be able to understand that this isn't pro-user at all. This is giving Apple control, and making it harder to switch in the future.
This is not true with Apple. They often ban superior apps to force their users to use Apple's inferior apps.
Once you understand this, you will be able to understand that this isn't pro-user at all. This is giving Apple control, and making it harder to switch in the future.
Do you have any examples? I can’t think of any instance apple forced users to an inferior app, besides either an app blatantly violating user privacy (like tracking children) or a company they outright purchased, like Siri and what is now Shortcuts.
I’m not saying it’s definitely never happened, but I’d be love to read about some examples.
I’m not saying it’s definitely never happened, but I’d be love to read about some examples.
I’ve noticed the exact opposite. The Apple apps are surprisingly basic. If I want any real functionality, I’m forced to buy a third party app which results in Apple getting more money. They have direct motivation to avoid doing what you claim. How would they make money on their own free apps?
but this is a good next move for us consumers if you think about the overall position and dynamics of the industry relative to privacy. but as you point out, it doesn't mean we can let our guard down. we have to remain vigilant to imbalances of power that threaten our civil liberties (like the right to privacy).
once apple starts gaining traction with this feature, it's positioning will inevitably change, possibly for the worse, and then we back another borse who will keep apple in check.
unlike on game of thrones, our watch never ends.
once apple starts gaining traction with this feature, it's positioning will inevitably change, possibly for the worse, and then we back another borse who will keep apple in check.
unlike on game of thrones, our watch never ends.
[deleted]
The best solution imo is an open and federated email proxy standard, so that others can self-host an equivalent identity protection layer.
Just like facebook or google can block your account and prevent you from accessing all those logins you linked ever again.
So you better log in with your own email, but of the 3, I’d rather pick Apple as the lesser evil!
So you better log in with your own email, but of the 3, I’d rather pick Apple as the lesser evil!
Apple isn't just holding your authentication like Google login, but Apple is also exclusively holding your contact information. This means Apple has a sore authority to completely cut your access to your users: you have zero means to reconnect to them. This is different from other authentication methods where the provider does get an email address where they can use that communication medium to bypass the platform if needed.
I agree. This is a direct response to Spotify's recent moves
You could just ask the user for their “real” email post sign up. Send a test email to make sure it’s real.
I am sure users would simply love that. The point of sign in with Apple is that I don’t have to give out my real email. If you ask me for it anyway, I’m gone.
Users already do that with many sign up flows now. We are talking about a button press + an auto filled email field, doubt conversions would plummet.
What information would you gain from sending a test email? Wouldn't test emails sent to Apple's anonymous forwarding email also go through?
There's really no such thing as checking for a "real" email address, though lots of sites do blacklist known anonymous email domains like 10minutemail. But nothing can stop you from just signing up for a new Gmail.
There's really no such thing as checking for a "real" email address, though lots of sites do blacklist known anonymous email domains like 10minutemail. But nothing can stop you from just signing up for a new Gmail.
Senders to Apple's email proxy needs to be pre-registered first (and I highly suspect the generated addresses are scoped to each individual app's whitelist), so no, not everyone can send to those addresses.
The sender already is pre-registered. We're talking about users who have successfully Signed In With Apple ID.
After signing up you would request a non proxy email. Hence, the “real” email. You would then test that the user supplied email is legit.
But nothing is stopping the user from supplying a proxy email address in your textbox where you ask for a non-proxy email address. Sending a test email doesn't tell you whether the user-supplied email address is a proxy email address or a non-proxy email address, since your test email will go through in either case. That's the whole point of a proxy email address instead of a completely fake email address, is that emails sent to the proxy email address will still go through.
I imagine if you did you would be swiftly (hah) kicked out of the App Store
>It shows Apple actively seceding an opportunity for exchanging marketing data in favour of user privacy.
Apple isn't ceding anything here. They still have your email address, they have the record of your activity on the site you're accessing. They are withholding your email address from the site you're accessing, which is good for your privacy. But you make it sound like they've sacrificed something in doing that.
If google had done this, everybody would be up in arms about how google was further overreaching in their goal to gain complete control of the internet and are preventing poor little mom and pop websites from being able to meet their marketing goals.
Apple isn't ceding anything here. They still have your email address, they have the record of your activity on the site you're accessing. They are withholding your email address from the site you're accessing, which is good for your privacy. But you make it sound like they've sacrificed something in doing that.
If google had done this, everybody would be up in arms about how google was further overreaching in their goal to gain complete control of the internet and are preventing poor little mom and pop websites from being able to meet their marketing goals.
So I take it that you didn't watch the video or read the transcript where they state explicitly that they don't record or track that information.
Just because you believe the FB/G nonsense that the internet is only possible by gross violations of user privacy doesn't mean everyone else buys into it.
Just because you believe the FB/G nonsense that the internet is only possible by gross violations of user privacy doesn't mean everyone else buys into it.
They have to store the information, if for nothing else than to correctly forward emails to your real address.
They have a list of what websites i sign into with my Apple ID. Which is more information than they used to have. If you switch from signing in with your email address to signing in with your apple ID, that's one more entity that knows about that relationship than otherwise would.
I'm not trying to say this is a bad thing, I love what apple's doing here. I'm just trying to push back against any suggestions that apple is giving something up. They are collecting more data about their users now than they were previously, and positioning themselves as the gatekeeper of user identity. There's every indication that they're doing this for the right reasons, and it's good for users, but it still increases their control and their stored user data.
I'm not trying to say this is a bad thing, I love what apple's doing here. I'm just trying to push back against any suggestions that apple is giving something up. They are collecting more data about their users now than they were previously, and positioning themselves as the gatekeeper of user identity. There's every indication that they're doing this for the right reasons, and it's good for users, but it still increases their control and their stored user data.
To me this suggests then that the absolute amount of data collected isn’t necessarily a useful metric
I'm not quite sure what kind of metric you're referring to, but Apple is simply centralizing data collection of its ecosystems. The incentive is more comfortable service interaction and less entities receiving information about you.
On the other hand, Apple is tightening its control over its own ecosystems as every interaction has to go through them. Moreover, they're inhibiting anonymous usage of services as more and more things required direct or indirect verification of the user. This entices the market to normalize the demand for unique virtual identities.
On the other hand, Apple is tightening its control over its own ecosystems as every interaction has to go through them. Moreover, they're inhibiting anonymous usage of services as more and more things required direct or indirect verification of the user. This entices the market to normalize the demand for unique virtual identities.
All they have to record is alias->real in a giant table.
They don't need to record what app or service got the alias address, and they explicitly state that they do not record any details about interaction with your service, or any emails that go through the alias. It's an explicit statement in the linked talk.
They don't need to record what app or service got the alias address, and they explicitly state that they do not record any details about interaction with your service, or any emails that go through the alias. It's an explicit statement in the linked talk.
[deleted]
When someone starts forwarding illegal content via these accounts the feds will ensure that the recipients are disclosed.
What?
Which accounts doing what?
Businesses sending to a cloaked email?
Which accounts doing what?
Businesses sending to a cloaked email?
The mapping but not necessarily the user's activity.
Apple's business model is selling hardware, not selling advertising. It's not really a sacrifice for them. It's a "strategy credit" https://stratechery.com/2013/strategy-credit/
They don’t have a “record of your activity.” They only know that you have signed in with Apple on a site. They aren’t tracking your behavior or usage. The Apple JS doesn’t have to be on any page except the sign up/in.
And you don't have to use the Apple JS if you don't want to, since it's really just a library to download the appropriate button image and to do OIDC.
> If google had done this,
Google provides a similar thing as an OAuth/OpenID provider. (except they track all that stuff and share the email with the site/app).
Google provides a similar thing as an OAuth/OpenID provider. (except they track all that stuff and share the email with the site/app).
And you know, don't currently have a monopoly on iOS application distribution that it could use to strong arm developers on their platform to always make using it an option.
I'm a big fan of the feature, was quite thrilled to see it, but aren't they the provider of the redirect? So there is privacy to anyone but Apple: they'll know (if they wish to) that you signed up on Some Site with a burner email in a way they might not have if you used a regular burner email service.
Personally, I'm fine with Apple having that kind of info as I generally trust them and also that my main concern is the same with your frustration of my email ending up in yet another leak seemingly frequently.
Personally, I'm fine with Apple having that kind of info as I generally trust them and also that my main concern is the same with your frustration of my email ending up in yet another leak seemingly frequently.
> Personally, I'm fine with Apple having that kind of info as I generally trust them
...up until Apple decides to change their leadership, or their business model, or the mobile market implodes and they start looking for new revenue streams, or their relationship with the US government changes, or ...
I get that as a practical matter we are forced to trust somebody somewhere eventually, but at best we should be saying that "Apple doesn't seem motivated to abuse this information for now."
...up until Apple decides to change their leadership, or their business model, or the mobile market implodes and they start looking for new revenue streams, or their relationship with the US government changes, or ...
I get that as a practical matter we are forced to trust somebody somewhere eventually, but at best we should be saying that "Apple doesn't seem motivated to abuse this information for now."
This is a common perspective, and it is generally correct and worth considering.
However, for a company like Apple to change its stance would take a long time. Culture is sticky and, furthermore, they simply don't have the mass data collection and processing pipelines necessary for such an about face. There would be a fairly long period (my guess is years) during which consumers would be able to change providers.
However, for a company like Apple to change its stance would take a long time. Culture is sticky and, furthermore, they simply don't have the mass data collection and processing pipelines necessary for such an about face. There would be a fairly long period (my guess is years) during which consumers would be able to change providers.
Data sticks around for a lot longer than “a long time”.
Which is why Apple protects your data in a way they can't access it - in the event that they change into Google and Facebook in future they have no access to the current information.
I don't think it's valid to say Apple can't access your data. Maybe I'm understanding it wrong, but wouldn't that mean all your data would have to be encrypted with a private key that only you have? All I use to access my Apple data is a password, which I can reset at anytime.
Correct, all your data on apple's services are encrypted such that apple can't access them. The final fallback for account recovery is the "iCloud key vault" which is covered in documentation they published. Those are essentially HSMs gated by your account password and passcode, and a counter that triggers recovery key erasure.
I think the primary security white paper describes exactly how it works, but essentially there's a set of shared symmetric keys that are encrypted to public keys for each of your devices. Outside of the key vault path, the way a new device gets access to those keys is one of your other 2fa devices encrypt a decryption key to the new device when you approve it. The basic result is that there is no point in which the key material is transmitted unencrypted off a device.
I think the primary security white paper describes exactly how it works, but essentially there's a set of shared symmetric keys that are encrypted to public keys for each of your devices. Outside of the key vault path, the way a new device gets access to those keys is one of your other 2fa devices encrypt a decryption key to the new device when you approve it. The basic result is that there is no point in which the key material is transmitted unencrypted off a device.
[deleted]
Yeah, I do agree here - as much as I love to believe that this is a core belief of all the employees at apple - and in my experience this is a true statement - we have to remember that Apple is a company, and there is undeniably a huge marketing ability in privacy given that their business model doesn't depend on selling information.
But there's also a huge security benefit to apple not tracking this information: A hacker/angry-former-employee/creepy-current-employee can't access it either (eg. like the various stories we here about fb,uber,etc admins and employees spying on people).
But there's also a huge security benefit to apple not tracking this information: A hacker/angry-former-employee/creepy-current-employee can't access it either (eg. like the various stories we here about fb,uber,etc admins and employees spying on people).
To be perfectly cynical, I'm willing to temporarily give the benefit of the doubt to the company that's not currently selling my personal information to marketers, over the companies that are doing so flagrantly.
Exactly. With Apple it's "what if" their customers suddenly become advertisers, whereas Google and FB their customers already are advertisers.
Apple is in a unique position where they can sell hardware at profit making prices to a huge customer base. Even if we are at peak iPhone, current Apple users are not going anywhere (I tried to switch my wife to an Android phone once and it was a disaster hah). Privacy moves like Apple ID will only solidify the current user base. Best in class products like AirPods and the AppleWatch also lock users in - in a good way though.
I've noticed that since this announcement it is also pulling some stout Android users I know who have become disillusioned with how Google is slowly locking Android down. The constant bad press Google has received combined with the Apple privacy drum beat is starting to pay dividends for Apple.
Apple is in a unique position where they can sell hardware at profit making prices to a huge customer base. Even if we are at peak iPhone, current Apple users are not going anywhere (I tried to switch my wife to an Android phone once and it was a disaster hah). Privacy moves like Apple ID will only solidify the current user base. Best in class products like AirPods and the AppleWatch also lock users in - in a good way though.
I've noticed that since this announcement it is also pulling some stout Android users I know who have become disillusioned with how Google is slowly locking Android down. The constant bad press Google has received combined with the Apple privacy drum beat is starting to pay dividends for Apple.
While that's all true, again as a practical matter, a massive multi-decade-old denizen like Apple in some ways has more cultural and institutional inertia than even the US government. Especially now. Life is short; Apple's "for now" has been 43 years running.
The company has been around for over 40 years. Have they done anything to suggest that they’ll just randomly go rogue? Their brand is built on some amount of user trust, if they start violating that, there’d be significant market risk which makes no sense for them to do. They can and are already winning when it comes to privacy, violating that would be incredibly stupid from a business perspective. Privacy is one of their competitive advantages.
I feel more importantly they go to great lengths to create a brand image (because after all, everything else aside, they are a for profit company) and I imagine that reneging on the privacy angle would be considered to be damaging to the brand.
I feel of all the major tech companies, Apple is way more invested in retaining their brand image.
I feel of all the major tech companies, Apple is way more invested in retaining their brand image.
That's answered in the video: They don't record app usage, they don't record or monitor email that goes over the cloaked address.
The problem with burner address servers:
* They don't protect against fake addresses (which is why many services actually block them)
* They are much harder for regular users to use
* They're annoying to use, and fundamentally require providing your email address to yet another third party
Apple Sign-In clearly make the use of cloaking addresses much easier.
Again this still only applies to "social" logins, you're welcome to have your own login system.
The problem with burner address servers:
* They don't protect against fake addresses (which is why many services actually block them)
* They are much harder for regular users to use
* They're annoying to use, and fundamentally require providing your email address to yet another third party
Apple Sign-In clearly make the use of cloaking addresses much easier.
Again this still only applies to "social" logins, you're welcome to have your own login system.
Not knocking the system, quite thrilled by it personally: the other option is Google or Facebook at this point and if I got off OAuth and email with Google (leaning towards buying a personal domain and going with proton mail or similar, may wait until this built in burner option is available), I could probably rid myself of them (Facebook is more of a mental break I’d need to make, honestly). I’d love this.
I’ve personally tried personal burner email addresses for forums sign ups but the thing I found is that it is a maintenance (if that’s the correct word) nightmare. If you go with the ones that last for a brief period of time, you better guard the credentials because there’s no clicking forget password.
I’m hopeful of the feature, but even if it proves to not be that great, I’d still rather they be my identity provider over Facebook or Google so it’ll still feel like a net win.
I’ve personally tried personal burner email addresses for forums sign ups but the thing I found is that it is a maintenance (if that’s the correct word) nightmare. If you go with the ones that last for a brief period of time, you better guard the credentials because there’s no clicking forget password.
I’m hopeful of the feature, but even if it proves to not be that great, I’d still rather they be my identity provider over Facebook or Google so it’ll still feel like a net win.
Conceivably they could theoretically even spy on your emails with the companies you 've signed up with, including apple's competitors. It could even lead to potential legal issues for apple. At least plain email is considered distributed and does not rely on gatekeepers.
As opposed to Google and Facebook that convinced users to install apps that went around the App Store so they could record everything that you do with your phone or Facebook buying Onava (a VPN provider) with the express purpose of spying on you?
Apple could in the future become evil after 40+ years. The other two companies are actively evil.
Apple could in the future become evil after 40+ years. The other two companies are actively evil.
iirc they actually paid those users. And i don't think any company should be trusted. Apple was part of prism and is known to strong-arm their users to stay locked in their ecosystem. This sign in is a good step for security, but i don't think there can be such a thing as corporate-owned privacy.
“strong arm their users”?
Do jack booted thugs come to my door to force me not to buy an Android device?
Do you really think most users were aware that they were giving up their privacy? Even if you assume they do, Google broke a contract with Apple by using a developer certification.
Do jack booted thugs come to my door to force me not to buy an Android device?
Do you really think most users were aware that they were giving up their privacy? Even if you assume they do, Google broke a contract with Apple by using a developer certification.
Ur arguments are extreme. Apple does lock-in users and developers more than anyone else by enforcing rules and taking away/not implementing features, that's trivial for anyone who has an ios device to see. Agreed though, facebook and google also lock-in users by providing enough free services to users that they don't want to leave. That's a different level of coercion though.
You still haven’t given concrete examples....
Apple is the one that handed over iCloud keys to the Chinese government. Next to Apple, those two are lightweights at being evil.
Google was upfront about what their app did and paid their users for that data. It's just like a Nielsen box. I had installed it on an unused tablet myself, tapping the notification to check in weekly, and collecting enough Amazon credit to pay for Prime. https://www.google.com/landing/panelresearch/
Google was upfront about what their app did and paid their users for that data. It's just like a Nielsen box. I had installed it on an unused tablet myself, tapping the notification to check in weekly, and collecting enough Amazon credit to pay for Prime. https://www.google.com/landing/panelresearch/
Were they upfront with Apple about their use of the enterprise certificate?
Were they clear in telling people “we can record all of your internet activities including messages, banking information”, etc.?
Yes Apple stored data on Chinese servers, but your private keys never leave your device. Do you have any evidence to the contrary?
Were they clear in telling people “we can record all of your internet activities including messages, banking information”, etc.?
Yes Apple stored data on Chinese servers, but your private keys never leave your device. Do you have any evidence to the contrary?
> we can record all of your internet activities including messages, banking information
What the app was capable of collecting is different from what the app actually collected, which was clearly specified when signing up. The app is still available in the Play Store, and people still use it because nobody was surprised by what it collects. https://play.google.com/store/apps/details?id=com.google.and...
> Were they upfront with Apple about their use of the enterprise certificate?
Who cares? There's nothing evil about circumventing some arbitrary Apple policy to give users an app that they want.
> Yes Apple stored data on Chinese servers, but your private keys never leave your device.
Not your private keys but Apple's private keys, which gives the Chinese government unfettered access to everything Chinese users store in iCloud https://techcrunch.com/2018/07/17/apples-icloud-user-data-in.... Worse, the change was applied retroactively to data the users had stored in iCloud prior to the change. No other US tech company comes close in evilness.
What the app was capable of collecting is different from what the app actually collected, which was clearly specified when signing up. The app is still available in the Play Store, and people still use it because nobody was surprised by what it collects. https://play.google.com/store/apps/details?id=com.google.and...
> Were they upfront with Apple about their use of the enterprise certificate?
Who cares? There's nothing evil about circumventing some arbitrary Apple policy to give users an app that they want.
> Yes Apple stored data on Chinese servers, but your private keys never leave your device.
Not your private keys but Apple's private keys, which gives the Chinese government unfettered access to everything Chinese users store in iCloud https://techcrunch.com/2018/07/17/apples-icloud-user-data-in.... Worse, the change was applied retroactively to data the users had stored in iCloud prior to the change. No other US tech company comes close in evilness.
What the app was capable of collecting is different from what the app actually collected,
Yes they pinky promised not to collect all of your data. So will you email me your social security number if I promise not to use it?
Who cares? There's nothing evil about circumventing some arbitrary Apple policy to give users an app that they want.
Yes there is nothing wrong with breaching a contract....
Not your private keys but Apple's private keys, which gives the Chinese government unfettered access to everything Chinese users store in iCloud https://techcrunch.com/2018/07/17/apples-icloud-user-data-in.... Worse, the change was applied retroactively to data the users had stored in iCloud prior to the change. No other US tech company comes close in evilness.
That’s not how public/private key pairs work and the article said no such thing.
The app is still available in the Play Store, and people still use it because nobody was surprised by what it collects. https://play.google.com/store/apps/details?id=com.google.and....
So you’re absolutely sure that every single person who downloaded the app was aware of what it was able to collect and that everyone who downloads it was legally of age able to consent to data gathering?
Yes they pinky promised not to collect all of your data. So will you email me your social security number if I promise not to use it?
Who cares? There's nothing evil about circumventing some arbitrary Apple policy to give users an app that they want.
Yes there is nothing wrong with breaching a contract....
Not your private keys but Apple's private keys, which gives the Chinese government unfettered access to everything Chinese users store in iCloud https://techcrunch.com/2018/07/17/apples-icloud-user-data-in.... Worse, the change was applied retroactively to data the users had stored in iCloud prior to the change. No other US tech company comes close in evilness.
That’s not how public/private key pairs work and the article said no such thing.
The app is still available in the Play Store, and people still use it because nobody was surprised by what it collects. https://play.google.com/store/apps/details?id=com.google.and....
So you’re absolutely sure that every single person who downloaded the app was aware of what it was able to collect and that everyone who downloads it was legally of age able to consent to data gathering?
> Yes they pinky promised not to collect all of your data. So will you email me your social security number if I promise not to use it?
That's dense. If you use Apple email, they also collect your social security number if someone sends it to you, and they (and the Chinese government for Chinese users) have the ability to reset your password and gain access to any service is sign up for, despite pinky promises otherwise, and Apple's software has permission to read absolutely everything you do on your phone. In just the same way, what they have the ability to do exceeds what they tell their customers they do. What the app actually collected was specified, and there remains no evidence that they did anything more than they told the panelists.
> Yes there is nothing wrong with breaching a contract....
There is certainly nothing evil about giving users what they want in spite of the whims of a capricious (and actually evil) middleman.
> That’s not how public/private key pairs work and the article said no such thing.
Apple encrypted user's iCloud emails and iCloud data in a way that Apple still has access to for search. It is Apple's keys that matter in this case, not the user's keys for communicating with Apple.
The article said exactly such thing: "Before a switch announced in January, all encryption keys for Chinese users were stored in the U.S., which meant authorities needed to go through the U.S. legal system to request access to information. Now the situation is based on Chinese courts and a gatekeeper that’s owned by the government [emphasis added]."
That's dense. If you use Apple email, they also collect your social security number if someone sends it to you, and they (and the Chinese government for Chinese users) have the ability to reset your password and gain access to any service is sign up for, despite pinky promises otherwise, and Apple's software has permission to read absolutely everything you do on your phone. In just the same way, what they have the ability to do exceeds what they tell their customers they do. What the app actually collected was specified, and there remains no evidence that they did anything more than they told the panelists.
> Yes there is nothing wrong with breaching a contract....
There is certainly nothing evil about giving users what they want in spite of the whims of a capricious (and actually evil) middleman.
> That’s not how public/private key pairs work and the article said no such thing.
Apple encrypted user's iCloud emails and iCloud data in a way that Apple still has access to for search. It is Apple's keys that matter in this case, not the user's keys for communicating with Apple.
The article said exactly such thing: "Before a switch announced in January, all encryption keys for Chinese users were stored in the U.S., which meant authorities needed to go through the U.S. legal system to request access to information. Now the situation is based on Chinese courts and a gatekeeper that’s owned by the government [emphasis added]."
There is certainly nothing evil about giving users what they want in spite of the whims of a capricious (and actually evil) middleman.
So users want to install software that can intercept all of their communications? I’ve never heard someone say, “I would give up all of my privacy and install a network sniffer/key logger on my device of someone paid me*
Apple encrypted user's iCloud emails and iCloud data in a way that Apple still has access to for search. It is Apple's keys that matter in this case, not the user's keys for communicating with Apple.
That’s also not how email works. Email is not a secure communications and is never encrypted. Besides that, you don’t need to use an Apple provided email account.
The article said exactly such thing: "Before a switch announced in January, all encryption keys for Chinese users were stored in the U.S., which meant authorities needed to go through the U.S. legal system to request access to information. Now the situation is based on Chinese courts and a gatekeeper that’s owned by the government [emphasis added]."
That’s not how public/private key encryption works - despite what you read from techcrunch. The whole purpose of a public private key pair is that you (or your device) creates the key pair, you send the public key out for anyone to use. They then use the public key to encrypt a message and you keep your private key. Anyone can encrypt a message and only you can decrypt a message with your private key. Am I really explaining how public/private key encryption works on Hacker News?
So users want to install software that can intercept all of their communications? I’ve never heard someone say, “I would give up all of my privacy and install a network sniffer/key logger on my device of someone paid me*
Apple encrypted user's iCloud emails and iCloud data in a way that Apple still has access to for search. It is Apple's keys that matter in this case, not the user's keys for communicating with Apple.
That’s also not how email works. Email is not a secure communications and is never encrypted. Besides that, you don’t need to use an Apple provided email account.
The article said exactly such thing: "Before a switch announced in January, all encryption keys for Chinese users were stored in the U.S., which meant authorities needed to go through the U.S. legal system to request access to information. Now the situation is based on Chinese courts and a gatekeeper that’s owned by the government [emphasis added]."
That’s not how public/private key encryption works - despite what you read from techcrunch. The whole purpose of a public private key pair is that you (or your device) creates the key pair, you send the public key out for anyone to use. They then use the public key to encrypt a message and you keep your private key. Anyone can encrypt a message and only you can decrypt a message with your private key. Am I really explaining how public/private key encryption works on Hacker News?
> So users want to install software that can intercept all of their communications? I’ve never heard someone say, “I would give up all of my privacy and install a network sniffer/key logger on my device of someone paid me*
I just told you that I did exactly that. If you read the reviews of the app on the Google Play Store, you will find many other users confirming that they knowingly and happily made the same deal. The Nielsen box itself contains a microphone that can hear everything in the room, and people happily sign up for the payment.
> That’s also not how email works. [Blah blah blah.]
You missed the point. The point was that Apple has the exact same access as Google from the operating system. There is a difference between what the operating system allows an app to do and what it actually does, which you have repeatedly conflated.
> That’s not how public/private key encryption works.
Now you've confused end to end encryption with public key encryption. It's a bit ridiculous that I have to explain the difference to you, but here it goes. iMessages is end to end encrypted. ICloud services like mail, drive, and docs are not. By handing over the iCloud keys to China, Apple has given the Chinese government unfettered access to this information and, by extension, all services which can be accessed using those credentials.
Now that you understand the problem, do you understand how that is evil?
I just told you that I did exactly that. If you read the reviews of the app on the Google Play Store, you will find many other users confirming that they knowingly and happily made the same deal. The Nielsen box itself contains a microphone that can hear everything in the room, and people happily sign up for the payment.
> That’s also not how email works. [Blah blah blah.]
You missed the point. The point was that Apple has the exact same access as Google from the operating system. There is a difference between what the operating system allows an app to do and what it actually does, which you have repeatedly conflated.
> That’s not how public/private key encryption works.
Now you've confused end to end encryption with public key encryption. It's a bit ridiculous that I have to explain the difference to you, but here it goes. iMessages is end to end encrypted. ICloud services like mail, drive, and docs are not. By handing over the iCloud keys to China, Apple has given the Chinese government unfettered access to this information and, by extension, all services which can be accessed using those credentials.
Now that you understand the problem, do you understand how that is evil?
https://support.apple.com/en-us/HT202303
In some cases, your iCloud data may be stored using third-party partners’ servers—such as Amazon Web Services or Google Cloud Platform—but these partners don’t have the keys to decrypt your data stored on their servers.
If Apple is in fact lying,I’m sure a lot of government agencies would be glad to know.
In some cases, your iCloud data may be stored using third-party partners’ servers—such as Amazon Web Services or Google Cloud Platform—but these partners don’t have the keys to decrypt your data stored on their servers.
If Apple is in fact lying,I’m sure a lot of government agencies would be glad to know.
Facebook has had anonymous email redirects for years. Developers hated it, and circumvented it; it hands control over the communication channel from the developer to Facebook, and not to the user. The same will be true with Apple login.
There's obvious pros and cons to the developer owning that communication channel, or to a middleman owning that communication channel.
What Apple is doing here is using their total control of the application distribution channel on iOS to hold apps hostage to add an option to sell users on handing Apple control, or possibly reduce their growth by forcing them to remove the other login options.
It's mildly pro-consumer, but I think it's anywhere from mildly to very developer hostile. I'm not positive it will have a sustained effect, as developers may do what they did with Facebook and detect the proxied email and ask for the real one in its place.
There's obvious pros and cons to the developer owning that communication channel, or to a middleman owning that communication channel.
What Apple is doing here is using their total control of the application distribution channel on iOS to hold apps hostage to add an option to sell users on handing Apple control, or possibly reduce their growth by forcing them to remove the other login options.
It's mildly pro-consumer, but I think it's anywhere from mildly to very developer hostile. I'm not positive it will have a sustained effect, as developers may do what they did with Facebook and detect the proxied email and ask for the real one in its place.
> as developers may do what they did with Facebook and detect the proxied email and ask for the real one in its place.
And Apple may very well outlaw this practice.
And Apple may very well outlaw this practice.
Developers can in turn allow those user accounts to log in but only enable some features unless a real email is used.
Sure, Apple could add even more complexity to their review process (delaying approval), or give stiff penalties to developers for working around it.
Apple's recourse to remedy a situation where a developer does not want to allow Apple to forcefully insert itself as a middle-man is primarily punitive.
Thus, as stated, this is mildly to very developer hostile.
Sure, Apple could add even more complexity to their review process (delaying approval), or give stiff penalties to developers for working around it.
Apple's recourse to remedy a situation where a developer does not want to allow Apple to forcefully insert itself as a middle-man is primarily punitive.
Thus, as stated, this is mildly to very developer hostile.
Maybe I'm misunderstanding, but I believe Apple still absolutely has your real data as well as the ability to link it to all the anonymous throwaway addresses. They just chose not to give away that data for free to every app that is asking nicely.
I agree, this is some win for privacy against random rogue apps, but I don't see how Apple would secede anything.
Could you elaborate?
I agree, this is some win for privacy against random rogue apps, but I don't see how Apple would secede anything.
Could you elaborate?
If you watch the video or read the transcript they explicitly state that they do not record any of the information.
They obviously have a mapping of cloak address -> real address, but there's no requirement for them to have any record of which apps got which addresses.
They obviously have a mapping of cloak address -> real address, but there's no requirement for them to have any record of which apps got which addresses.
This is not hard to determine. E-mail messages have headers, and the app will send registration e-mail to the cloaked address. So all it takes is scanning the e-mail headers of stored mail.
The do mention that they allow users to disable individual aliases at any time. Which would indicate that they do at least mark that for the user.
>It shows Apple actively ceding an opportunity for exchanging marketing data in favour of user privacy.
This is not a new thing.
For example, when the iPad launched and digital versions of magazines began to be available, Apple allowed a subscriber to provide the magazine publishing house with their email address, but also required that they be allowed to refuse to provide it.
The new thing here is to give the user a way to shut off abusive spamming of an email address they have chosen to provide.
This is not a new thing.
For example, when the iPad launched and digital versions of magazines began to be available, Apple allowed a subscriber to provide the magazine publishing house with their email address, but also required that they be allowed to refuse to provide it.
The new thing here is to give the user a way to shut off abusive spamming of an email address they have chosen to provide.
Pretty useless, as steam and other websites have already blacklisted the idbloc.co domain as disposable, preventing user sign ups.
Is it unreasonable to believe that companies will block disposable Apple email addresses, just as they do, e.g., mailinator.com emails - often for authwalls intended purely for tracking users?
I think it's somewhat unreasonable to believe that, in the sense that Apple is pretty explicitly using their clout to make it much harder for companies to do this.
When a company blocks Mailinator, they're giving up a pretty small number of users -- those who know about Mailinator, use it, and refuse to sign up for a service that blocks it. Since Sign In with Apple is required for any iOS app that supports 3rd-party login, any company (with an app, which is mostly what this is all about anyway) that decides to block this new type of authentication will be forced to either give up all 3rd-party login options (costing them existing users who sign in this way and increasing the cost to acquire new ones), or give up their iOS app -- in either case, this probably means giving up a large number of users.
When a company blocks Mailinator, they're giving up a pretty small number of users -- those who know about Mailinator, use it, and refuse to sign up for a service that blocks it. Since Sign In with Apple is required for any iOS app that supports 3rd-party login, any company (with an app, which is mostly what this is all about anyway) that decides to block this new type of authentication will be forced to either give up all 3rd-party login options (costing them existing users who sign in this way and increasing the cost to acquire new ones), or give up their iOS app -- in either case, this probably means giving up a large number of users.
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.
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.
> 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.
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.
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.
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.
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).
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.
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.
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).
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).
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.)
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.
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.
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.
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.)
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.
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.
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.
I'm sure they will, but I'd take that as evidence that they do intend to sell it or spam me.
Which would be even more reason not to sign in at all. That said I'm sure that whenever the official guidelines come out there will be something explicit about not doing so (although of course that would only apply to apps)
Which would be even more reason not to sign in at all. That said I'm sure that whenever the official guidelines come out there will be something explicit about not doing so (although of course that would only apply to apps)
Yep, this is a strong signal from Apple.
Nitpick: seceding = leaving a group, ceding = giving up something.
Nitpick: seceding = leaving a group, ceding = giving up something.
Hilariously because I read this my brain got into the "wait, what was the other option? which one should I be using?" state and I had to double check myself.
Thank you very much :p
Thank you very much :p
fixed :)
I don't comment often on here, but just wanted to say thank you for this tool. I will be thoroughly checking out https://idbloc.co and making good use of it! It looks like it will be simpler than using disposable emails, and definitely better than creating random emails!
thanks for the kind words :-) I hope you get as much use out of the product as I already do!
[deleted]
A little trick I've found out is having a GSuite account added to the Gmail app and generally always using the "all inboxes" view, I've seen no ads with this setup.
I wish it allowed you to supply an email “formula” (for example “apple-sign-ups-${supplied-unique-id}@my-domain”). I understand this is a particularly “pro” request, but I’d still like it.
Again, from a customer angle I’m not 100% sold on this. I don’t want to miss an email because Apple servers are down, and if Apple decides to kill an app I don’t like, I also want the ability to disagree. Separately, I want something that wouldn’t be a pain to use on non-Apple devices.
Again, from a customer angle I’m not 100% sold on this. I don’t want to miss an email because Apple servers are down, and if Apple decides to kill an app I don’t like, I also want the ability to disagree. Separately, I want something that wouldn’t be a pain to use on non-Apple devices.
That "formula" allows the service to identify you the user because it's your domain (or group you into a subset of users if you share the domain with other people). Apple's relay service right now gives the application zero new information about you.
Don't most people already use a secondary email for signups to sites that they don't wish to hear from? I believe it's a solved problem, even for average users.
[deleted]
Why do we think Apple is not going to start reading this forwarded email and then using it to target ads? Sign-in with Apple makes them gmail... but without having to provide a web interface for reading email.
I do like the layer of indirection, but I have to imagine that someday the shareholders are going to ask "why not target ads like Google is doing" and they're not going to have a good answer.
I do like the layer of indirection, but I have to imagine that someday the shareholders are going to ask "why not target ads like Google is doing" and they're not going to have a good answer.
Because (if you watched the talk or read the transcript) they already explicitly stated that they will not?
They've also explicitly stated that they will not record any information about interaction with a service.
Based on Apple's general approach to data security, I suspect that there is no "company A got alias address Y" table. In principle all that they need is a table of alias->real. On the other hand maybe it would be useful to have such a table in the case a site gets compromised/starts selling information?
But they have stated explicitly in a public video that they will not record interactions or emails you send, so I'm sure it would be lawsuit city if the reneged on that.
They've also explicitly stated that they will not record any information about interaction with a service.
Based on Apple's general approach to data security, I suspect that there is no "company A got alias address Y" table. In principle all that they need is a table of alias->real. On the other hand maybe it would be useful to have such a table in the case a site gets compromised/starts selling information?
But they have stated explicitly in a public video that they will not record interactions or emails you send, so I'm sure it would be lawsuit city if the reneged on that.
The piece which requires state is the 'user consented to sharing data X with app Y' bit so that the user can change that consent in the future.
The email relay address could feasibly be just a reference to that state.
The email relay address could feasibly be just a reference to that state.
Because the moment they do that they lose the whole reputation they’ve spent years and years building as the ‘privacy focused tech company’. User trust goes out the window.
Wasn't Google the "don't be evil" tech company that all the "influencers" suggested their friends switch to over to when Altavista was being shady?
You guys trust companies wayyyy too much.
You guys trust companies wayyyy too much.
First of all, iCloud does have a web interface. Second of all they can’t read your email. Reviewing Apple’s numerous explanations of how the system works should make that clear. If paranoia gets the best of you, nobody is forcing you to implement sign in with Apple and you are free to not use sites that do.
It seems like it could be really good for users, but the fact that it's _required_ for any apps that use other 3rd-party sign-in options and that it's _required_ to be listed first among those options leaves a bad taste in my mouth.
I can't even imagine what would happen if Google did the same thing with Google Sign In and the Play store.
Disclaimer: I work for Google, not on anything related, and am speaking for myself (as always).
I can't even imagine what would happen if Google did the same thing with Google Sign In and the Play store.
Disclaimer: I work for Google, not on anything related, and am speaking for myself (as always).
It's not required to be first, it's "suggested" :-/
But lets look at it another way:
* I buy an app on the App Store, and then find out that I have to use FB or Google login.
* So to use the app I have purchased I am required to allow the app and/or Google or Facebook to further their abuse of my privacy.
Alternatively:
* An App is shown as "Free"
* I install it, and it require FB or Google sign in.
That isn't free. Again, signing up for abuse of my privacy is not free.
But lets look at it another way:
* I buy an app on the App Store, and then find out that I have to use FB or Google login.
* So to use the app I have purchased I am required to allow the app and/or Google or Facebook to further their abuse of my privacy.
Alternatively:
* An App is shown as "Free"
* I install it, and it require FB or Google sign in.
That isn't free. Again, signing up for abuse of my privacy is not free.
>> That isn't free. Again, signing up for abuse of my privacy is not free.
Surely the logical extension of this is that no app with ads should be marked as "free". Your attention is not free. Right?
Surely the logical extension of this is that no app with ads should be marked as "free". Your attention is not free. Right?
The Google Play Store will show "contains ads" under the install button. Same for "contains in app purchases". Makes it much easier to see which app is really free.
This is a good policy, and the Apple App Store has done the same thing for a while.
Not just the attention, but also the knowledge of where my attention is, shouldn't be free. Right?
[deleted]
However it is _required_ that you add Sign in With Apple. I'm all for privacy but I disagree with this move because apple said "You must add Apple Sign In" rather than "You must allow one form of anonymous login" which means they are forcing developers to use their tools.
Additionally, if the app only has FB or Google login and you don't use either, you can just not use the app
Additionally, if the app only has FB or Google login and you don't use either, you can just not use the app
Developers wouldn’t add it if it wasn’t required, full stop. They want access to your social media presence and personal information.
The problem here is very basic:
Why should an app be listed as free if using it requires sacrificing my privacy to use it? That's fundamentally not free.
If the app cost me money then I've purchased an app I cannot use.
This is very simple: they're saying that you cannot require Apple's (and by extension your) users to submit to abuse of their privacy in order to use your app.
Why should an app be listed as free if using it requires sacrificing my privacy to use it? That's fundamentally not free.
If the app cost me money then I've purchased an app I cannot use.
This is very simple: they're saying that you cannot require Apple's (and by extension your) users to submit to abuse of their privacy in order to use your app.
This "they're stealing my privacy!" outrage is tiresome. Someone built an app; it authenticates a certain way; if you don't like it, uninstall it. Both Google and Apple offer near immediate refunds. But really there's some due diligence required here - installing an app is not like visiting a web page, you should take a little care what you spend money on.
You're complaining that someone else is building apps in a way you don't like. That's their right; they aren't building them for you.
You're complaining that someone else is building apps in a way you don't like. That's their right; they aren't building them for you.
Why should Google know what apps I'm installing?
Why should Facebook?
Why should I have to get accounts for those services just to use your app?
Why should apple list apps that can't be used by users because of they require user's to create accounts with companies that are known to abuse user privacy?
The last point I think is the most reasonable: why should I, a user, be required to use some arbitrary third party just to use your app?
If you are solely using them for login support, and nothing else, then all you're doing is adding one more OAuth provider. What makes it so hard to require an Apple identity if you're already willing to accept google or facebook ones?
Why should Facebook?
Why should I have to get accounts for those services just to use your app?
Why should apple list apps that can't be used by users because of they require user's to create accounts with companies that are known to abuse user privacy?
The last point I think is the most reasonable: why should I, a user, be required to use some arbitrary third party just to use your app?
If you are solely using them for login support, and nothing else, then all you're doing is adding one more OAuth provider. What makes it so hard to require an Apple identity if you're already willing to accept google or facebook ones?
Besides that, I’m downloading an app from the Apple App Store. They already know which apps I’ve downloaded. They aren’t getting anymore information via “Sign in with Apple”.
Why should I build an app the way you want?
You are entitled to not use my app. I am entitled to not care.
You are entitled to not use my app. I am entitled to not care.
They are complaining that these app developers are misrepresenting the cost of the "free" app. What it really costs is access to data about you as a Google/FB user. Sure, build an app like that all you want, but don't lie about it.
In the common usage of the word they are totally free. If you want to redefine the word as it's used, let's start also considering your bandwidth isn't "free" and so these apps aren't free in that sense either. How about the electricity you paid to charge your phone? The calories you ingested that help you operate the phone?
The common and almost universally accepted understanding of "free" is "no exchange of money". Saying those who don't adopt an extreme viewpoint are lying is dishonest.
The common and almost universally accepted understanding of "free" is "no exchange of money". Saying those who don't adopt an extreme viewpoint are lying is dishonest.
The common usage of the word "free" is something like "without cost" (yours doesn't work and I actually couldn't find a definition that explicitly says "money"). Placing ads in an app has various costs, just not usually monetary. I don't think you need to redefine anything or go to this odd extreme you're trying to straw-man into the argument.
"There's no such thing as a free lunch" agrees with you - things described as free often have some cost, even if not monetary
Does Apple have a feature in their app store that allows developers to mark their apps as "Monetarily free but you have to sign in with Google"? If not, how exactly do you expect developers to comply with your demands when Apple provides no way to do so?
Your "they're stealing my emails!" outrage is hard to sympathize with.
If they are developing for iOS, they are already “forced to use Apple’s tools”.
Sure, but would you agree that open source tools and being able to choose the tools we want is better? We should have that same freedom when it comes to building authentication into our applications
It’s standard OATH. There are libraries for every language that I’m aware of that let you integrate with OATH providers. You don’t have to use Apple’s tools to do it. You could use “sign in with Apple” from any platform.
But what good would “open source tools” do overall if you still have to integrate with Apple’s services/APIs to do anything useful - the same is true with Android/Google Play Services.
But what good would “open source tools” do overall if you still have to integrate with Apple’s services/APIs to do anything useful - the same is true with Android/Google Play Services.
Reading and replying to this comment was not free then.....
Free in the colloquial sense means "no money required", otherwise nothing is free since there is always some cost, if not an opportunity cost. What are you going to do, complain that an app required bandwidth to download?
Free in the colloquial sense means "no money required", otherwise nothing is free since there is always some cost, if not an opportunity cost. What are you going to do, complain that an app required bandwidth to download?
"Suggested" by virtue of being part of the HIG. I and I'm sure many others have experienced app review rejections by virtue of HIG violations.
I can kind of see your point regarding paid apps, but for free apps, you aren't really losing anything, besides maybe a few seconds of your time. If you don't like the authentication options the app offers, you can just uninstall it, and for 99% of the apps in the app store there's multiple alternatives that will offer a different set of options.
Unless I don’t have a google or fb account, in which case having an app listed in the store that I can’t use is hostile - and I bet it would be even more problematic if they elevated the rank of apps that supported Apple sign in over those that didn’t, even if it did reflect the value proposition for the user
Why are you then purchasing installing the app if you think they invade your privacy. Just dont use those apps.
I think that's pretty well established that free means free with ads.
Ok, so add a "Sign In with Apple" icon to the App Store page.
I think that if "downloading apps users can't log into wastes their time" was the problem Apple was trying to solve, this would be a good (maybe better?) solution.
But the problem they're going after is bigger: how do you allow users to keep using their favorite apps (because most people aren't super privacy-conscious) while at the same time making sure those apps don't track users or sell their data? And, like it or not (and many people won't), I think forcing developers' hand is the only real way to make this happen.
But the problem they're going after is bigger: how do you allow users to keep using their favorite apps (because most people aren't super privacy-conscious) while at the same time making sure those apps don't track users or sell their data? And, like it or not (and many people won't), I think forcing developers' hand is the only real way to make this happen.
I know what you're saying but I'm okay with it. In this case Apple chose users over developers. iOS developers have to do a little more work (Apple has made it very easy from what I've seen of the framework) and have a little less freedom but users signing in to apps using 3rd party auth are guaranteed the privacy protections Apple is promising. They drew a line in the sand by making their solution mandatory but I think they had to to deliver what they're promising to users (which I think is great).
That privacy seems a bit overboard though. This is fine if a user can create his account directly inside the app. But it's not very clear how to support a workflow where you have an organization with multiple users authorized by an admin to use the app. How can the admin add a user to his organization, if he doesn't know in advance the user randomly generated email? I guess you could send an invitation code, and let the user enter that code after the apple sign in, to associate the account to the authorized user. This sounds more complex for the user than a workflow where the admin can directly authorize specific emails.
Does this apply to enterprise apps distributed outside the normal App Store? I bet it doesn’t.
Also I think you’re given the choice of using your real email address instead if the anonymizes one. At least that was my understanding.
Also I think you’re given the choice of using your real email address instead if the anonymizes one. At least that was my understanding.
App Store guidelines have no bearing on enterprise apps.
The randomly generated email is a user choice, they can also provide their real email. The randomly generated one would not work for things like slack sso etc.
Apple knows that for most people (unlike this website's audience), the privacy concern is not as important as using That Cool New App, and if this was just another option developers could, but didn't have to implement, many apps would choose not to -- and most people would still download them. The only way to make sure that most users' email/login/usage isn't being sold or used to track them is to force developers to offer Apple's auth option, and make it as easy to use as choosing to log in with Facebook or Google.
> I can't even imagine what would happen if Google did the same thing with Google Sign In and the Play store.
If Apple made its money by mining its users' data, there would be a big uproar about this announcement, too. But Apple made it very clear that they will not be doing that with this data, and is moving more and more towards establishing itself as the privacy-focused alternative to Google... So this is by and large (and obviously there are many people with reservations, whether about Apple forcing developers' hands, or about trusting a big company in general) being seen as more of a Good Thing.
> I can't even imagine what would happen if Google did the same thing with Google Sign In and the Play store.
If Apple made its money by mining its users' data, there would be a big uproar about this announcement, too. But Apple made it very clear that they will not be doing that with this data, and is moving more and more towards establishing itself as the privacy-focused alternative to Google... So this is by and large (and obviously there are many people with reservations, whether about Apple forcing developers' hands, or about trusting a big company in general) being seen as more of a Good Thing.
Google should just add a similar requirement in response. With this rule Apple is forcing their signup method to be taken up across all platforms (web, Android, iOS) because you can't only enable logging in with Apple on one platform.
If Google were to implement the same requirement, any cross platform app with Apple's login would also now have a Log in with Google button, making sure that Apple won't be getting any Oauth monopoly any time soon just to keep them in check.
If Google were to implement the same requirement, any cross platform app with Apple's login would also now have a Log in with Google button, making sure that Apple won't be getting any Oauth monopoly any time soon just to keep them in check.
I am very uneasy with this as well.
Apple has just leveraged their position as the iOS gatekeepers in order to obtain a huge marketshare of the SSO market.
Apple has just leveraged their position as the iOS gatekeepers in order to obtain a huge marketshare of the SSO market.
The SSO "market" is only a market if the SSO providers are monetizing your data at the expense of your privacy. Private authentication is not a "market" almost any of us needs or wants, but rather a right that we deserve.
Not sure why you've put "market" in quotes there. Okta is literally a SSOaaS that has a $14 billion market cap.
Does anyone use Okta outside of the Enterprise? No enterprise focused app is going to allow any random third party credentials. Okta is also not by any definition a “social network”.
It's also a "market" if you happen to run one of the largest payment networks in the world (Apple Pay) and if having users signed in with your service gives you the ability to let them easily provide payment information through you to the exclusion of your competitors (Amazon Pay, Google Pay, etc).
My understanding is that putting SIWA first is in their Human Interface Guidelines, which (nominally) are not mandatory. Some apps have been rejected for HIG violations, however, so maybe they'd enforce that (but I doubt it). Plenty of HIG-violating apps make it into the App Store, so they definitely don't enforce all HIG violations.
To me this is a fair rule and benefetial for the end users, it will give more options to them. It simply says "if there are competitors, you must include us".
I'm not an Apple user, but I would expect Apple to provide and guarantee that you can log in any app with your Apple login. Seems fair to me.
Also, I'm pretty confident that Google offering a privacy-oriented SSO on Google Play would be appreciated by everyone. Privacy on Android is such a joke : any app can freely read the accounts present on your phone, they don't even need you to sign in to identify you
I'm not an Apple user, but I would expect Apple to provide and guarantee that you can log in any app with your Apple login. Seems fair to me.
Also, I'm pretty confident that Google offering a privacy-oriented SSO on Google Play would be appreciated by everyone. Privacy on Android is such a joke : any app can freely read the accounts present on your phone, they don't even need you to sign in to identify you
Well, maybe if Google didn’t do stuff like trick users into installing privacy invasive apps by using developer certificates that were only suppose to be used for internal apps you might have a leg to stand on....
Can you point to anyone who was tricked? I signed up for that program myself. It was very clear what I had signed up for. I wasn't tricked into it any more than a Nielsen family is tricked into getting paid to use a Nielsen box.
You’re comparing a Neilson box with installing spyware on your phone that can intercept every piece of information you send across the internet?
Not to mention that Google knew that the certificates were meant for internal use only and agreed to the terms.
Not to mention that Google knew that the certificates were meant for internal use only and agreed to the terms.
> that can intercept every piece of information you send across the internet?
Just like a Nielsen box, the app collected clearly specified data, and users were paid for it.
Just like a Nielsen box, the app collected clearly specified data, and users were paid for it.
From the link you posted it wasn’t clear that it could intercept anything. Can a Neilson box intercept my emails? My account details and drain my account?
> From the link you posted it wasn’t clear that it could intercept anything.
That's Apple's fault if the permission screen didn't show that. What the app actually collected was different from what it had OS permission to collect and was clearly described to the user.
That's Apple's fault if the permission screen didn't show that. What the app actually collected was different from what it had OS permission to collect and was clearly described to the user.
The whole idea of a development certificate is that it is suppose to be used for internal use where a corporation can deploy an app to employees that can do all sort of weirdness.
And employees should also be informed, just like Android informs them.
I'm thrilled about implementing this on our app so we can make registration and login even more smooth without having to be in bed with Google and Facebook. Can't wait to implement it.
I'm even more thrilled to see, that according to the Okta article linked in another thread by simonw [1], Apple uses OAuth and OpenID Connect for this, and not some home-grown protocol.
Great news all-round.
[1] https://developer.okta.com/blog/2019/06/04/what-the-heck-is-...
I'm even more thrilled to see, that according to the Okta article linked in another thread by simonw [1], Apple uses OAuth and OpenID Connect for this, and not some home-grown protocol.
Great news all-round.
[1] https://developer.okta.com/blog/2019/06/04/what-the-heck-is-...
Hoping for a cordova plugin sooner rather than later, for us Hybrid App developers.
techntoke(5)
Even better, this may eliminate passwords. This is only available on iOS and requires FaceID / T2 chip.
Aaron Parecki, the author of the "OAuth 2.0 Simplified" book, wrote a blog post on the misunderstandings around Sign in with Apple: https://aaronparecki.com/2019/06/04/23/sign-in-with-apple-mi...
That article seems worthy of discussion on its own. I submitted it (expecting to find an existing discussion) but it turns out it hadn't been submitted yet.
https://news.ycombinator.com/item?id=20128029
https://news.ycombinator.com/item?id=20128029
CAUTION: There's a redirect loop bug when you open this link in Safari. Seems to be an error in their JS. The only option is to close the tab. Works fine in Firefox and Chrome.
Just so people can watch the detailed developer introduction.
Specifically:
It verifies the "realness" of the account, so everyone claiming that they need user's real email address for "fraud detection" can't argue that nonsense anymore. We all know that argument was just a cover for "we want to be able to spam our users with impunity", but this specifically addresses that argument just to be sure.
Specifically:
It verifies the "realness" of the account, so everyone claiming that they need user's real email address for "fraud detection" can't argue that nonsense anymore. We all know that argument was just a cover for "we want to be able to spam our users with impunity", but this specifically addresses that argument just to be sure.
> ...can't argue that nonsense anymore. We all know that argument was just a cover for "we want to be able to spam our users with impunity"
Run a site that allows/displays user submitted content and you'll likely change your mind about that being a cover or bogus argument.
Run a site that allows/displays user submitted content and you'll likely change your mind about that being a cover or bogus argument.
But requiring an email hardly solves that problem.
And very few apps (at least of what I use) that have 3rd party auth have features where user content is displayed to others.
And very few apps (at least of what I use) that have 3rd party auth have features where user content is displayed to others.
It does significantly reduce the problem.
How? Is it because you have "proof" that it's a real user?
If you watch the presentation or read the transcript, you'll hear that they already do a bunch of fraud prevention. I'm going to go out on a limb and say Apple is doing much more anti-fraud/fake account work that most others are able to.
If you watch the presentation or read the transcript, you'll hear that they already do a bunch of fraud prevention. I'm going to go out on a limb and say Apple is doing much more anti-fraud/fake account work that most others are able to.
I’d imagine there’s a lot of criteria being used. Maybe something like the age of the account, how often it’s used, of it was created from an often used IP address. Whatever it is, it’s probably not in Apple’s interest to disclose it.
You can still ban the underlying iOS account, you just don't get an email address to spam/sell.
Sorry what exactly does having a cloaking address do that makes this a problem?
You get an email address you can contact them through.
You get an email address you can contact them through.
Then say that: "we want your email in case there are issues with your content".
But that doesn’t explain why they need your actual email.
The only reason they want a user’s real address is because they want an address the user cant stop them from spamming.
There is literally no other reason.
The only reason they want a user’s real address is because they want an address the user cant stop them from spamming.
There is literally no other reason.
> The only reason they want a user’s real address is because they want an address the user cant stop them from spamming.
Unsubscribe and report to spam doesn't exist in our world, anymore?
Unsubscribe and report to spam doesn't exist in our world, anymore?
Unsubscribe relies on the sender honouring your choice.
Deleting the anonymous redirect address they’ve been given requires no such cooperation.
Deleting the anonymous redirect address they’ve been given requires no such cooperation.
[deleted]
Just because an account is real doesn't mean it isn't spam. Most of the forum registration spam is done by real people.
Also, I think most users anyway use a secondary or "throwaway" mail account to sign up to various websites that are not critical to them. This problem is largely already solved.
Also, I think most users anyway use a secondary or "throwaway" mail account to sign up to various websites that are not critical to them. This problem is largely already solved.
But what does getting a real email address do in that case?
If you watch the presentation or read the transcript, they explicitly say that they're doing fraud/spam account prevention.
Do you really think you're doing more fraud/spam detection and prevention work than apple?
If you watch the presentation or read the transcript, they explicitly say that they're doing fraud/spam account prevention.
Do you really think you're doing more fraud/spam detection and prevention work than apple?
The email is not the relevant part. Apple sign in requires the purchase of an apple device so it's almost guaranteed to not be a bot. However apple cant know (and shouldn't know btw) if the iphone user uses it to sign up and spam various websites.
Apple already has a lot of anti-spam/fraud accounts because they need to prevent iMessage spam (is your forum going to be subject to the same spam account pressure of a system like iMessage or iCloud?)
But also any argument that the makes spam harder to block also applies to Facebook or google logins - I can’t imagine spammers are using real email addresses with those services.
The only people this changes the experience for are actual users. Spammers already have a huge array of options to get “real email addresses”.
But also any argument that the makes spam harder to block also applies to Facebook or google logins - I can’t imagine spammers are using real email addresses with those services.
The only people this changes the experience for are actual users. Spammers already have a huge array of options to get “real email addresses”.
ugh, this totally vendor lock-in .
1. If my app is both in IOS and Android, and maybe Windows, would this work across platforms? The answer looks like no... Apple's definition of "multiplatform" means iOS, TVOS and WatchOS, and some javascript for the web. (given Apple's poor track record for anything web-based, good luck with that). If you want to port your app to Android or Native Windows, good luck with that. Your users are locked in.
2. If I have an app that is a competitor to Facebook, and FB decides to cut me off, I can use the existing emails so the user are not locked out the app (i.e. they will be sent an email with a link to create a password and keep their account).
This looks impossible with the apple sign in. Basically if Apple decides to cut you off, your user's accounts are lost.
No matter what some folks believe that 'everything social is evil', some applications providers provide the social log-in just because the user that prefer using them over entering the same information over and over. Instead of entering email, authorizing/verifying it, and having a profile picture, a social log-in provides those for you.
As I am building an app that has the social login (Google and Facebook) as well as simple email sign in, this feels like an additional burden that I'd prefer not to (for the two main reasons above).
Feels very anti-competitive.... Apple should provide the log-in as an option, and compete with its own merits, but not force app makers to use it.
Also, I think apple is being totally evil now: By forcing companies like Spotify and other competitors to use their log in, they are creating an very intrusive/invasive way to monitor their competitors.
Eg. Netflix and Spotify and a myriad of other Apple's direct competitor are forced to be locked in the Apple's vendor sign in trap.
1. If my app is both in IOS and Android, and maybe Windows, would this work across platforms? The answer looks like no... Apple's definition of "multiplatform" means iOS, TVOS and WatchOS, and some javascript for the web. (given Apple's poor track record for anything web-based, good luck with that). If you want to port your app to Android or Native Windows, good luck with that. Your users are locked in.
2. If I have an app that is a competitor to Facebook, and FB decides to cut me off, I can use the existing emails so the user are not locked out the app (i.e. they will be sent an email with a link to create a password and keep their account).
This looks impossible with the apple sign in. Basically if Apple decides to cut you off, your user's accounts are lost.
No matter what some folks believe that 'everything social is evil', some applications providers provide the social log-in just because the user that prefer using them over entering the same information over and over. Instead of entering email, authorizing/verifying it, and having a profile picture, a social log-in provides those for you.
As I am building an app that has the social login (Google and Facebook) as well as simple email sign in, this feels like an additional burden that I'd prefer not to (for the two main reasons above).
Feels very anti-competitive.... Apple should provide the log-in as an option, and compete with its own merits, but not force app makers to use it.
Also, I think apple is being totally evil now: By forcing companies like Spotify and other competitors to use their log in, they are creating an very intrusive/invasive way to monitor their competitors.
Eg. Netflix and Spotify and a myriad of other Apple's direct competitor are forced to be locked in the Apple's vendor sign in trap.
As for 1, just use a webview? That's how the iOS SDKs for Facebook/Twitter worked for the longest time.
edit: Also it looks like it's just OAuth and you could implement it directly
edit: Also it looks like it's just OAuth and you could implement it directly
They actually stated that it supports iOS, Android and Web.
You can use the REST API if you don’t want to use the JavaScript SDK.
This seems to be a case of “anyone but Apple” logic by naysayers.
If Mozilla or name your blessed organization of choice came up with this system, most of them would be fine with it.
But because it’s Apple, there’s all this consternation about it.
Apple’s huge advantage: their revenue comes from devices and services, not advertising.
It would be different if this was a one-off but they’ve been implementing privacy features for several years…
If Mozilla or name your blessed organization of choice came up with this system, most of them would be fine with it.
But because it’s Apple, there’s all this consternation about it.
Apple’s huge advantage: their revenue comes from devices and services, not advertising.
It would be different if this was a one-off but they’ve been implementing privacy features for several years…
Not because it’s Apple, but rather because Apple are exploiting their position as iOS App Store gatekeepers to require developers to add Sign In With Apple. Mozilla don’t have this position / power.
I think people would have the same issue if Google required ‘Sign In With Google’ in play store apps that have Facebook login, and returned throwaway / proxies email addresses.
I think people would have the same issue if Google required ‘Sign In With Google’ in play store apps that have Facebook login, and returned throwaway / proxies email addresses.
I haven’t seen anyone upset over the feature set. The only complaints I’ve seen are those uneasy with Apple’s forceful hand. They are both the gatekeeper to the store and now gatekeeper to the login. This is happening at the same time they are being investigated for anti-trust.
> they’ve been implementing privacy features for several years…
Yet this one is not a pro-privacy feature, it's an "apple owns your privacy" feature. Apple will control your account access and even be able to read your emails. Sure you trust them, but in the future they 'll use it to push their own ecosystem (like apple payments) to developers. We 've had single sign-ons for too many years to know that any ecosystem lock-in is a bad thing. As bad as email sounds, it's still the free-est , most decentralized login provider available.
> If Mozilla or name your blessed organization of choice came up with this system, most of them would be fine with it.
Mozilla came up with Persona, which would be great if they pushed it further and perhapps provided an anonymous email relayer like this instead of being based on existing email providers. With Mozilla the big advantage is that your account is not tied to any other service, real name, credit card etc. I wouldn't use Apple Login to sign up to a porn site, despite the high standards of apple's security.
Yet this one is not a pro-privacy feature, it's an "apple owns your privacy" feature. Apple will control your account access and even be able to read your emails. Sure you trust them, but in the future they 'll use it to push their own ecosystem (like apple payments) to developers. We 've had single sign-ons for too many years to know that any ecosystem lock-in is a bad thing. As bad as email sounds, it's still the free-est , most decentralized login provider available.
> If Mozilla or name your blessed organization of choice came up with this system, most of them would be fine with it.
Mozilla came up with Persona, which would be great if they pushed it further and perhapps provided an anonymous email relayer like this instead of being based on existing email providers. With Mozilla the big advantage is that your account is not tied to any other service, real name, credit card etc. I wouldn't use Apple Login to sign up to a porn site, despite the high standards of apple's security.
Does anyone else dislike when websites offer a lot of 3rd party sign-in options? Maybe it's just me, but when there's more than one option, I often forget which one I used and it ends up being a process of checking all of them. The service I run only offers email and Facebook, and now I'll have to either remove Facebook, or add both Google and Apple (I can't just add Apple because it'll look annoying for our Android users if there's Apple and no Google).
Also, when OAUTH uses the real email address, it makes it simple to switch between the different login options without much friction, which won't work anymore for people using Apple ID. Maybe I'll just have to make it a habit to use only Apple when available, and plain email otherwise.
Also, when OAUTH uses the real email address, it makes it simple to switch between the different login options without much friction, which won't work anymore for people using Apple ID. Maybe I'll just have to make it a habit to use only Apple when available, and plain email otherwise.
I had this problem two or three times and that - and the fact that some of those got removed after a couple of years like mozillas persona and OpenID - made me go back and always use email, which has the added value that I don't expose the usage of that website to a 3rd party.
> can't just add Apple because it'll look annoying for our Android users if there's Apple and no Google
just like it looks annoying for your Android users that there's Facebook but no Google?
just like it looks annoying for your Android users that there's Facebook but no Google?
Facebook is not related to Android or iOS. But Google is related to Android and Apple is related to iOS.
Right, my point is that it's already weird to have Facebook but not Google on Android.
I agree it's a little weird, and we do get requests for it once a month or so. When we decided on just adding a single 3rd party option, FB seemed like the most platform agnostic. We'll probably be adding all of them now though.
Yahoo has had disposable email for a long time. You can create upto 500 disposable email addresses (by going to Settings->More Settings->Mailboxes).
Also, you can give this email address a base name that is different from your normal email address so if your normal address is [email protected], you can have "abc" as the base name of your disposable addresses, and your disposable emails will have addresses of the form abc-<your-chosen-disposable-id>@yahoo.com ([email protected] for example).
So unlike gmail's "plus" email addresses, it's not possible to decipher your real email id from the disposable one. Very handy.
Combine this with Firefox's ability to remember userid/passwords and sync across devices, and you have a powerful privacy toolset that is not a pain to use and is not controlled by any single entity.
Also, you can give this email address a base name that is different from your normal email address so if your normal address is [email protected], you can have "abc" as the base name of your disposable addresses, and your disposable emails will have addresses of the form abc-<your-chosen-disposable-id>@yahoo.com ([email protected] for example).
So unlike gmail's "plus" email addresses, it's not possible to decipher your real email id from the disposable one. Very handy.
Combine this with Firefox's ability to remember userid/passwords and sync across devices, and you have a powerful privacy toolset that is not a pain to use and is not controlled by any single entity.
I create unique email addresses per service. The pain is in autocompleting email inputs in signup forms. It will suggest a bunch of email addresses that I used on other services and not a new one to use for this service.
I'd love if someone could explain if the 'fake email' address that the developer gets from Apple will be the same across all apps from the same developer? Or is there some way for the developer to link a login on one app to the same user on another app from the same developer?
I'm all in favour of increasing user privacy and the general direction that Apple is moving but we've got multiple Apps which allow users to log in via Game Centre, Facebook or Twitch to the same account. This allows them to access their friends, messages and support tickets from any of our Apps. We're able to do this because each of those providers gives us a unique identifier for each user (we only store that id and don't ever store the email address from them). I fear that Apple are going to make this impossible for us to do this going forward which would be a negative experience for our users.
I'm all in favour of increasing user privacy and the general direction that Apple is moving but we've got multiple Apps which allow users to log in via Game Centre, Facebook or Twitch to the same account. This allows them to access their friends, messages and support tickets from any of our Apps. We're able to do this because each of those providers gives us a unique identifier for each user (we only store that id and don't ever store the email address from them). I fear that Apple are going to make this impossible for us to do this going forward which would be a negative experience for our users.
In the presentation they talk about how the authorisation returns a stable, team-scoped (that means same developer) id.
Previous discussion: https://news.ycombinator.com/item?id=20086045
The previous discussion was the announcement not the developer presentation that actually goes over the full details.
That conversation has a lot of people arguing about things that this video addresses.
That conversation has a lot of people arguing about things that this video addresses.
Has anyone seen a live online demo of "Sign in with Apple" anywhere on the internet?
I've seen a few tutorials - https://developer.okta.com/blog/2019/06/04/what-the-heck-is-... is particularly good - but no one seems to have deployed a button I can click anywhere yet.
I've seen a few tutorials - https://developer.okta.com/blog/2019/06/04/what-the-heck-is-... is particularly good - but no one seems to have deployed a button I can click anywhere yet.
If you’re using iOS 13,
https://appleid.apple.com/ now use Sign in with Apple, although obviously there’s no granting flow (where you can choose whether to give them the real email).
JavaScript example https://developer.apple.com/documentation/signinwithapplejs/...
Can you do oauth? I'm not gonna add a random script hosted by apple to my page.
Yes you can - here's some example code that uses an OAuth redirect rather than Apple's JavaScript: https://github.com/aaronpk/sign-in-with-apple-example
This is amazing. Am I right to conclude that this lets us use it in apps older than iOS 13 as well as it’s based off of oauth redirect?
Unfortunately, Apple Sign In for the Web - insists on using HTTP POST's for the redirect_uri. This is a snippet from their official JavaScript library.
const t = { baseURI: "https://appleid.apple.com", path: "/auth/authorize", originURI: "", env: "prod", uxMode: "redirect", responseType: "code id_token", responseMode: "form_post", client: { clientId: "", scope: "", redirectURI: "", state: "" } };
Notice the responseMode which is set to form_post which I believe is the only supported mode.
This means you can no longer do things like localhost redirect_uri's for testing, or even use Apple Sign In on an internal web-app. Also, goes against OAuth2. :(
I submitted this feedback. Hopefully, someone takes a look.
const t = { baseURI: "https://appleid.apple.com", path: "/auth/authorize", originURI: "", env: "prod", uxMode: "redirect", responseType: "code id_token", responseMode: "form_post", client: { clientId: "", scope: "", redirectURI: "", state: "" } };
Notice the responseMode which is set to form_post which I believe is the only supported mode.
This means you can no longer do things like localhost redirect_uri's for testing, or even use Apple Sign In on an internal web-app. Also, goes against OAuth2. :(
I submitted this feedback. Hopefully, someone takes a look.
> This means you can no longer do things like localhost redirect_uri's for testing, or even use Apple Sign In on an internal web-app.
Seems this might provide some security benefit, e.g. no credentials showing up in web server access logs. Either way, are you sure the final POST isn't made by the client? If so, the client would resolve the address. On their JS configuration page[1], I don't see any obvious evidence that Apple will make the post. They show this line:
`AppleID.auth.signIn();`
P.S. Aghghgh the mixed camelCase and under_score makes me cringe.
Seems this might provide some security benefit, e.g. no credentials showing up in web server access logs. Either way, are you sure the final POST isn't made by the client? If so, the client would resolve the address. On their JS configuration page[1], I don't see any obvious evidence that Apple will make the post. They show this line:
`AppleID.auth.signIn();`
P.S. Aghghgh the mixed camelCase and under_score makes me cringe.
[1] https://developer.apple.com/documentation/signinwithapplejs/configuring_your_webpage_for_sign_in_with_appleThey already don’t show up if you use fragment URIs. The real issue I have is that the OAuth2 spec covers all this and we don’t have to rehash this every time a new IDP creates an Auth system.
No. The final post is not made by the client and a server has to handle the request. Webapps cannot handle POST requests from an Authorization server.
No. The final post is not made by the client and a server has to handle the request. Webapps cannot handle POST requests from an Authorization server.
Will "Sign in with Apple" be available on non Apple devices? If not how will cross device syncing etc work?
In the presentation they mentioned that it's available for JavaScript, and said that's the way to do Sign in with Apple on web and Android.
Seems like it would be less useful on a non-Apple device though. I don't know about you but my Apple login is a nightmarishly long password and 2FA. Authenticating through FaceID or TouchID is what makes it usable.
What about using a password manager?
Good point. I have an irrational paranoia putting really vital stuff in those, but it would work.
This type of issue is why I use LastPass, and not Apples Password manager. I'm very weary of how this would work on a non-mac device and I definitely use multiple non-mac devices regularly through a given day or week.
Microsoft has a better decentralized approach https://www.microsoft.com/en-us/security/technology/own-your.... Things have come full circle.
My team has been wondering: We allow third-party login via one OAuth provider (Esri) in addition to "local" accounts. Users who log in with Esri do so to access content in their Esri account, not as a matter of convenience.
Apple's guidelines stipulate that it will be "required as an option for users in apps that support third-party sign-in".
In contrast with social logins, you cannot create an account with our app via the Esri login, and your Esri account must be set up first in the back-end to even use it at all.
We can't think of a way to feasibly support this per their requirements, unless Esri allows it via their OAuth flow as well (they do support Facebook/Google today).
Apple's guidelines stipulate that it will be "required as an option for users in apps that support third-party sign-in".
In contrast with social logins, you cannot create an account with our app via the Esri login, and your Esri account must be set up first in the back-end to even use it at all.
We can't think of a way to feasibly support this per their requirements, unless Esri allows it via their OAuth flow as well (they do support Facebook/Google today).
> Users who log in with Esri do so to access content in their Esri account, not as a matter of convenience.
So this is not a third-party sign in. This is access to third party data which requires signing in with them.
So this is not a third-party sign in. This is access to third party data which requires signing in with them.
> It will be required as an option for users in apps that support third-party sign-in when it is commercially available later this year.
This is absolutely ridiculous. What about games that allow you to sign in with Facebook specifically for the purpose of tracking your progress relative to your friends? Sign in with Apple has precisely zero purpose in this scenario.
I can sort of understand making this a requirement if sign in is required to use the app at all. I really hope that exemptions will be allowed where Sign in with Apple is 100% pointless.
This is absolutely ridiculous. What about games that allow you to sign in with Facebook specifically for the purpose of tracking your progress relative to your friends? Sign in with Apple has precisely zero purpose in this scenario.
I can sort of understand making this a requirement if sign in is required to use the app at all. I really hope that exemptions will be allowed where Sign in with Apple is 100% pointless.
If sign in with Facebook is optional and for providing specific features, then its not really using Facebook as an account management system - it’s more connecting to Facebook - so I think you’ll be fine.
The updated guidelines say nothing about the login being required vs. optional.
" * You may only use the Sign In with Apple software if you are enrolled in the Apple Developer Program."
This taken directly from their JS at https://appleid.cdn-apple.com/appleauth/static/jsapi/appleid...
This seems to imply that using this for your personal site, for instance, requires the $99 "developer tax"...
This taken directly from their JS at https://appleid.cdn-apple.com/appleauth/static/jsapi/appleid...
This seems to imply that using this for your personal site, for instance, requires the $99 "developer tax"...
Will Apple be able to read all the emails that are sent to/via the forwarding address?
Yes, unless services are sending encrypted e-mails to their users via keys that are established out-of-band.
Technically they could. According to the docs, they destroy the email after delivery.
How will the mandatory implementation of this affect apps that rely on a third party as the data storage system? For example https://moo.do stores everything in Google Drive, if they have to implement Sign in with Apple the app won't function
My interpretation is that the rule applies to using a third party service to create the identity you use for your own service, vs. actually logging into the service.
e.g.
* You have a forum that needs a per user identity, but you recognize that managing account login information securely is challenging, and the most cost effective solution is to offload on a separate authentication service (Google, Facebook, etc)
vs
* You're a 3rd party mail client for gmail, and you app is actually signing into the third party service itself.
Of course I'm sure all of this will be clearly and unambiguously explained by release :-/
e.g.
* You have a forum that needs a per user identity, but you recognize that managing account login information securely is challenging, and the most cost effective solution is to offload on a separate authentication service (Google, Facebook, etc)
vs
* You're a 3rd party mail client for gmail, and you app is actually signing into the third party service itself.
Of course I'm sure all of this will be clearly and unambiguously explained by release :-/
What I REALLY want is simpler 2 factor auth.
Love iMessage autofill on text inputs from text message codes
But... Authy (arguably more secure) is super annoying to open, click, copy, re-window over, click, and then finally paste.
Would be cool if this somehow cleaned up the whole process.
Love iMessage autofill on text inputs from text message codes
But... Authy (arguably more secure) is super annoying to open, click, copy, re-window over, click, and then finally paste.
Would be cool if this somehow cleaned up the whole process.
Check out 1Password for 2FA management. It's extremely well done. When it auto-fills your user/password, it also puts your 2FA code into your clipboard so you can just paste it in on the next page.
Alternatively, and if the form supports it, you can use the share sheet on iOS to get 2FA auto fill from 1Password.
Alternatively, and if the form supports it, you can use the share sheet on iOS to get 2FA auto fill from 1Password.
>Authy (arguably more secure)
What's the argument ?
>Would be cool if this somehow cleaned up the whole process.
Everyone, just leave 2FA alone. No sms. No custom garbage that sends a push from a cloud and uses a blob on the device. Use TOTP. It's simple and easy. If you want fancier phishing protection, optionally add the newer fido2 or whatever the newer standards end up being. Just no custom garbage.
What's the argument ?
>Would be cool if this somehow cleaned up the whole process.
Everyone, just leave 2FA alone. No sms. No custom garbage that sends a push from a cloud and uses a blob on the device. Use TOTP. It's simple and easy. If you want fancier phishing protection, optionally add the newer fido2 or whatever the newer standards end up being. Just no custom garbage.
For regular users TOTP isn't simple:
* you have to install an app, but you can't tell which app you're meant to use
* you have to configure the app with whatever your signin service is
* If you ever delete the app (something that is generally not harmful) you lose the ability to sign in, and reinstalling frequently does not bring back your old authorizations.
But yeah, SMS 2fa is garbage from a security stand point (and will remain so until carriers can be held liable for costs from transferring your number without your authorization), but it is usable and is leaps and bounds better than nothing at all, which is what users will do if you make 2fa hard to set up.
* you have to install an app, but you can't tell which app you're meant to use
* you have to configure the app with whatever your signin service is
* If you ever delete the app (something that is generally not harmful) you lose the ability to sign in, and reinstalling frequently does not bring back your old authorizations.
But yeah, SMS 2fa is garbage from a security stand point (and will remain so until carriers can be held liable for costs from transferring your number without your authorization), but it is usable and is leaps and bounds better than nothing at all, which is what users will do if you make 2fa hard to set up.
Little beyond me on why It’s considered more secure. Just what I read a while ago.
I just want cleaner integration for the user. Don’t care about messing with it
I just want cleaner integration for the user. Don’t care about messing with it
Yubikeys are great, but perhaps out of scope of this discussion.
It's quite amazing that Apple is doing this at the exact time the government is investigating them for anti-trust violations.
Essentially what Apple is doing is creating a new gate as they've done before with forcing developers to use their payment processing system for digital goods that costs 30% of the total fee.
Facebook Login already supports users blocking sending sites their email, as I disable that all the time. They even have published guidelines with what a site should do when they think they need that piece of information. So I'm not sold on the privacy story here. Go on, give it a try the next time you are signing in for the first time. You can even go back and remove your email permission from the security page in FB.
Apple did do one thing though, they created a bigger market for junk email services and made it easy to send those to services you expect to get notifications from. Still, this is something Apple could have built into iOS just like they did with password managers. It's not a feature that needed to be forced on anyone for any reason. As a user of the device, I can just pick, get me a junk email and presto, it's done.
I get it though, I can imagine the scenario last year right after news broke with Cambridge Analytica. This was enabled from a shady 3rd party developer using FB single sign-on and execs at Apple were pissed. They probably hastily demanded someone at Apple create something to circumvent FB's position. However, this doesn't just affect FB, it affects Twitter, Google, GitHub, Microsoft as well.
Yes Apple has good-will in this community, and its to their competitive advantage that they continue to build out more privacy focused features. However, I still do not appreciate that Apple gets the final say. This should have been a bigger conversation across the entire industry. Why didn't Apple come out and say, we are investing in the Oauth organization and then published papers on best practices? It would have been a much bigger win to get Microsoft or Google on board from the start and launched together. Hundreds of researchers all over the world would have jumped on it. Instead now we're left with another moral authority move, shoved in developers faces at the whims of Apple Execs.
Essentially what Apple is doing is creating a new gate as they've done before with forcing developers to use their payment processing system for digital goods that costs 30% of the total fee.
Facebook Login already supports users blocking sending sites their email, as I disable that all the time. They even have published guidelines with what a site should do when they think they need that piece of information. So I'm not sold on the privacy story here. Go on, give it a try the next time you are signing in for the first time. You can even go back and remove your email permission from the security page in FB.
Apple did do one thing though, they created a bigger market for junk email services and made it easy to send those to services you expect to get notifications from. Still, this is something Apple could have built into iOS just like they did with password managers. It's not a feature that needed to be forced on anyone for any reason. As a user of the device, I can just pick, get me a junk email and presto, it's done.
I get it though, I can imagine the scenario last year right after news broke with Cambridge Analytica. This was enabled from a shady 3rd party developer using FB single sign-on and execs at Apple were pissed. They probably hastily demanded someone at Apple create something to circumvent FB's position. However, this doesn't just affect FB, it affects Twitter, Google, GitHub, Microsoft as well.
Yes Apple has good-will in this community, and its to their competitive advantage that they continue to build out more privacy focused features. However, I still do not appreciate that Apple gets the final say. This should have been a bigger conversation across the entire industry. Why didn't Apple come out and say, we are investing in the Oauth organization and then published papers on best practices? It would have been a much bigger win to get Microsoft or Google on board from the start and launched together. Hundreds of researchers all over the world would have jumped on it. Instead now we're left with another moral authority move, shoved in developers faces at the whims of Apple Execs.
I don't see how this is an anti-trust issue at all. I don't get why people keep bringing it up.
Developers are free not to implement social login. If they do implement social login then this provides a unique user benefit (privacy) while also increasing user choice (users are still free to login how they want).
Developers are free not to implement social login. If they do implement social login then this provides a unique user benefit (privacy) while also increasing user choice (users are still free to login how they want).
There's confirmation in the PDF that there's a JavaScript SDK, which is nice. Native widget in Safari, but it looks like a fairly standard OAuth flow in others.
Wow, 11 years too late, it's finally here. The new ingenious invention, by Apple, to let me sign in to apps with the account I am already logged in on my device. But hey, it's Apple, let's cheer...
WOW what a great feature, you have have done it again Apple. Keep the innovations coming!! :DDD
And apparently, to make up for the 11 year delay in developing this feature, they now force everyone to show it alongside of Google & Facebook sign-in.
WOW what a great feature, you have have done it again Apple. Keep the innovations coming!! :DDD
And apparently, to make up for the 11 year delay in developing this feature, they now force everyone to show it alongside of Google & Facebook sign-in.
Ideal world: Apple implements this feature the way they did to test the water. With a successful result we have open source tech to mask email addresses.
How does authorization (as opposed to authentication) work with apple sign in? With Google sign in you get an actual email that can be pre-authorized on the server. With this, the server only has a phony email to work with, so how can you match that phony email to authorized users?
In this sort of login authorization is considered the severs responsibility, and in most cases that use it it amounts to: you get access to you stuff. This only handles authentication. If you need managed authorization, you are going to have to handle that yourself.
IIRC users have the option to share their real email or not.
if its not open source, I can't trust even Apple.
Google's and Microsoft's sign in PMs should be ashamed they hadn't implemented this already. Giving a stable email to all services leaks valuable information that would be more lucrative for them to keep to themselves.
I'm currently using Firebase Auth to manage my logins; Wonder if I'll have to add on another authentication layer on top of it now to add this. Don't see Google adding native support for Apple Auth any time soon.
Is there any word on when this is going to be enforced as a requirement (assuming you already have FB/Google etc.)?
Is it implied that as soon as iOS 13 goes out we'll start getting app updates rejected unless this is integrated?
Is it implied that as soon as iOS 13 goes out we'll start getting app updates rejected unless this is integrated?
I would expect soon after, so some people have time to update. Maybe day one. But it didn’t sound like it would be long.
What happens if an app has iOS, web and Android versions ? Do they all have to implement apple log in now just because the iOS app needs to implement it and they want users to be able to use the app across platforms?
I really hope this is the first step to them adding scopes for accessing iCloud data (mail, calendar, notes, reminders, photos, others). Being able to write better apps for them on Android & web would be amazing.
Tested a sample demo and working OK
https://github.com/nov/apple_id/issues/1
https://github.com/nov/apple_id/issues/1
[deleted]
Previous discussion: https://news.ycombinator.com/item?id=20086045
Unless this becomes open for everyone, even for web devs that do not specifically have an Apple device and Apple Developer Licence, I do not see it getting far.
When “@privaterelay.appleid.com” starts showing up in lists like haveibeenpwnd, you know you made the right choice.
If for no other reason, this is a great reason to use it.
If for no other reason, this is a great reason to use it.
What’s the incentive for vendors to participate? Why would they switch to a less-featured product from ones that exposes all manner of user analytics?
So, you can sign in with apple, but the app can then ask for a real email address as well if they wanted to right?
So how do I benefit as a consumer?
This is a classic Apple workaround to a problem THEY perpetuate.
Apple suddenly decided on the amateur-hour policy of forcing users to use an E-mail address as their user ID. And more recently they've doubled down on that stupidity by requiring that it be a WORKING E-mail address, giving you no way to specify (in your user profile) a real E-mail address at which you can be contacted.
The public at large isn't all that savvy about how this works; so when asked to set up an account with their E-mail address and password, what percentage would you guess assumes that they have to use the same password as their actual E-mail account?
I'm guessing that percentage is very high, maybe 50%.
When sites implement this asinine policy, they become responsible not just for the user's security on that one site, but the security of the user's E-mail account. Talk about a ripe opportunity for identity theft or more, if the site's database is hacked or stolen.
You don't see banks or brokerage houses forcing people to log in with an E-mail address. Apple's ignorance of online services continues...
Apple suddenly decided on the amateur-hour policy of forcing users to use an E-mail address as their user ID. And more recently they've doubled down on that stupidity by requiring that it be a WORKING E-mail address, giving you no way to specify (in your user profile) a real E-mail address at which you can be contacted.
The public at large isn't all that savvy about how this works; so when asked to set up an account with their E-mail address and password, what percentage would you guess assumes that they have to use the same password as their actual E-mail account?
I'm guessing that percentage is very high, maybe 50%.
When sites implement this asinine policy, they become responsible not just for the user's security on that one site, but the security of the user's E-mail account. Talk about a ripe opportunity for identity theft or more, if the site's database is hacked or stolen.
You don't see banks or brokerage houses forcing people to log in with an E-mail address. Apple's ignorance of online services continues...
People are very enthusiastic about this but this is actually not going to gain a lot of traction because
- it's more difficult to implement than FB sign in and websites don't get any of the benefits
- it works with apple devices, and it will be a nightmare to use in other devices, esp. if the user uses the private email
- Apple would control and route the emails of the user and the app! This is a big privacy hole imho.
- Apple drops users or apps without second thoughts from their ecosystem, and the web is not used to this (and is not going to change)
- Maintaining new sign options is already a hassle, adding a new one that will only be accessible to a relatively small user base, with a number of hoops makes it seem less worth it.
On the plus side though, you do know that users coming from apple sign in are probably richer and better monetizable.
- it's more difficult to implement than FB sign in and websites don't get any of the benefits
- it works with apple devices, and it will be a nightmare to use in other devices, esp. if the user uses the private email
- Apple would control and route the emails of the user and the app! This is a big privacy hole imho.
- Apple drops users or apps without second thoughts from their ecosystem, and the web is not used to this (and is not going to change)
- Maintaining new sign options is already a hassle, adding a new one that will only be accessible to a relatively small user base, with a number of hoops makes it seem less worth it.
On the plus side though, you do know that users coming from apple sign in are probably richer and better monetizable.
> but this is actually not going to gain a lot of traction
You're forgetting the part where Apple is going to mandate that app developers must offer Sign In With Apple if the app offers any social logins like Facebook or Twitter, and that the Sign In With Apple option is strongly suggested to be the first one on the list.
It absolutely will gain traction.
You're forgetting the part where Apple is going to mandate that app developers must offer Sign In With Apple if the app offers any social logins like Facebook or Twitter, and that the Sign In With Apple option is strongly suggested to be the first one on the list.
It absolutely will gain traction.
I think the more likely scenario will be apps removing social logins and implementing their own login logic.
Huh? Add a handful of lines of code in your iOS/Mac app to add another login button or implement a whole server based authentication scheme? Maintain and keep secure the server based authentication for the lifetime of your app? That is not at all likely given the relative cost in money and time between the two choices.
A real email address is too important for businesses. Maybe indies or really small teams will use Apple sign in, but I doubt VC funded apps will.
it will never be more popular than fb because they don't have the user base. And this only applies for new signups, generally there is no option to switch from fb sign in -> apple sign in.
- it's more difficult to implement than FB sign in and websites don't get any of the benefits
It's standard OATH just like FB
- Apple drops users or apps without second thoughts from their ecosystem, and the web is not used to this (and is not going to change)
That's no more of an issue than if you are using any other IDP that could also drop you.
Maintaining new sign options is already a hassle, adding a new one that will only be accessible to a relatively small user base, with a number of hoops makes it seem less worth it.
iOS users are a small user base?
It's standard OATH just like FB
- Apple drops users or apps without second thoughts from their ecosystem, and the web is not used to this (and is not going to change)
That's no more of an issue than if you are using any other IDP that could also drop you.
Maintaining new sign options is already a hassle, adding a new one that will only be accessible to a relatively small user base, with a number of hoops makes it seem less worth it.
iOS users are a small user base?
> It's standard OATH just like FB
Doesn't it require an active developer subscription?
> That's no more of an issue than if you are using any other IDP
Google and FB are pretty lenient about who is allowed to use their sign in and i haven't heard of any horror stories. Comparatively apple is very aggressive in removing apps.
> iOS users are a small user base?
It's like 12-25% of users which is not a lot and it is very highly overlapping with people having FB/google accounts already, so it definitely seems like an "optional" sign in option.
Doesn't it require an active developer subscription?
> That's no more of an issue than if you are using any other IDP
Google and FB are pretty lenient about who is allowed to use their sign in and i haven't heard of any horror stories. Comparatively apple is very aggressive in removing apps.
> iOS users are a small user base?
It's like 12-25% of users which is not a lot and it is very highly overlapping with people having FB/google accounts already, so it definitely seems like an "optional" sign in option.
You’re not selling an app worldwide. In the affluent countries:
http://gs.statcounter.com/os-market-share/mobile/worldwide
-United States 54%
-United Kingdom 49%
http://gs.statcounter.com/os-market-share/mobile/japan
- Japan 70%
https://www.statista.com/statistics/861532/australia-mobile-...
-Australia 56%
Even if you take into consideration poorer countries, the more affluent population still has iOS devices.
-United States 54%
-United Kingdom 49%
http://gs.statcounter.com/os-market-share/mobile/japan
- Japan 70%
https://www.statista.com/statistics/861532/australia-mobile-...
-Australia 56%
Even if you take into consideration poorer countries, the more affluent population still has iOS devices.
[deleted]
US competition laws are outdated with undue reliance on the concept of a monopoly.
I don't care if you're a monopoly or a third of the market or even a small company. If you run a marketplace or app store or similar platform, you should NOT be able to:
- Force usage of a separate product of yours over/with competitors (in this case, Apple sign-in, but also Apple Pay instead of Google Pay, etc.)
- Prevent competing products from appearing (whether Apple not allowing other browser rendering engines, Amazon not allowing Google Home or Chromecast to be sold, etc.)
- Rank your own items higher in search results etc. if competitors can't bid to do the same e.g. sponsored results for everyone including yourself (so Amazon Basics or Google Shopping needs to be listed as a sponsored result, not as a separate feature)
This is the kind of thing 21st-century legislation for fair competition should address.