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