I'm glad they've got the tech right for the actual authentication, but their email relay is still far from usable.
It's limited in very fundamental ways, that will prevent many companies of any scale from using it. It's very difficult to make it work with an email service such as SendGrid, and it's limited to 10 domains you can prove ownership of, and 10 specific email addresses.
I work for a company that charges users and ships physical products – our payment providers and shipping providers all need to be able to contact our customers if they choose to use those services, but this would be essentially impossible (or a prohibitive amount of technical work at scale).
I think maybe if everybody selling something didn’t make the audacious assumption that I’m also providing my email address because I really want you to spam the shit out of me with all of your announcements and promotions, it wouldn’t have to come to this.
I certainly don’t want anybody I buy from having my Apple ID email, and they should not assume that just because it is a user identifier, that does not mean it’s even used for email. Some retailers do this with things like paypal, and actually overwrite the supplied email address with the one from paypal. Really annoying.
The correct pattern is to ask the user for the email address that they would like you to have. And preferably, never send email to it again.
In order to send email messages through the relay service to the users’ personal inboxes, you will need to register your outbound email domains. All registered domains must create Sender Policy Framework (SPF) DNS TXT records in order to transit Apple’s private mail relay. You can register up to 10 domains and communication emails.
I've rarely seen vendors sharing e-mails with payment and shipping companies, and would consider it somewhat icky for privacy reasons, especially when done without the user's consent.
It also seems that you could set up your own relay allowing those providers to contact your customers. In fact, that would be the privacy-conscious alternative even to your current implementation.
Many delivery providers need to be able to contact the person they are delivering to. This is standard practice. The same is true for many non-trivial payment providers (such as PayPal/Klarna).
This data is shared for the legitimate interests of the customer. You've bought something and asked to a) pay for it, and b) have it delivered. I think it's reasonable to expect that the companies involved in this can contact you for the purposes of fulfilling your request.
This is all done under GDPR. The companies hold the data only for as long as they need, for the purposes explicitly requested by the user. This will all be included in privacy policies.
> It also seems that you could set up your own relay allowing those providers to contact your customers.
This might be technically possible, but introduces many concerns such as deliverability and spam ratings. Relaying email in this way is non-trivial when you're doing it at scale. For services sending ~100k emails a month or more, this requires careful planning because it's very easy to become filtered as spam.
1. You already gave those downstream vendors your contact information so they can, you know, ship your package to your home and charge your credit card.
2. 99.99% of all users probably want to be emailed tracking information or payment confirmation information. Adding such a checkbox only adds friction to their funnel in order to please an incredibly small minority of people using their site.
Thanks for that . A couple of things: 1. I don’t think an E-mail address is really necessary in order to ship a package or charge a credit card. 2. Friction and convenience used to be acceptable reasons to collect personal info without consent but maybe that’s starting to change. I highly doubt the 99.99% figure but having no data of my own I won’t dispute it. I trust that you have seen such an opt-in rate for sharing E-mail addresses in your past user research.
> I don’t think an E-mail address is really necessary in order to ship a package or charge a credit card.
For credit cards, no it's not (but would be for pay-later, PayPal perhaps, Alipay, AmazonPay, maybe).
For shipping, most shipping companies have the option to handle the customer communication. When creating an order you provide them an email address and/or phone number, and they will send notifications. Many use these channels to provide the user the ability to reschedule deliveries, select delivery windows, change their delivery address, etc. This process is often also white-labelled so you may not realise that it's actually with the delivery company.
These details are not stored long term, only for the purposes of doing the delivery, any applicable returns process, and any insurance claims, etc.
It is possible to not do this, but assuming the retailer wishes to provide the same level of communication it means a much deeper level of integration, as tracking data needs to be ingested by the retailer. Given the industry has no standards for this, and "integrations" are SFTP + cron jobs once a day + CSVs, this can be pretty difficult, error prone, and result in a poor UX where you don't actually have the granularity of data to send an email when the package has been delivered.
> Friction and convenience used to be acceptable reasons to collect personal info without consent but maybe that’s starting to change.
We have found that it is within the user's expectation that we will share contact details to the third parties necessary to complete their order in this manner. It's in our privacy policy that we do this. We also check that all of our suppliers understand their GDPR responsibilities.
> I've rarely seen vendors sharing e-mails with payment and shipping companies
If it was done correctly, odds are good you wouldn't even know those emails originated from a third party vendor. Plenty off stuff you order is fulfilled by third party vendors who specialize in payment & logistics.
For example, if you ever ordered contact lenses from costco, the whole damn thing is driven from vendor called "WVA"[0]. I'm pretty sure it is completely turn-key. Only way I figured out what was going on was looking at the return address in streetview.
I ordered a lockpicking from an online vendor and it was fulfilled by some logistics provider on the east coast. Same kind of thing...
So I'm not actually sure what your problem is, but plenty of businesses have a need to share your contact information with their vendors.
> In order to perform this we share basic user details with them only for the purpose of performing this check, and on the basis of this check the provider will either agree or decline to offer the credit.
> How does the payments provider know if the customer has an outstanding balance? They use the customer’s email address.
> [...] Unfortunately this is completely ineffective for the pay-later scenario, which depends on being able to correlate user accounts.
I'm finding it hard that an organisation that is capable of doing a credit check on me (which doesn't rely on my email address) is unable to account for multiple debts without using my email address.
Infact, if they are only using my email address, that is absurd, as one email address != one person.
> Services that use dynamic domains (for example thread.foobar.com) will be unable to authenticate all of their domains.
Services that use dynamic domains (for example thread.youjustgotphished.com) will be unable to be authenticated by end users as being legitimate. Dont do it.
> Best practice for email deliverability suggests that senders should send from a different domain per category of email that they send8. This mostly applies to larger products, but 10 domains is too limiting.
Because our industry is rampant with spam, we have created new ways to try and bypass spam filters. Nope, go away.
> In the EU where GDPR restricts what companies may do with customer data, this leaves Apple’s SSO providing little to no benefit over what is already required by law.
Another layer of protection against companies that fail to abide by the law (and companies that wilfully neglect their obligations under the law) is more valuable than "little to no benefit" to end users.
Sorry to be really blunt, but these are just the highlights. As an end user, all I have for [the retailer] is a tiny violin. Retailers at large have demonstrated a fundamental lack of respect for end users. Apple's service looks like it lacks respect for the new-norms that retailers have adopted.
I get that you don't like spam. Neither do I! I'm very keen on anything to reduce this.
What we're talking about here is not spam. We're talking about transactional email that a user wants. I know that when we fail to send order dispatch emails users shout "Scam!" because it looks like we've taken their money without doing anything. I know that users like being able to pick up their order at a local store (with a security code). I know that users like to be able to pay with a range of payment options.
We're not talking about marketing here, we're talking about the minimum of communication for a user to feel that they can trust a retailer.
Yes the industry abuses email, but these examples are not that.
As for the credit check, email is certainly not the only signal they use, but in the typical case it's an easy one to check that can provide high signal. I don't want to speak for the service provider, but this sounds like one good approach to me.
> Apple's service looks like it lacks respect for the new-norms that retailers have adopted.
Apple's service makes it impossible for retailers who respect users privacy and marketing preferences to operate the core of their business.
Thank you for taking the time to reply. Appreciate it.
> I get that you don't like spam. Neither do I! I'm very keen on anything to reduce this. What we're talking about here is not spam ... We're not talking about marketing here ... Yes the industry abuses email, but these examples are not that.
> Apple's service makes it impossible for retailers who respect users privacy and marketing preferences to operate the core of their business.
Unfortunately, while that may be true of your business, it's not true of others. You know the saying about bad apples spoiling barrels, right?
In the case of any legitimate email from third parties, your business can now be the relay for those emails. Instead of @ emailing me about a purchase from legitimateretailer.com, moving forward only *@legitimateretailer.com (and up to 9 more domains...) can email me about that purchase. And on top of that, legitimateretailer.com is required to do the bare minimum to try and reduce spoofing off their domain. Ideally DKIM and DMARC would be mandatory as well, and not just SPF!
For it to be any different, Apple would need to certify every partner in the chain used by any retailer. Every time a new partner is engaged, Apple would need to be notified and that partner certified. That seems even more onerous.
> As for the credit check, email is certainly not the only signal they use, but in the typical case it's an easy one to check that can provide high signal
KYC requirements in financial businesses are pretty strict. If losing this signal is a problem for your business, you're probably violating regulatory requirements. See previous remarks about value provided & legal requirements.
It's limited in very fundamental ways, that will prevent many companies of any scale from using it. It's very difficult to make it work with an email service such as SendGrid, and it's limited to 10 domains you can prove ownership of, and 10 specific email addresses.
I work for a company that charges users and ships physical products – our payment providers and shipping providers all need to be able to contact our customers if they choose to use those services, but this would be essentially impossible (or a prohibitive amount of technical work at scale).
It's a very poor implementation. I wrote an obnoxiously long blog post about this. https://danpalmer.me/2019-07-02-on-signing-in-with-apple/