Hacker News new | ask | show | jobs
by reissbaker 816 days ago
That's not what the feature was. The feature was that you could use Messenger inside Netflix and Spotify to chat with your friends without leaving those apps. If you opted into using Messenger to chat with your friends inside Spotify, I'm confused why you think Spotify couldn't access your messages, given that Messenger was unencrypted at the time and you were running it inside Spotify. How else would the feature work? It's Messenger running inside Spotify; just like how iOS has access to the unencrypted files and network traffic of any app on your iPhone, Spotify could access any of the unencrypted files or network traffic in Spotify.

It's a dumb feature and I'm glad they killed it, but the "gotcha" here isn't much of a gotcha IMO. It was an opt-in feature to use Messenger inside these other apps; of course the other apps could see your messages if you opted into that. It's like complaining that GMail "shares your private email" with Apple Mail if you use Apple Mail as your mail client.

2 comments

The web was rampant with these patterns in the early 2010s when OAuth didn't exist, and HTTPS the exception rather than the rule.

The most egregious example was probably LinkedIn's GMail "integration," ostensibly used to invite your GMail contacts to LinkedIn. Back then, that sort of thing felt innocuous. But the implementation was even worse. Due to lack of OAuth and MFA, you literally entered your GMail password into LinkedIn. Then LinkedIn logged into your GMail account where they could do anything. Even if they limited it to scraping your contacts, they still got every email address you'd ever sent or received an email to or from, over the lifetime of the account.

In any other context this would be called phishing. And by the way, this pattern still exists. For example, apps that force you to log into a third party site in their embedded WebView can read the entire DOM (including your password). ..

Yeah definitely. There are still some pretty bad patterns out there; for example, if you try to add an event from Facebook Events to your Google Calendar, instead of generating a normal ICS file or event link, they... ask for read/write access to your entire Google Calendar account. No thanks!

Similar to apps that ask for access to your entire Contacts list to "find your existing friends"... You can bet they're uploading that entire thing to their servers and trying to growth hack with it.

Would be nice if APIs offered more granular permissions. Almost every one of these is global read/write so it’s impossible to distinguish between good and bad actors.
Think about the difference between accessing these specific messages, and accessing all messages.
If I give Apple Mail my credentials for my GMail account, I would expect Apple Mail to be able to access my email in my GMail account. Switching the word "email" to "DM" doesn't feel like a meaningful difference: if I'm using a third-party client to access and send messages, of course the third-party has access to my messages. Would I expect Tweetbot to be unable to access any tweets other than the ones sent from Tweetbot? That's... not a very useful third-party client. These were third-party Messenger clients; they had access to your Messenger DMs if you opted into using them.