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