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