471–480 of 485 posts
Earlier quoted context omitted.
I assume they rely on the fact that sharing a random list with a random person a thousand times is pointless.
What if the list contains/is itself advertising, and the random person is everyone on a huge list of active email accounts?
Earlier quoted context omitted.
For the first point, the app can explicitly tell the user what their login is, or otherwise assign some unique identifier the user can use when contacting support. The app can also offer to contact support for them, which can pre-fill the user identifier. For the second, that’s entirely the user’s choice. Your app can also allow them to associate a new email address for this purpose (which strikes me as exactly what…
> For the second, that’s entirely the user’s choice. Your app can also allow them to associate a new email address for this purpose (which strikes me as exactly what you actually want since the real unstated motivation here is getting the user’s email). So the solution here is for a developer to add a bunch of code to their codebase on at least 4 platforms just to get to the same exact functionality and level of priv…
You need to support letting the user change their email address anyway. Letting them change it from the privacy forwarding email to something else is no different. And that shouldn’t even interfere with using Sign In With Apple going forward because surely you’re using the user’s unique identifier from Apple to associate the sign-in with your service’s user.
Also FWIW you can use the Sign In With Apple JS approach on non-Apple platforms. This is obviously useful for web, but Apple’s developer site says it’s “for web and apps on other platforms” so you could use this from Android too, it will just take some more work.
> As a user, I find that functionality to be incredibly clunky by comparison (on all platforms).
As a user, I have never connected with someone on a service by typing in their email address. Not only do people routinely have multiple email addresses (e.g. work and personal), but people also often use unique addresses for services (e.g. plus addresses), so it’s not at all a reliable mechanism.
> If I'm using a computer and I need to manually copy a link, open my email client, compose a new email, type the subject and a message, paste the link, and hit send
Why would you do all this? The service can offer a mailto: link that pre-fills the body, so all you have to do is click it, type in the recipient’s email address, and hit Send. And this lets you customize the message as appropriate. Better yet, on Apple platforms you can use the built-in share functionality, including on web with the Web Share API[1].
And if you really don’t want to do all of that, you could have me enter an email that you send a special link to rather than looking up in your user database. That’s still not great for me as a user because it means I’m giving you someone else’s email address, which I don’t want to do, but it’s better than nothing.
The simple fact is, if your sharing mechanism requires me to know the email address someone else has already used to sign up for your service, it’s a crappy sharing mechanism.
Earlier quoted context omitted.
For the first point, the app can explicitly tell the user what their login is, or otherwise assign some unique identifier the user can use when contacting support. The app can also offer to contact support for them, which can pre-fill the user identifier. For the second, that’s entirely the user’s choice. Your app can also allow them to associate a new email address for this purpose (which strikes me as exactly what…
And when you're using the web app on a desktop? There's no easy sharing mechanism there.
Earlier quoted context omitted.
My recollection is the first time I used Sign In With Apple it forced me to choose (no default), and after that it defaulted to my last choice. I expect 99% are obfuscating because that’s the sensible choice to make. Giving an app my real email should only be done if there’s an explicit need for this, such as being able to log in from non-Apple devices.
You make a good point, and in general I agree, but it introduces additional headaches if I think about logging in from a non-Apple device later.
https://developer.apple.com/documentation/sign_in_with_apple...
This is obviously the most useful for websites, but Apple’s developer site links to this with the descriptor “for web and apps on other platforms” so clearly they’re ok with Android apps using it too.
Earlier quoted context omitted.
It's not a mistake, by any means. It's dead clear that you don't work with consumers. Your technical bias shows what you care about and you're(an me) are an utter minority. If you want security, btw - you should have multiple passwords for different things. And ideally not even use a password manager.
Why should he not use a password manager?
What's the point in password manager, if all you need is one time auth - and you're in!
Earlier quoted context omitted.
My guess is that it's being send to the email the user registered with. And requiring them to provide a separate email from the one they registered with completely defeats the purpose of obfuscating the email in the first place, so I think it'd be unreasonable to ask a developer to implement a whole second place to put an email just to work around Apple denying access to that information in the first place. At the ve…
If I understand the model of the hypothetical app referenced above, they send email containing confidential (already, this seems problematic, but let's ignore that) "trip" information to some email address. Within that structure, then sure it's problematic to have to require two different email addresses. Except, you don't have to do that. Don't require an email address to start using the app. Let users enter whateve…
Earlier quoted context omitted.
My guess is that it's being send to the email the user registered with. And requiring them to provide a separate email from the one they registered with completely defeats the purpose of obfuscating the email in the first place, so I think it'd be unreasonable to ask a developer to implement a whole second place to put an email just to work around Apple denying access to that information in the first place. At the ve…
> My guess is that it's being send to the email the user registered with I assumed otherwise because they specifically wrote "sharing". Still, I'm not sure agree with: > requiring them to provide a separate email from the one they registered with completely defeats the purpose of obfuscating the email in the first place I can't use most apps without providing an email, whether they need it or not. That's a much worse…
But if you share a trip to a person who's on Tripit - they just get a notice and a record in their webapp.
Earlier quoted context omitted.
My gf googled a Mexican restaurant neither of us had been too on her phone and when we got in my truck literally 5 minutes later android auto maps on my phone suggested it as a destination. If they can do this, they can get your other email addresses.
Wait, why? If both of you have your location info turned on then this seems like a trivial correlation to make, especially since both of these are Google's own services.
Earlier quoted context omitted.
duh ! I blame my sleepiness for missing that. Still pretty meh that it is the only solution of its kind without an sdk
They don’t need an SDK if they’re using protocol-compliant OpenID Connect. Any OpenID Connect (or OAUTH2) library of the devs choice is the SDK. The Facebook/google SDKs are simply there to add trackers and bloat.