"Sign In with Apple will be available for beta testing this summer. 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."
Someone at Apple deserves a raise.
(Data is mostly correct though)
Fortunately, most payment terminals in London already supported NFC payments thanks to NFC debit and credit cards long being prevalent here, and Apple Pay is just tokenised NFC payments.
Same is true of literally every iPhone owner I know, and usage simply increased as payment limits went from £20 to £30 to unlimited (unlimited on Apple Pay, but still limited to £30 on NFC cards or when using older payment terminals).
Plus I got to ditch my oyster card and just use weekly fare capping after a while too. Good times.
I have switched almost exclusively to Apple Pay, and frequent only one chain of gas station because they rolled out NFC at all of their pumps last year. After the introduction of chip readers gas pump mag stripe readers became the main vector for card skimming in my area and even with the security stickers all of the gas stations have been putting on their pumps I don't trust any mag reader anymore.
At locations that don't have an Apple Pay logo on their card readers, like my local movie theater, I have spied the NFC logo and given it a try and it works.
Except for Amazon, almost all of my online shopping is now done through Apple Pay. I have a shirt out for delivery today from a small retailer I had never heard of before that I purchased with one click and a fingerprint via Apple Pay.
It has not only changed how I buy things, but how I dress. Instead of my George Costanza wallet I only carry an ID and two cards in a slim front pocket wallet, relying on Apple Pay for almost everything and walking out of a store if they are cash-only or don't support chip/NFC.
Regardless of your chosen NFC platform, I recommend that everyone use it and shun points of sale that don't have it.
Personally I used it only once (although I am not in US market)
Quite the gambit.
Even the existing Sign In with Facebook is implemented terribly by many apps, e.g. requiring me to enter my password in app instead of calling out to the Facebook app like maybe 50 of apps support properly.
I think honestly this comes from apps that are built with cross platform frameworks but its still frustrating.
Further more it drives me crazy new apps (and websites) released this year focused on mobile (e.g. pay for fuel at a fuel station with your phone) and I can't even auto complete the credit card or name using the new keyboard extensions because they somehow labelled the forms in a way apple can't figure out.
For example, Slack can be (and is often) configured to use Okta or some other SSO provider. Does the Slack app have to implement some kind of support for Apple Sign In when such use cases are involved?
Not for the first half of the iPhone’s life, I’d say.
This sounds like a tremendous headache that I really don’t want to worry about. But Apple is looking to leverage their power in the app market to force me to implement a tool I may not be interested in as a merchant?
I despise being strong armed. I hope the EU crushes this.
However, I wish email and sms would go away as a way to authenticate. Until it does I will be using foo+aliashere@gmail.com so that my account can’t get transferred to someone else through socially engineering a tired rep.
I personally don’t use FB login. And I use `+merchant` to keep track of bad actors. But from a merchant perspective this will likely be a chore. And Apple has decided that we don’t get to decide if it’s worth it. We can’t disable FB login because we’ve supported it for a long time and a ton of accounts only have a FB-synced profile.
To be clear, it’s not the product I have issue with. It’s the draconian ultimatum that because we are in bed with FB we have to also get in bed with Apple Sign In.
They could have just built this into their form system. It already recommends my personal email / credit card / auto generated password. Why not prepopulate / suggest an Apple-generated email? Why force the merchant to implement another standard which breaks all other SSO integrations _by design_?
I don’t have answers to those questions. If this was a consumer feature embedded into their keyboard I’d be ecstatic. Strong arming merchants to implement and bear the full cost of confused consumers who can’t seem to login to their app _even when they click the Apple button_ is inexplicable (to me).
https://tools.ietf.org/html/rfc5233
Not Gmail-specific. Labels however are ;)
Can confirm what parent poster is saying, we remove them on signup.
Also, if you try to mail people based on GeoIP data, you're going to have a bad time.
You could argue that a major feature of the GDPR is to legislate that just because a company can do something, doesn't mean it's allowed to do it.
user@domain.com
The 'detail' is optional, and doesn't infer any privacy.
It's kind of like if you get mail delivered to:
nprateem, office 2, university of ycombinator
and instead they only store:
nprateem, university of ycombinator
Odds are, mail will still be delivered to you, but it might not come to office 2, and might come to office 1 instead. It's not what you wanted, but there's absolutely no impact to your privacy by them stripping away additional details.
The 'user' part is still public information, as is what it's used for. There should be no expectation of privacy for information being used per specification design.
The usability trade-off is a shame, but the solution was half-baked at best, and is primarily useful when combined with privacy-sacrificing public email providers. When you have greater control of your email, distinct 'user' parts can be used, which does provide the privacy aspect desired.
> we also don’t operate in any country requiring compliance with the GDPR
You know it's nothing to do with the country you operate in but the nationalities of your customers though don't you? You could only have a presence on the moon but if you had any EU customers you'd still be bound by the GDPR AFAIK.
But why?
The above scenario goes against what they are trying to achieve though
1) If you support SSO and email/password - then the email and password are still stored (and possibly not hashed and salted if the developer is incompetent) - so you are at risk of compromise if you reuse passwords 2) If you store the users actual email, you are putting them at risk of credential stuffing, as well as opening them up to tracking
The EU can always surprise, but I suspect they would actually like this because it addresses key risks to consumers of password reuse, credential stuffing, and tracking. Additionally it competes against their ideological targets, Facebook and Google.
Not saying what the EU does is goos or bad, but painting it as pro free market competition seems unfounded.
Every tech related legislation doesn’t and shouldn’t need to so,be every tech related problem. The EU has other, non GDPR related, mechanisms to handle monopoly issues.
So to me it seems unfounded to say EU cares about market health and is not, in fact, just picking on FB and Google.
I am honestly curious what you think are examples of EU mechanisms fostering healthy markets. Maybe the MS case but that is the same “EU picks on US tech giant” genre.
I’m not sure what kind of examples you want.
Once I chose to use Apple-Sign In will I be locked into the ecosystem? Will there be 'Apple-Sign In' for Android?
That said, the concept of "Apple Sign-In" for Android and other platforms is an interesting one, not likely in the short term, but possible someday!
Unless I'm misunderstanding what the mandatory part is.
The option is mandatory. End users using it is optional.
Again, the tech is fine. The strong-arm is indefensible.
If you support FB login now and decided to add Google, for example, that doesn't require your existing FB users to do anything different. It should only affect new users who are creating an account and choosing to use the new provider. Wouldn't that be the same for Apple Sign In?
Note, I'm not taking a position on the strong arm tactics, just pushing back on your claim regarding existing users being affected by a new identity provider. That doesn't sound right to me.
A service supporting alternate identity providers via OAuth (Facebook, Twitter, Google, Github) via a flow like this shouldn't have trouble with Apple Sign In from a web page, iOS app, or Android app.
I have to assume there will be exceptions.
obviously apple has considered this and is forging on anyway. good for them.
Excluding other third party sign on options would be problematic if Apple were abusing a dominant position among smartphone makers, which is not the case by any objective measure.
Note that I'm not making an argument about how to classify the behavior legally, I'm arguing that calling it "competing" is pretty generous.
For instance, even if Apple decides to increase the app store fee to 50% so its app's prices as well, still consumers don't have much choice since buying a new phone is typically more expensive by order of magnitude than buying an app. This is also a part of Spotify's claim as well and Apple is trying to defend itself for this time unlike Apple v. Pepper.
Pretty much the standard.
I haven’t studied this since the late 90’s, so I may be out of date...
Apple would have long ago been cited for Antitrust if Android hadn’t had most of the market. I personally think that the definition of a trust is too narrow — one member of an oligopoly abusing its position as a platform provider and strongarming people is also pretty bad.
https://www.theverge.com/platform/amp/2019/6/3/18650861/appl...
It's not entirely how European anti-trust law works.
If Apple was the only provider of smartphones then there would be a case for them to open up their platform to third parties.
If it's defined as a market, then Apple will be surely in trouble but enforcing Apple ID alone doesn't make much differences from the current situation as it always has been doing similar things for web browsers, music apps, app store itself etc. So it's pretty natural to enforce this policy for Apple; no additional risks but only benefits.