The difference is that a screenshot may be fake. If the intermediary is revealing user private messages, it’s a stronger evidence than just making up a photoshopped screenshot.
I imagine that the API-based uploads of the recent decrypts from the user being reported can also be faked, so I'm not sure that this is a very important distinction.
Assuming whatsapp uses the same message franking mechanism Facebook's encrypted chats use, no. Ciphertexts are authenticated so that the contents of them can be verified using a key held on Facebooks servers (and crucially that key allows you to forge those transcripts, so someone can't use the stolen key to publicly confirm the contents of someone's messages as with DKIM). See https://eprint.iacr.org/2019/016
There is some difference in the skill level required to convincingly craft a fake screenshot versus to spoof an API request, but yeah, it's not a huge difference.
The fact that it's an API request will make it easier to create checks. For example, they could check if the length of the messages match with the length of the encrypted ciphertext the server sent. In theory you can do with this a screenshot already, by redigitizing the content, but it's harder. Or they could check whether the received/sent/etc dates match with what the servers recorded, etc.
> I imagine that the API-based uploads of the recent decrypts from the user being reported can also be faked, so I'm not sure that this is a very important distinction.
That assumes that the decrypted messages aren't signed (e.g. via HMAC), no?
End-to-end MACs don't help because the recipient knows the key and thus can generate a valid MAC on a fake message.
But there are plenty of other ways to implement this. Digital signatures. Or if facebook stores the ciphertext, the recipient could simply reveal the decryption key for the message. Or facebook could compute a MAC over the ciphertext with a key neither participant knows, then the recipient could reveal the ciphertext and decryption key, and facebook could verify the outer MAC to verify authenticity.
I somehow don't think FB's world class engineers would fall for the cryptographic doom principle, so this would imply MAC-then-Encrypt-then-MAC, no? :D
While there is certainly a MAC using a key shared between sender and receiver using either an integrated authenticated encryption algorithm or encrypt-then-MAC this key will be known to the recipient and is thus useless for proving authenticity to a third party. But facebook could add an additional MAC using a key only known to them over the already authenticated ciphertext.
It can all be faked with a lot of effort, but proving it's an effort beyond F12 is just a refresh. But if you're going to such extremes you wouldn't trust server data/logs at all either, you don't know if they've been manipulated or not. You wouldn't trust anything, so the whole thing itself doesn't matter unless you had them say it directly to you.