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.
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.
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.
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?
At that point, why not just have an URL that opens facebook with a message pre-populated and skip all the oauth?
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.
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.
The other option is long prison sentences for the board and CEO.
...it occurs to me that this is in fact how most desktop apps work, and I do prefer it that way.
(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)
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.
That's like asking permission to read and write your entire phone, just to provide the ability to write and read back a file.