[tsunamihippo]

The article skips a lot of context to make it sound significantly worse than reality. Facebook didn't just randomly give Netflix access to everyone's messages. Specific user would need to purposefully log in to the Netflix app with their Facebook account in order to grant Netflix access to the chat functionality (intended to send movie recommendations to Facebook friends inside the Netflix app).

https://about.fb.com/news/2018/12/facebooks-messaging-partne...

Disclaimer: I work at Facebook but not on messaging or anything related to this article.

[lupire]

And if a user consented to Netflix-based chat, Facebook overshared all chat data, instead of only the Netflix chat data, because they couldn't be bothered to build a properly isolated API?

That's like asking permission to read and write your entire phone, just to provide the ability to write and read back a file.

[rezonant]

This isn't how permissions work in most OAuth APIs. When you request permissions on apps like this, you request an "action" on a "subject". The "action" can be read/write/delete, the subject can be "DMs". How does Facebook determine whether a specific DM is a Netflix DM? In the database it's just a message from one user to another, with a certain text content.

By the way I'm not suggesting that it cant work this way, just that it doesn't. Facebook could have added a specific scope to allow an app to only read back messages related to itself. But that would have required anticipating the use case before these companies implemented it, or at least having better review policies to try to reduce the permissions apps are asking for.

But if the app wants to allow the user to have a back and forth with the other user, then that implies that Facebook Chat needs to have the ability to have app-specific conversation threads. It doesn't have that, though.

Netflix and Spotify requested read permission for DMs. Did they need it? Most assuredly they did not. But requesting read permissions for DMs in general has valid use cases, even if it should be treated sensitively by Facebook's authentication flow.

If there's any problem here, its that Facebook didn't seem to recognize that the apps (Netflix and Spotify) should not have been requesting read privileges at all, and should have revoked their ability to request that permission in a timely manner.

[slowmovintarget]

This is why OAuth is insufficient for privilege management, especially for multi-tenant systems, or what should be segregated data sets. You want to grant access to dataset abc123, but not dataset abc124 belonging to the same user.

This leads to an explosion of scopes, or an explosion of API keys, unless you have a policy engine, or resource-based access control. A company as big as Meta should be able to (is able to) do better than they did, but they probably didn't think this was worth prioritizing because money lie in attention farming, not in mending the fences.

[rezonant]

It's not just RBAC, the actual feature needs to be designed with this sort of use in mind. When it is, OAuth is perfectly capable of handling it. The ideal way to implement something like this is to expose the message in the Facebook Chat app as a "Netflix Chat", separate from your normal one on one conversation with a user. Then, any message in the Netflix chat is shared with Netflix so they can render it in their UI, but nothing else. Put a message under the Netflix logo in Facebook Chat that says "Netflix will be able to read messages in this chat"

The OAuth consent screen details for an app ("Netflix" and the Netflix logo, etc) could be used to present this to the user.

However this presupposes that this was ever a good idea. On desktop you have a Facebook tab you can chat from, and on mobile, you want to chat on the Facebook (or whatever) app so you have all of its normal features, instead of a gimped version stuck inside a third party app. The third party app only needs to be able to ask the user if its OK to send a message with specific content, and possibly be able to enumerate who it might send to, but even that we've weeded out into the OS' own Share dialog nowadays.

[abalone]

OAuth 2.0 is perfectly fine for privilege management. The problem is they granted read access when all Netflix needed here was write access.

An analogy would be granting full access to a Gmail inbox in order to merely send an email. It would not require “scope explosion” to isolate the email sending permission. That’s just one OAuth scope. They just didn’t isolate it.

The more interesting question here is how this interacts with supposed end-to-end encryption. Clearly the messages Netflix sends cannot be E2EE (right?). The whole point of E2EE is the service provider doesn’t have your keys. If Facebook is letting 3P send messages on your behalf, they must be unencrypted.

Normally, ideally, in an E2EE system this should set off alarm bells. If you get a message from someone that’s not actually signed/encrypted by them, this should be very clearly alerted. Otherwise it’s a privacy attack vector. You could be downgraded to an unencrypted channel without your awareness.

So, what’s the Facebook messenger user experience here?

[michaelt]

> The problem is they granted read access when all Netflix needed here was write access.

At that point, why not just have an URL that opens facebook with a message pre-populated and skip all the oauth?

[prox]

It’s also an already solved problem. Every contact could be like a channel (like in IRC) where you can gain access to (or not)

[btown]

Slack has a notion of private channels to which a bot can be added. Even a bot with full OAuth scopes can’t read private channels it hasn’t been granted access to. Of course, many people wouldn’t explicitly add the Netflix bot to their DM with their friend - but that’s exactly the point here.

OAuth is absolutely compatible with bots being treated as principals in a social graph, it’s just that that’s incompatible with the type of passive surveillance that was desired here.

[sebasvisser]

So when it comes to adding value for advertising fb is able to separate every object and data piece into sickening degrees of detail… but when it’s about privacy and authentication it’s “not the way things are done around here”… As you’ve mentioned as well it’s a choice by fb. Just as we have a choice to call fb out on making immoral choices. Better yet, the developer(s) that coded this part, and the developers that make a daily choice to maintain it in its current form.

And yes, it’s a choice. Just because people don’t take responsibility to make a deliberate choice, doesn’t mean it’s not a choice.

[londons_explore]

The engineers who worked on Chat at facebook likely had the same access... They had an employment contract which said that they were allowed to use their access to debug bugs and improve the product, but not to spy on their girlfriends DM's.

Netflix presumably had the same.

As long as that access is audited to ensure it really was being used only for the intended purpose, I'm fine with that.

Inspected 50 messages all from your test account: fine. Inspected messages from an account after that user contacted customer support citing a problem with messages: fine. Inspected messages from an account after that account fired off alerts to the devops team for causing segfaults: fine. Look at a random account: not fine. Dump messages from many accounts with a script: not fine, and rate limits should stop you after like 100 messages.

[toofy]

i’d question the “…couldn’t be bothered to build…” i’d be more likely to believe they knew exactly what they were sharing and wanted it that way.

[krisoft]

I don’t know. If there is a “Facebook Messenger” feature on some Netflix interface then I would be surprised if it only worked with some chats and not others.

(That being said I have no clue why there would be such a thing, and why a user would prefer it? Maybe if Netflix were making set-top boxes)

[Euphorbium]

That is how permissions work on android. I hate it.

[amelius]

That's why I moved to GrapheneOS.

[vlan0]

What incentive does FB have to limit that access? Feels like MBAs would just see that as a cost/burden? We know FB does give a fuck about privacy, so that’s never gonna be a reason.

[yen223]

If you believe FB is in the business of selling user data, then giving out user data for free is not an optimal move.

[vlan0]

Absolutely. So the question is, did FB view this through that lens? If they did, then maybe the ROI wasn't there. So they said fuck it.

[captn3m0]

Courts across the world fining them.

[pooper]

The fines have to be more than 100% of global annual revenue if they are going to matter.

The other option is long prison sentences for the board and CEO.

[exe34]

We often act as if corporations are unalignable super intelligences, but you're right, if there are consequences for the board/executive/shareholders, they would start caring.

[Wowfunhappy]

> That's like asking permission to read and write your entire phone, just to provide the ability to write and read back a file.

...it occurs to me that this is in fact how most desktop apps work, and I do prefer it that way.

[ornornor]

On windows idk but Unix has permissions for that reason.

[Dylan16807]

Normal Unix permissions do nothing here in a desktop context because the program is running under your account.

[Wowfunhappy]

There are permissions, but I think https://xkcd.com/1200/ is relevant here.

[some1else]

Note that everyone had access to the Inbox API at the time. We made an art project highlighting the invasiveness of such broad access:

"E-dentity is a project that asks a participant to login to its Facebook account, then takes his/ her private data from their profile and automatically prints them in an understandable booklet that is handed to the user. This booklet seeks to raise awareness of the hidden data we are sharing which we are often not aware of."

https://github.com/some1else/Edentity

[YeBanKo]

Thanks for the context, it's important. But from the link you posted:

  > In order for you to write a message to a Facebook friend from within Spotify, for instance, we needed to give Spotify “write access.” For you to be able to read messages back, we needed Spotify to have “read access.” “Delete access” meant that if you deleted a message from within Spotify, it would also delete from Facebook. No third party was reading your private messages, or writing messages to your friends without your permission.

So here Facebook acknowledges that an app that sends messages needs write permission, not read. I would assume that sending a recommendation is a write only thing, especially with something private as direct messages. And it is pretty well understand pattern. When you share something through iMessages, Signal or WhatsApp from the a different app, the app does not get an access to you chat history.

The allegation that Arstechnica are pretty sever:

  > By 2013, Netflix had begun entering into a series of “Facebook Extended API” agreements, including a so-called “Inbox API” agreement that allowed Netflix programmatic access to Facebook’s users' private message inboxes

Strange naming "Inbox" for sharing API.

  > in exchange for which Netflix would “provide to FB a written report every two weeks that shows daily counts of recommendation sends and recipient clicks by interface, initiation surface, and/or implementation variant (e.g., Facebook vs. non-Facebook recommendation recipients).

This is something that Netflix could do even without special access to the messages, since links originate from them. But so could Facebook, since they see the traffic in messages and can identify referral links. Looks like Titan API, whatever it is, gave even more access?

NYTimes article from 2018 [1] has more details, but it is still unclear if user consent was explicitly obtained for Netflix to read messages. But an interesting quote from Steve Satterfield, Facebook’s director of privacy and public policy:

  > With most of the partnerships, Mr. Satterfield said, the F.T.C. agreement did not require the social network to secure users’ consent before sharing data because Facebook considered the partners extensions of itself — service providers that allowed users to interact with their Facebook friends.

A rather conspicuous statement by someone who have properly collected consent from users.

[1] https://archive.is/DH17k

[rezonant]

> So here Facebook acknowledges that an app that sends messages needs write permission, not read.

I guess the feature at issue here is that you could actually hold a conversation with a Facebook friend inside of Netflix or Spotify which does indeed necessitate the ability to read back messages from the other user.

Whether it was wise to allow that instead of the kind of sharing systems we use today in 2024 is another question.

[YeBanKo]

Depending on the OS architecture it might be possible to have an SDK render messages without handing any data to the parent app. Or of it's not possible at least the question is where any of the messages even hit Netflix servers.

[choppaface]

> Disclaimer: I work at Facebook but not on messaging or anything related to this article

Same as "Hey, Googler here. Let me tell you how I'm right and why you should think this way."

> Facebook didn't just randomly give Netflix access to everyone's messages.

That's not at all what the title alleges, nor what the article says. The article (1) provides evidence that Facebook monetized user private messages in a data-sharing project with Netflix and (2) cites court documents that litigate Facebook having Jedi-Blue-like monopoly-preserving interaction with Netflix.

It doesn't matter what the Facebook TOS says or how the tech works. Human users never provided informed consent that their private comms would be monetized as well as used for anti-competitive un-American purposes (un-American as in the Sherman Act, altho creating a monopoly is perhaps very American indeed). And Facebook has done that time and time again.

[ionwake]

I only read the headline and this reply gave me even greater concern. wtf they shared ALL msg data for logging into Netflix chat?!?

I dunno I’m surprised I’m still surprised these days

[notnmeyer]

so you agree then that “private” messages aren’t private on fb? i don’t know how to interpret this in a way that isn’t terrible for fb users…

[airtonix]

not if you log in to enable and agree to share such messages. no.

[scarface_74]

If you give access to your chat as the parent poster claims, why are you surprised that Netflix has access?

[hipadev23]

Because it’s not a reasonable expectation that your private messages would be shared with an advertising partner when you link your account to it, and “give access” is rarely a step that your average user actually reads, much like agreeing to TOS’s upon signup.

And catering to the average user’s expectation is what should dictate policy, not a “technically we have permission” caveat.

[vel0city]

> would be shared with an advertising partner

In this case Netflix was not an advertising partner. You were signing into Facebook Chat inside the Netflix chat, and participating in Facebook chat messages inside the Netflix app.

You were opting in and using the Netflix app as a Facebook Chat client. Its like being surprised the Pidgin executable could see your Jabber messages.

[rezonant]

In the sense that some users may not have realized what they were allowing, that's fair. But that just implies that the permission dialog for this sort of thing should be pretty onerous while being very easy to understand.

There are details that aren't clear here too: Did Netflix request read permissions when you signed in via Facebook? If so, that's shitty and is worthy of condemnation, but the onus falls more on Netflix than Facebook there. You should be able to sign in with Facebook without expecting your DMs to be sent to Netflix. It's still on Facebook, but to a much lesser extent: They should make what's being shared super clear when you sign in with Facebook, and that includes making the sign in super onerous and scary if its something like reading DMs, so the user doesn't miss these details. And they should be reviewing third party apps and what permissions they request, and making sure its inline with the functionality the app is presenting.

However, if the normal Facebook authentication flow did not grant this permission, and the permission was only granted when the user accessed the "Netflix Chat" or whatever feature which obviously did, in actuality, require the read permission to function, then this isn't that big a deal.

[bluefirebrand]

You would expect that giving permission to send specific pre-approved messages does not imply permission to read everything you've ever said to anyone or they've said to you..

Right?

[reissbaker]

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.

[chatmasta]

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). ..

[reissbaker]

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.

[lupire]

Think about the difference between accessing these specific messages, and accessing all messages.

[reissbaker]

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.

[notnmeyer]

it’s disingenuous to think that users read and fully understand the various permission scopes of a service. “private” has an unambiguous meaning—playing the “well, technically” card falls pretty flat imo.

[scarface_74]

When you give your mail client credentials to read your email , would you not expect your client to be able to read your mail?

On Android, when you give a third party client permission to receive SMS, you don’t expect it to have access to your SMS?

[SoDmbIHadToRply]

So when I give thunderbird my email details, someone at thunderbird gets access to all my emails ?

[rezonant]

If Thunderbird had a hosted web version, yes. Are you arguing that data portability and interoperability should never be possible if the receiving app is an online service?

Of course Thunderbird could send an automatic update that starts shipping your emails to Thunderbird's servers. You dont expect that, but only because you trust them.

[sashank_1509]

unless I’m wrong thunderbird software has complete access to all your emails when you give thunderbird your email details. Of course, that does not imply that a specific thunderbird employee can read your emails, it is probably encrypted on that end but if they pull a switcheroo and download all your emails into an AWS instance, yes that might be possible (and probably wildly illegal too)

[k8svet]

So... this sounds like OAuth, with a nice consent scene that says I'm giving Netflix this access to my FB DNs. That's what you mean, right? Otherwise, what the fuck is the difference?.

And really, as if this makes anything better, wow. Imagine having the feeling of obligation that you have to stick your neck out over this. Just take your over-sized salary and be happy knowing you work for one of the worst companies of our time. (despite my tone, at this point, I honestly say that without judgement, just ... own it.)

[aardvarkr]

When you give your mail client credentials to read your email , would you not expect your client to be able to read your mail?

On Android, when you give a third party client permission to receive SMS, you don’t expect it to have access to your SMS?

[navigate8310]

Totally agree with the sentiment here. The comment by the employee make it sound like it's the user's fault. Something akin to dark pattern and malicious compliance by giving the user an OAuth consent for their DM.

[rezonant]

It's only a dark pattern if this was the permission Netflix asked for when you hit "Sign in with Facebook" or some other unrelated feature. If the permission was granted when you tried to use Netflix Chat, a bidirectional in-app chat powered by Facebook, then its not a dark pattern at all, its just the usual way things are done.

[k8svet]

Lmao, love seeing what HN decides is controversial these days.

God give me the power of some of y'all's utterly depraved self-serving self-delusion. I at least acknowledge the moral compromise of how my labor accrues in the system instead of burying my god damn head in the sand about it and offering poor incoherent defenses of my employee in public. And I make a third of what I could make at FB, and still probably don't contribute as negatively to the world.

[lesuorac]

> Disclaimer: I work at Facebook but not on messaging or anything related to this article.

So, it could work exactly as it sounds and you'd have no idea?

---

Although I'm not sure the complaint [1] (linked from articled) actually says that messages were given.

[1]: https://cdn.arstechnica.net/wp-content/uploads/2024/03/compl...

[trolan]

Yes I think they're giving their general nerd opinion while also being transparent about possible conflicts. Their comment reads like an analysis of the article not the technology.

[cm2012]

If this wasn't Facebook it wouldn't even be news.

[soraminazuki]

I hope you’re being sarcastic? Or is that actually your stance on people’s privacy rights?

[AnotherGoodName]

Google docs literally has the exact same feature and we're not even talking about it. Using the exact same OAuth framework as here you can grant Netflix and Spotify the right to read everything and all comments in your Google Docs. You can even grant them the right to read all your emails in Gmail!

In all seriousness i believe anyone providing oauth should just shut it down at this point, Cambridge Analytica was entirely users granting a third party oauth access to read their friends lists with an explicit permission dialog and all and it was a scandal that led to massive fines. The world decided that oauth access is not ok even with the dialogs prompting to allow third party access and at this point we as developers should listen and take it away. Google currently flys under the radar with the exact same access that led to cambridge analytica but they should probably just shut it down unless they want to run the risk of similar court cases.

[tety]

In order to write something that reads user emails in Google APIs you have to go through multiple levels of hell, so I don't think that's a fair comparison

[AnotherGoodName]

It seems you have to do that here too though. In the end you have to deal with the headline the media can write about it.

If Netflix and Spotify went through the vetting process for the purposes of enabling an in-app email client the media could write pretty much the same headline.

[tety]

Google has strict licensing for what you can do with such data (almost nothing) and you have to go through an extreme vetting process

However, this won't generate the same headline because any company can go through it, and it isn't some API sold for some special privileged company. Also the user knows it is sharing their mails (not sure if that's the case with facebook)

[rezonant]

Boiling it down here... some users hit the "Yes" button when Facebook asked them if it was OK to allow Netflix to access their DMs for a feature that allowed you to chat (bidirectionally) with your friends inside the Netflix app. That's a privacy violation?

[kazinator]

Rather, it seems like cynicism about the media, than a stance on rights.

[rvba]

Lots of comments here look like some sort of astroturfing made by a PR agency

[robocat]

"Please don't post insinuations about astroturfing, shilling, brigading, foreign agents, and the like. It degrades discussion and is usually mistaken. If you're worried about abuse, email [e-mail] and we'll look at the data." - https://news.ycombinator.com/newsguidelines.html

[choppaface]

The root comment is literally a Facebook employee who is intentionally trying to change the narrative. An employee of a company that has been fined billions for privacy breaches, that was responsible for literal voter suppression https://www.opendemocracy.net/en/dark-money-investigations/t... etc etc

HN "guidelines" say "Please don't post shallow dismissals" -- Don't allow FANG to astroturf these forums.

[valicord]

Are you suggesting that people working at companies you don't like should be banned from HN simply because of who their employer is, or that they should not be allowed to reveal conflict of interest when discussing topics related to their employer?

[saagarjha]

Your concern is exactly what the guidelines are talking about.

[cm2012]

I've been on HN since 2007 man.