Hacker News new | past | comments | ask | show | jobs | submit login

A lot of the points they make here are real points, and I think AnyList has validity in their actions.

I also think it’s not as unmanageable as it seems.

Let’s analyze this quote, from the article, as it highlights what I imagine are a big crux of this issue:

> with the “Hide My Email” option, your spouse or friends obviously won’t know your privaterelay.appleid.com email address, so when they enter your email address, our systems will believe that you don’t have an account

Since you know this to be the case, why not have an onboard if flow they Sign In with Apple where you have them A) choose a visibility email used for sharing/communication etc. and B) allow for this email to be their backup email? So if they forget their login or whatever you could just transfer the account to this email instead? Of course this should be opt-in but you can always Under good faith explain benefits there in.

It’s more work, but I don’t believe that it’s going to run issue with Apple and provides end users with flexibility.

Of course this may not be worth it, at all. This is just a consideration worth thinking about as an app developer

edit: Of course another alternative here is they just make users aware of what their sharing email is and allow users to optionally change that, if they want to. This most definitely wouldn’t run counter to this I’d think






> Since you know this to be the case, why not have an onboard if flow they Sign In with Apple where you have them A) choose a visibility email used for sharing/communication etc. and B) allow for this email to be their backup email? So if they forget their login or whatever you could just transfer the account to this email instead?

I'm fairly certain that detecting someone hiding their e-mail from you and then making them pick a different e-mail goes against the spirit, if not the rules, of Sign In with Apple.

That said, it would be extremely beneficial to pop up a screen saying "Hey, is this the e-mail you want to use for communications?" and let the user decide.

That said, removing third-party sign-in is also a fine solution, almost definitely a better one, and simplifies things immensely for everyone involved (assuming their sign-in form in the app supports saving passwords to the keychain).


> making them pick a different e-mail

I think it's more about _letting_ them pick a different email. While I can understand that AnyList (or any other app for that matter) would want to, on occasion, send marketing emails to users, I don't think any app would, in their right mind, _require_ the user to provide a 2nd email address.

But by allowing them to optionally give that 2nd address, they can provide a path forwards with people being able to use Sign In With Apple (of course, that means some users may opt out of marketing emails entirely by refusing to provide a 2nd address).

This does probably go against the spirit of the feature, but if it actually is against Apple's rules to be doing this (anyone know the answer to this?), then it would definitely veer on the side of user hostility on Apple's part, since I would expect many apps to be taking a stance similar to the one taken by AnyList here.


So someone explicitly chose to hide their email, and then on logging into an app is asked to share their real email.

Anyone in that position would think the app is shady AF and user hostile.


Progressive consent makes sense though: in starting out with an app that i have no previous trust relationship, "Hide my email" sounds like a good idea in a trial balloon. If after using the application it tells me that to better use its collaboration tools it would like me to consent in giving a more direct email address, I might change my mind given changes in trust relationship (I have been using this app for some time and I trust it more now) and/or greater context for why the app is interested in a more direct email address ("make collaboration easier").

It's not necessarily shady or user hostile when done right, and there are plenty of opportunity to add trust relationship building as a part of the consent process (links to privacy policies; details about marketing policies; etc).

It's also not that different from how many iOS applications (at least) are encouraged (in App Store best practices) to handle consent models for location tracking and notifications: ask the user as they become familiar with the application, not up front, and provide as much context as you can.


I like this approach. And giving users that progresive consent is smart. If I open your app and am greeted with "You need to give us your email to get the most out of our app" then I'll be upset as that is user hostile. But If I click a share button and am told "In order to make it easier for people to send you things, would you provide your email" and being able to dismiss that and continue to use the app and all of its features, I'll be significantly happier.

That said though, I don't see why the app couldnt just change their sharing model to an "invite link" based pattern. If I want to share something with a friend, why do I need to provide their private information to the app to do it? Why can't I generate an invite link and send that through my already established channels of communication? I don't think the "but your friends don't know your Apple privacy email" reason is very compelling. That might not work in their current system, but it is definitely not an insurmountable problem.


That's something that bugged me about the article because it sounds like they do fallback to an "invite link" pattern when they don't know an email address, but it sounds like they've spent most of their UX optimization work on flowing people most directly from invite links into "Create Account" that they don't trust users not to create new accounts on receiving an invite link. (Maybe just stop assuming that people receiving invite links don't already have accounts and instead better your UX flows for existing users?)

(ETA: They make an okay follow up point that someone accepting an invite link sent to a different email sends a signal that they could just go ahead and link that email address directly to the account, and don't see why you wouldn't just give them that email in the first place. But in addition to being a squicky privacy faux pas to automatically link any email to an account without direct user consent, there are plenty of reasons to send emails to an address only indirectly linked to a person and/or that a user would not feel comfortable directly linking to an account. It's a somewhat flimsy argument below the surface, I think.)


While I can understand that AnyList (or any other app for that matter) would want to, on occasion, send marketing emails to users

I am not an AnyList user but do they ask when signing up if users would like to opt in to such marketing messages? It’s become such a pet peeve buying something from an online purveyor and not even having the choice to opt in or not on marketing emails and any other form of communication I did not explicitly ask for beyond completing a purchase.

seems like another reason for progressive consent and ASKING your users how they would like to be contacted and honoring those preferences


For this use case there is no need to collect real email address. The obfuscated email that apple provides can be used to send emails to the user.

You don't have to ask for the email at all, if you don't want to. Pinterest apparently does not, so for them SIWA is just an authenticator.

In a perfect world people would share things with you without entering your private email address in other people's systems. I don't want to be in the database of whatever app or system my friends decided to join, nor I want to receive spam from these companies.

Many of the objections come from wanting to do things the old way, without privacy and responsible handling of private data.


> Many of the objections come from wanting to do things the old way, without privacy and responsible handling of private data.

No, they come from the fact that privacy comes at a cost. In this case, it's much harder to receive support, find your account if you lose it, and get proper communication. Everything is a trade off, and anyone who thinks the reason things have been done this way is only to scoop up as much data as possible is either brainwashed or naive. These changes are adding a whole new layer of complexity, which may be worth it in some cases, but in others it just is a net negative for the customer.


Can you elaborate on "private email address"? I'd be offended if someone were careless with a more intimate identifier like my personal cell phone number, but I've always considered arms-length interactions with businesses and institutions I'm not fully on board with to be the whole point of email.

I have a private email address and a catch all address for a variety of websites.

{app_name}@example.com goes to the same place, but it is easy for me to see if they sell/lose my email. And if it gets lost I'm done with them I can just block that specific address.

The added benefit is no one can assume that {my_name}@example.com is my bank email address or my email login.

I used to have a standard {username}@gmail.com for a while, but now it is on 20+ breached site lists. Best case? Copious amounts of spam. Worst case? I may have been reusing a password prior to switching to a password manager.

Now, I can just block the email from receiving anything. Two, if I accidentally reuse a password the username is at least different.


I wonder if Apple would be ok with asking them to give up their email?

Apple clearly likes the idea of the hide option... personally I would expect a less than positive reception from Apple.

I get where both AnyList (if they asked) and Apple (if they didn't like it) would be coming from here.

It does seem to be a shortcoming here where outside of a user one time sign up situation... you don't want to have to burden the user with coming up with silly names and codes to use social like features that require someone else knowing an identifier for you that isn't email.

I don't want to go back to a time where we have to remember / pass along everyone's ICQ number. ...


I think it would come down to user hostility here.

If I sign in with Apple and opt out of giving my email only to be faced with a prompt demanding I give up my email address, I'll be upset. I JUST told the app (via checking the box in Apple) that I don't want to give my mail, so why is it now suddenly required?

However if the app allows me to sign in and only asks for my email when I try to interact with a feature that would be more usable had I given my email, then I would be more accepting of it. Though I would still fully expect to be able to use the app in its entirety even if I opt out.

Now what Apple will say to this, I have no idea. But as a privacy conscious user, I would be happier with this.

As for having to come up with silly names, I don't understand why I need to be discoverable within an app. We have established social media and communication platforms, use them. Let me send a link to a friend to connect with them in your random app. I don't need to be able to add them within the dang app.


I think the problem is that once you want to be found, like for a grocery shopping app, most folks think you search and just find them and when it doesn't work....they don't know to go find some settings and figure it out.

Yeah but I dont want to be found. That's why I don't share my email. If I want to share with someone, I don't want the use that app to establish a link between us, because I don't want the app to know anything about us except what it must to do it's job.

"Go find some setting and figure it out" is a UX fail. When I share eg a Dropbox link or a Google Photos link, you can get to it whether you have an established account or not. If there's something special about an app that requires an account before interaction is possible, then you can still make it a one-time share.

Yes, it does make user support more complicated. Yes, that's what I want and expect. I hope when I come asking for help, you can't help me because you have no clue who I am and have no way to get in touch with me because I used some email obscuring service. That's on me.


I get your use case.

But in this case the company is someone who claims to be "The best way to create and share a grocery shopping list and organize your recipes."

Sharing is part of the deal with them and a sign in process that from the start complicates it is understandably a no go / introduces all sorts of complications that they detail in the article.


I get that sharing is a core thing for this app. I just don't think sharing should have anything to do with my identity. It can be a hash that is shared across any communications platform (even by meat-space, vocally!).

If the goal for the app is for itself to be a tool for identity management, then knowing my email is especially not needed...after all, all identity context is already in the app!

UX should center around ease of sharing some hash value across some other medium, not "searching by identity."

I do honestly empathize with the app creators. But anybody choosing an obscuring email by definition does not want to be identified by email.


My anecdote: About 4 years ago, I looked a shared google spreadsheet with logged with my account. I thought that my account isn't shown to document owner but it seems not. I don't know whether I clicked something like share-account button.

I don't think Apple would care about asking for email for legitimate use. I thought the point of Sign in with Apple is that it decouples giving away your email from signing up. Not that it bans apps from collecting emails in any way.

I hope so.

Why should Apple be allowed to dictate if an app asks for an email address? They should not become the defacto law makers of our society

That ship sailed long ago. Apple basically has apps and app-developers by the balls, not to mention the 30% extortion money they try to get not just for app purchases but any transaction done within the app, so much as even banning an app from telling the user that they can do the transaction elsewhere.

It makes my blood boil but from the discussions I see on HN about it, most people here seem to be more or less ok with it.


It’s not any transaction. It’s any digital transaction. You can sell physical goods and services either without giving Apple any cut, or by using Apple Pay and Apple just gets your standard credit card processing fee.

Does Walmart let you sell your product in their store and say you can look at it there but get it cheaper from Amazon?


My app is not the App Store. The user has already paid to download my app from the App Store and Apple has gotten 30% of the cut. What users do on my App after that is none of Apple's business, though of course Apple would like to claim otherwise.

Similarly, once I have bought something from Walmart I can use it as I wish. Our business transaction ends there, so your analogy isn't really apt.

> Does Walmart let you sell your product in their store and say you can look at it there but get it cheaper from Amazon?

Funny you say that, because Walmart and many other brick-and-mortal retailers will happily price-match Amazon and each other. You know why? Because they are not a monopoly or pseudo-monopoly and so need to do good by their users to compete.

Of course you can justify Apple's behavior any way because you can claim that I am on an iPhone so I am on their property or something and so they are my overlords but that is precisely what users here are trying to argue against.

Or to be honest, you don't even need to justify it that way. The magical market justifies it because the fact that these apps are on the Apple ecosystem means that staying on it is better for them than staying off it. And no other justification is necessary. And you would not be wrong.

But people have a moral intuition about these things based on how they see the world work, and so they have an intuitive sense for when something seems 'off', even if the market seems like it's working. That's why they complain against things like exorbitant pay-day loans despite them too being an example of a market that seems to be working.

Last I checked, I did not get an iPhone on lease from Apple. This attitude where just because I am on an iPhone means I owe Apple in perpetuity needs to die.


> My app is not the App Store. The user has already paid to download my app from the App Store and Apple has gotten 30% of the cut. What users do on my App after that is none of Apple's business, though of course Apple would like to claim otherwise.

It seems like you are the one who would like to claim otherwise, since to get your app in the store you have already agreed both to the terms of the developer program and to follow Apple's guidelines.


Not agreeing with what are arbitrary rules on the App Store and with the percentage that Apple takes as a cut, but this paragraph opens up many issues with running a platform:

> The user has already paid to download my app from the App Store and Apple has gotten 30% of the cut. What users do on my App after that is none of Apple's business, though of course Apple would like to claim otherwise.

If the App Store runs the way you describe, then everybody would offer their apps for free to avoid the 30% cut and also not have any in-app purchases (since those also have a cut). The result would be the user installing the app and having to go to a website (even if it’s embedded in the app in a web view) to create yet another account, finish the signup process, go through a separate (and usually lengthy) payment process to actually buy the app and managing those payments in cases where those are subscriptions.

One can argue on the merits and demerits of Apple’s current system (which needs an overhaul, IMO), but the other option isn’t without demerits as far as users and user experience are concerned.


> once I have bought something from Walmart I can use it as I wish.

Not if it's a movie, music, or video game. I.e. anything with digital content.


Providers of digital content seem to be absolutely all over the place with this stuff

Comcast of all people offers the ability to buy movies on demand. Not just rent but outright purchase. If you leave Comcast as a customer, you can have every purchase mailed to you as either a DVD (SD) or Blu Ray (HD) purchase

Steam has provisions in place that if its service ever gets terminated to allow users to continue to use games they've purchased on the platform. They also allow users to continue to download and play games either removed from the store or no longer sold (Alan Wake and Deadpool being two examples in my own library)

Conversely Microsoft's Xbox will de-list titles and make them excruciatingly hard to download, such as Marble Blast Ultra. Requiring you to find the game in your account history and then use that to navigate to a download page

Sony's Playstation is downright malicious with their digital store. Konami's "P.T" was offered as a free download as a teaser for an upcoming Silent Hill game

Once Konami changed their mind however, the game was not only removed from the store but actively wiped from the users console! If you connected to Playstation Network the game would be forcefully deleted from your device


You don’t own any of these things, you own a license to the content and the physical disc.

It’s completely different to owning something.

Steams provisions are helpful in practice but ultimately meaningless because you don’t own any of the actual games, you merely have a license to run the code under their terms.


Funny you say that, because Walmart and many other brick-and-mortal retailers will happily price-match Amazon and each other. You know why? Because they are not a monopoly or pseudo-monopoly and so need to do good by their users to compete.

Many stores get around that by having special SKUs that are only available in their store.

Also, Android has a slightly larger share in the US and a much larger share worldwide. Apple is no more of a “monopoly” than the console makers.


Actually, you're free to add "check out our online store" in the packaging of the product sold at Walmart or Amazon.

So Apple is being extra controlling here. They consider all Apple users property of Apple, so they take a cut off all digital transactions.


I have never seen a product at Walmart advertising that you should buy the product online at another retailer to avoid the “Walmart tax”.

It hasn't sailed yet. We'll have to see what comes out of the antitrust litigations in the EU and, if I'm not mistaken, also in the US.

They don't, the user controls this. When the user authorizes the client, they have the option to share their actual Apple ID email or use an obfuscated one.

Apple isn't forcing anything here.


I'm not sure they should be able to, but I assume they could disable Sign in with Apple for a given site if they wished.

This applies to any SSO.

> with the “Hide My Email” option, your spouse or friends obviously won’t know your privaterelay.appleid.com email address, so when they enter your email address, our systems will believe that you don’t have an account

Just create an invitation or "share list" link and let the user send it in any way they prefer, be it AirDrop, email or SMS.

The recipient clicks the link, and the service can connect the two accounts as needed (allowing the potentially new user to create an account as needed).


Do you know if this is allowed within the scope of Sign In with Apple policies? A company I work with is implementing Sign In with Apple and said they can't do this. Not sure if they're right or if this is their weird interpretation.

I couldn’t find anything in an admittedly shallow search of the requirements or documentation.

Of course another alternative here is they just make users aware of what their sharing email is and allow users to optionally change that, if they want to.

I think their perfectly valid to do what they’re doing but I also don’t buy into this being an overly complicated logistical hurdle either


Having a user name solve this. Github collaboration works the same way.



Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: