There is another world in which Apple just pushed 'Sign in with Apple' and created yet another federated identity provider rather than true, 'secure element'-based FIDO2 authentication.
Having saw Epic's developer account terminated by Apple, I would definitely stay away from any "Sign in with Apple".
(FWIW, the only 2fa with "Sign in with Apple", if you don't own any Apple hardware, is SMS.)
That said, it's generally true that any dependence on a platform is a form of risk. There are documented examples of Google kicking people out of their ecosystem unexpectedly too.
Federated sign-in schemes may be a good idea if they help your users create accounts and authenticate more easily, but it certainly seems smart to offer more than one, including your own email-based option.
Actually, it's clear that they intentionally got their _app removed_. The termination of their entire Apple account was a step I wouldn't have expected Apple to take because it underlines the fragility of their authentication system. Now, player who signed up to Fortnite on their phones can't continue to play anywhere else, probably making them regret using the Apple sign-in in the first place.
I generally consider any federated login that doesn't have an external email address attached to be fleeting, possibly disappearing out of the blue. I've lost some minor accounts when I deleted my Facebook account with services that didn't offer an email alternative. Developers, at least make adding an email/username and password optional once I've signed in with another service account, because that account might just disappear altogether one day!
- Apple never indicated that they’d remove Epic’s SIWA support, and there have been reports that Apple went out of their way to make sure the support would survive the account being terminated [0]
- Apple’s developer agreement allows them to terminate the account of an offending developer after 30 days; Epic’s account was terminated 45+ days after breach.
[0] https://daringfireball.net/linked/2020/09/29/epic-games-unre... (with the caveat that John Gruber shills for Apple, but also has some good contacts within)
A shill is a person who pretends to give a neutral endorsement but has an interest in the deal.
I've worked for a project for the tobacco industry, similar story.
https://developer.apple.com/sign-in-with-apple/usage-guideli...
Implementing a client with this also works on Android and any computer that supports some kind of hardware authentication mechanism, like fingerprint or face recognition.
Nevertheless, the suspension still clearly highlights the fealty you are expected to give to Apple being a dev on their platform, or else.
If anyone has a source to the contrary, we need it here please. And I mean a documented source, not hearsay.
Edit: there’s discussion below.
As a developer, I use my preferences as a user to steer my choices, but recognize that the world doesn't revolve around Apple so would allow other options.
> Having saw Epic's developer account t...
Since I have zero need to deliberately violate Apple's App Story policy, I don't worry about this overmuch.
That may be true today, but their policies are a moving target. Who knows what they'll be like in a year's time?
Likewise Google, Facebook, or any site/ API that a developer deals with on a daily basis.
I wouldn’t bet my company on any sign in with _____ service. I just feel the trade-offs with Apple’s sign in versus Google/ Facebook to be less bad. With any of the services, I might do something that causes me issues down the road. With Apple at least I’m not selling out my users immediately.
Single-sign-on means single point of failure.
I had to create an "account" to order a pizza. That account does nothing other than to make ordering pizzas slightly faster. I would be literally not inconvenienced at all if I had to input all that information for each order (because AutoFill.) I would also be literally not inconvenienced in the slightest if I lost access to that account and had to create another one.
To me, that's the type of "account" for which "Sign In With Apple" is a perfect solution. The type of account where it's only the provider insisting on having an account in the first place, and you would be get on just fine without one if they'd let you.
(Or, for an even more annoying example: web forums that you have to "create an account" for to read certain posts, or download attachments on those posts. Thanks for making me take five minutes to verify my email just so I can click a link on a page!)
My bank? Needs to be pretty independent of everything else.
Some random web store or something like Kickstarter? The only reason I care about those accounts is to track orders or for the convenience of not having to re-enter credit card info. The risk of losing my Apple account because ??? and dealing with recreating those accounts is negligible. In many cases I just use guest login for exactly that reason.
The convenience accounts are the ones I might use Sign in with Apple for. The bank? Not so much. But I won't trust Google or Facebook with even the convenience accounts.
I would also use something like this Touch ID on the web feature for 2FA, particularly if the only other options are SMS or email.
With Google Sign-In, you get an email address. If push comes to shove, you rip out the Google code and email everyone a traditional password.
1. Contracts are a thing. You can draft a contract with your vendor that guarantees certain terms for a certain duration.
2. You should be wary of wandering into commitments (including de facto commitments e.g. "vendor lock-in")--there are plenty of good reasons to do so, but one should make sure to properly consider the cost.
The problem is that doing business with Apple can make or break a company--companies can scarcely afford not to do business with Apple. I'm not an economist, but this seems pretty monopolistic (which isn't to say Apple should be broken up, but perhaps more tightly regulated).
The anti-trust frameworks in the US are based largely on monopolies and there is little in the way of legal precedence for protecting sellers in a monopsony market. If Epic wins their legal battle, it will likely set precedence for later cases.
Google and Facebook are also largely in weird legal ground. They have more or less exclusive access to large networks of users which is hugely disruptive to the advertising market.
[1] A monopoly is a market where there is only one provider. A monopsony is a market where there is only one buyer.
I would like to see the US crack down on anti-competitive behavior in general, but especially in cases where companies are deriving value by gate-keeping some large network. To this effect, I think Apple is a relatively minor problem compared to social media networks. Consumers have no meaningful choice (hopefully I don’t need to elaborate on why Facebook vs Twitter is a false choice) and it allows social media companies to get away with all kinds of awful behavior, but especially the ability to steer the course of democracy (by determining at scale who is exposed to which ideas and at what potency) and then selling that as a service to the highest bidder or even serving as an attack vector for other states to steer our democracy (or other democracies for that matter). A monopoly over the flow of speech is intolerable for a democracy, and at least in America where conservatives are concerned about censorship of conservative speech by Silicon Valley progressives and liberals are concerned about Russian manipulation, it seems like a naturally bipartisan concern.
Edit: genuinely wondering what downvoters are objecting to in particular? Do you not believe that social media companies have a monopoly over their own networks? Do you disagree that they can and do steer public opinion and thus public policy? Do you disagree that this is a bad outcome? Perhaps it’s a bad outcome but regulation is an ineffective solution (e.g., libertarianism)? Educate me.
Having ~50% market share is not a monopoly.
Even suggesting Apple has monopsony as I did above is a stretch and is only the case if you define the market based on paying users.
Expecting people to be in the general ballpark of the definition of a thing isn't pedantry. It's kind of hard to have any sort of meeting of the minds when people ignore even the basic premise of a term.
Most competition regulators disagree. 50% of a market is well above the threshold for both the US and EU to consider a company to be a monopoly. They usually treat the cut-off as around 20%.
Hint: It does, 100%. Epic could pick a fight with Google, tomorrow, that culminates in the same exact outcome.
It isn't?
Isn't that like, the hallmark of intelligence?
It is not the hallmark of intelligence to come up with every possible thing that could go wrong and build defenses against it just in case someone somewhere does something counter to their wellbeing.
If you use any third-party login system, think about how you can migrate users between accounts, or validate that they are who they say they are, that's perfectly normal. What if Twitter OAuth goes down? What if your Google dev account is suspended by some automated system for some reason? You should definitely have some kind of plan for that.
Spinning off contingencies in case Apple changes its developer policies out from under you and suddenly no one on iOS can log in? Too specific and arbitrary.
Honestly, I find this to be the distant second behind no account. I treat my password manager as my SSO provider in some sense.
You subscribe with `private-XXXX@apple-id.com` which relays to `foo@gmail.com`. Customer support asks you to chat with them from the same ID you signed up. Your e-mail client sends email from `foo@gmail.com`. How can you quickly respond to the customer support from `private-XXXX@apple-id.com`?
Unless of course they block you for whatever reason. Then the process of getting back access has nothing to do with convenience, security, and privacy...
I would stay away from any "Sign in with.." service as a user and as a product owner. You're affectively giving away a major control of your users to a third party.
And as a user, why would I trust my password to the website that rolled their own authentication over the big companies?
Other people have mentioned this, but if you're not reusing passwords, this shouldn't be a concern for you. Don't reuse passwords!
On the security front, companies that are implementing 3rd-party sign-in can still get hacked and leak your personal information. If that information is supplied by Apple instead of you, it's all the same. You don't automatically get better security because you're using 3rd-party sign-in, you only get better security if you're being forced to stop doing something bad (reusing passwords, enabling 2FA) or if Apple is providing less information than an account would ask for during signup.
To Apple's credit on that front, they do mask your email, which is a legitimate privacy improvement. But it would be better for that to be a generic service that allowed you to generate an anonymous email at any time for anything, rather than a perk that's hardwired into an anti-competitive scheme to make it harder for you to migrate devices or change services.
And as a user, what if Facebook/Google/Twitter/Apple decides you've violated their ToS, blocks you from your account, and now you can no longer log into any of the sites you've linked with one of those providers?
I know this is a bit extreme, and for many people, the risk is totally worth the reward, but I think that is one of the chief concerns many people have with trusting a third party for all their sign-ins. It's a single point of failure.
Do you use the same password everywhere, by any chance? :)
Thankfully, it's still fine for my bank login.
This situation is solvable by implementing forget password and storing user's email but many services don't and with a system similar to apple's where you mask the email or phone number, you can't do anything.
Even if the local auth system was poor, an email/password combo is simpler and faster without leaking data to social providers. There's no reason to remember which provider you used, or login to them first, or worry about loose permissions especially with future changes. It also limits the blast radius in case your social account ever gets compromised, and it's useful for completely anonymous and disposable accounts.
It's similar to publishing on medium (or Huffpost, from a few years ago) as opposed to your blog. You'll get more reach in the former case, but have much less control. For that matter, it's similar to serverless vs code everything and host it in a server on a rack somewhere.
Engineering is all about the tradeoffs.
So, how would I make that call? I'd think about how much it mattered to have control of the auth experience vs the easier onboarding of customers. I'd think about the risks of having the auth yanked out from under me (I'm not aware of any cases where this happened). I'd think about the value add of auth to my app; in most cases it's slim to none. I'd also look at what the auth provider allowed me to know about the user when they deliver an authenticated user to my application.
I think in general auth isn't a huge differentiator for most applications, and offloading it to a social provider, as long as a chunk or most of the target market has an account (github for devs, linkedin for sales folks, google for, well, people with an email address), is a good choice.
Don't forget, you can provide both; I've worked at companies with only social login, but don't think that's very common.
Disclosure, I now work for a company which provides auth software (link in my bio).
It's more expensive than syndicating content, sure, but I think you want to compare the relative costs of each option, not between them.
Write on medium vs writing on your own blog
Using social sign on vs building your own auth system (hopefully using a library)
But as long as that service has quality 2FA options with (ideally) Webauthn, it's much less of a concern.
You may also get users that you wouldn't have otherwise. It's a trade-off. Lowering friction tends to increase conversions.
At some point, people need to do business. Worrying about hypotheticals leads to paralysis.
Or probably they will terminate it if they don't like your business
I do not know if other terminated accounts get this "luxury".
https://www.theverge.com/2020/9/10/21431396/epic-sign-in-wit...
Apple commented they weren’t doing anything to stop Sign In with Apple working, but I have to wonder if there’s a lie of omission in there. Like “We aren’t doing anything deliberate to stop it, but it’s going to stop as a side effect of terminating their developer account.”
Either that or Epic was lying outright.
> multiple sources at Apple told me Epic’s claims were simply false. There was never a September 11 deadline for their SIWA support to stop working, and in fact, Apple’s SIWA team performed work to make sure SIWA continued working for Fortnite users despite the fact that Epic Games’s developer account had been revoked.
Or more to the point, if Apple terminates your developer account, do you think Apple's SIWA team will "perform work to make sure SIWA continues working" for your users?
If work is actually required, I'm not optimistic.
Gruber was also the one who spread the Safari Javascript is so much faster than its competitor because Apple have custom SoC and they use specialise ARM instruction to speed it up. And now even HN has a high percentage of people who believe in that without even thinking about it.
And like I said in the previous thread on HN about misinformation. None of these KOL, and including most media / publication care to fact check or to correct their previous wrong reporting.
In both Qualcomm and in IMG's Case.
The whole new Tim Cook's PR and Marketing is way worst than Steve's era in my book. Along with their business strategy and behaviour.
https://www.theverge.com/2020/9/10/21431396/epic-sign-in-wit...
And IIRC it all still works anyway, so this sounds like Epic either being confused about itself or lying to make Apple look like the bad guy (more).
And bear in mind that anyone using any third-party auth (like Twitter, Facebook or Google OAuth) could have their developer accounts terminated for violating the rules, same as Apple. I guess the key takeaway here is "if you're relying on someone else's services, don't flagrantly disregard the service's rules publicly in order to start a lawsuit and then try the case in the court of public opinion", but I think that's good advice for any service.
Not the only ones that randomly gets their accounts terminated.
Based on how apple has -insane- fragmentation and security for different aspects of the company, I would doubt any employee that isn't directly tied into the store accounts would know the whole details. (Source: GF worked for the department that did art/design for the apple stores, no one had access to their room, and they had more secure rooms that only a few employees had access to).
FWIW google has the same issues.
Don't trust a company with an account that you can't get a human on the phone for to review shit.
Not really random now right...
Ok, let’s translate it:
1) Apple believes it’s entirely in its rights to terminate Epic’s dev account and is doing so
2) Apple also believes it’s in their right to kill all related account functionally, but they aren’t, specifically with SIWA, for at least two weeks.
3) they don’t specify what will happen after two weeks, as that likely depends on several factors. We later learn that they extended it indefinitely.
So there’s multiple possible scenarios:
A) Apple really is just threatening as you indicated, but not being blatantly direct about it. Possible, but not the only possibility, and not usually their style from what I’ve seen for something like this, but who knows. I feel if Apple really wanted to threaten, they’d make the threat explicit and say “after two weeks of non-compliance, we will terminate everything”.
B) Apple is stalling making a decision over if SIWA will continue to be available to Epic’s users to ensure the SIWA team can support it when the dev account is deactivated. From other rumors where we hear folks saying SIWA team did have to make changes, I’m thinking this was the likely scenario. Don’t make a commitment to keep something going if you can’t deliver on it for sure yet, so “give them a two week extension” so you learn if you can actually keep SIWA up. If they can’t and Epic is still fighting with Fire, maybe you do terminate SIWA, but maybe not. Either way, Apple wins.
C) Apple is stalling a decision to scare Epic into compliance after Epic’s users backlash over word it might end. Possible, but I think Epic had well shown they were ready to play the Russian roulette game with Apple down to the last chamber, so I’m thinking less likely than A/B.
So if I was a betting man, I’d say it’s a mixed bag at best, but would likely go:
B > A > C
Apple doesn’t play checkers, they play chess. When they send a letter like that, they ensure there’s multiple positive outcomes for them for any potential scenario, from technical complications, to user perception, to legal proceedings, etc.
0: https://daringfireball.net/linked/2020/09/29/epic-games-unre...
According to Epic, Apple said they were going to turn it off and then changed their minds. Apple's position is they were never going to turn off Sign in with Apple for Epic.
[1]: https://twitter.com/FortniteStatus/status/130416143288864358...
I have devices logged into my iCloud account at a datacenter, that end up getting my 2FA for my other devices.
I have a iPhone, iPad, Macbook, do you think any device I actually use all the time gets the 2FA code ?
Sometimes, the same computer i’m using to login gets the code which is kinda pointless.
I have to always use SMS to get my code because of this.
If you don't renege on your agreements with Apple as part of a public pissing contest, and you aren't in the business of misleading customers and creating deceptive apps, it's unlikely they'll revoke your developer account.
I don't think anyone is crying over Apple not wanting to handle authentication for web sites offering "Illegal drugs or non-legally prescribed controlled substances."
The rest of the list is similar.
And yes, with that list Apple has once again affirmed it's not interested in helping normalize pornography. That's its choice.
> Apple reserves the right to disable Sign in with Apple on a website or app for any reason at any time.
“Show Apple or its products in a false or derogatory light.”
Who decides what’s false or derogatory?
None of these are legal definitions, Apple gets to decide what they mean. And no court of law is going to rule that they don't have the right to block when their TOS end with:
> Apple reserves the right to disable Sign in with Apple on a website or app for any reason at any time.
(IAAL, this is not legal advice.)
That's not how contract law works. There's a whole body of law around how to construe language in contracts, and it's subject to litigation and dispute if the definition isn't made clear in the contract itself.
> no court of law is going to rule that they don't have the right to block
Then you don't know courts very well. Such clauses are still subject to the law and public policy. For example, no competent court is going to allow anyone to use an escape clause to terminate a contract with someone because of their race, age, or gender.
But yeah, if you use someone's services and then publicly talk trash about them? Why should they be forced to continue to do business with you?
Do you really not see how saying, "businesses should be allowed to sever ties with people who say mean things" is different from saying, "the courts will decide whether or not you committed libel"?
> For example, no competent court is going to allow anyone to use an escape clause to terminate a contract with someone because of their race, age, or gender.
Do you think there's a difference between a court saying, "we're not going to allow you to sever a business relationship because of a protected characteristic", and "we're going to regulate what does and doesn't count as disparagement"?
Can you point me at an example of a business fighting a disparagement clause in a contract with language like this and winning, based on a court deciding that what they said didn't count as disparagement?
This is like the people who say they're going to sue Facebook for taking down posts because their definition of "misleading information" isn't specific enough. You can sue anyone for anything, but you're not going to win that case. Companies with contract language like this have broad leverage to wield their power in whatever way they see fit -- because for the most part courts have not ruled that escape clauses boiling down to "we can decide to ban you at any time for any reason" are illegal or unenforceable.
Of course I see that. Contract law and defamation law (tort) are separate domains. A court does not have to conclude that a party to a contract committed libel in order to determine that they are in breach for making disparaging remarks about the counterparty. The layperson might (understandably) believe that the analysis would be identical, but it is not. A finding of libel under tort law requires a multi-part test which I won't elaborate on here, and there are lots of defenses, too.
> Companies with contract language like this have broad leverage to wield their power in whatever way they see fit -- because for the most part courts have not ruled that escape clauses boiling down to "we can decide to ban you at any time for any reason" are illegal or unenforceable.
I think we're in violent agreement for the most part -- I'm just saying that your characterization is overbroad since obviously "any reason" is not quite "any reason." As engineers, we should strive to be as accurate as possible in our analyses and avoid hasty overgeneralizations.
At bottom, courts aren't generally inclined to force parties to do business with each other if one of them is no longer interested, there are no promises left to be fulfilled, and there's nothing binding them to an infinite term (which courts also don't like to enforce). Apple is not a common carrier or the government, and so they're treated just like anyone else for the purpose of contract law.
Nobody said they have to, just that it's very dangerous to depend on such a service. I say bad things about companies all the time!
Wait till you read the fine print in your cell phone contract.
Contracts of adhesion are just a part of life. We agree to them practically every day whenever we do business with a third party. And if you were in the other party's shoes, you'd do the same thing; otherwise you couldn't practically run a business.
I wrote about it here (long post):
https://news.ycombinator.com/item?id=24827031
I haven't quite processed this entirely yet. Part of me feels one or more adults on the world stage need to get behind what I will call a canonical approach to login, authentication, account recovery, password policies, etc.
In some ways I equate this mess to what happened back when fire hydrants were not compatible with every hose coupling fire departments used. In other words, it was a mess and people got hurt.
Standardization is good. Or can be good. After this weekend I can't help but think that this is another area where the web needs to seek standardization. I get the feeling that every n-th developer is rolling their own approach and the result is an absolute mess.
Not advocating for an Apple solution, just saying that I had a revelation this past weekend and what I learned does not speak kindly of how this important aspect of online life is being handled.
- "small" players like Mozzila who don't have a big enough marketing budget or leverage from existing products to drive adoption.
- large companies who are willing to throw large sums of money into this with the goal of monopolizing auth, and using that monopoly to manipulate related markets. In the non-Apple cases (Google, Facebook, Microsoft), it also involves collecting data on users for ad targetting.
It feels like a little like the first day we start to understand how "Big Tent" (in the OpenStack sense) FIDO2 ecosystem is. You can do whatever, make anything, and call it FIDO2; it's all duck typing: looks like a duck, quacks must be a duck. No implementation details are required, no transparency is needed, everything can be totally vendored way way up, and the standard will welcome you. Your platform is welcome here. This post is about how to use & prefer that platform, over the more common means available.
For sure this is overwhelmingly a good thing. It's by design that we allow platform authenticators in WebAuthn. Apple is allowing their closed, proprietary security technologies to seamlessly work on the web without making webdevs jump through hoops. It's a good thing, and this will really help Web Authentication for sure.
Still I have some wistfulness. It's a good user experience, it's great. It's a win for devs, it's a win for users. Still there's some larger context I can't quite put my finger on, when I see "authenticatorSelection: { authenticatorAttachment: "platform" }". The web is letting more of the native platform shine through, and that's good, but it also forgoes some of the knowability & commonality that resounds on so much of the rest of the web, and while the immediate impact is extremely good, I still think there's some kind of hard to describe ultra-slow-motion civilization-scale loss that's also passenger to this successful commingling of web and platform.
News like this where we can tell people "it already works because we made the right decision" is fun.
I think about Apple Pay for web - it started out as a proprietary API, and then the Payment Request API standard was developed and they added support for that.
It's in Apple's interest to help develop and support standards like this because they mean more adoption of their platform features.
What do you mean? All Mac models introduced since 2016 support USB-C.
I am 100% on board with USB-C on computers -- but the use cases that apply to a laptop/desktop are very different than how people use phones.