Change 456305 had a related patch set uploaded (by Rxy; owner: Rxy):
[mediawiki/core@master] Add suppress related permissions to $wgGrantPermissionGroups

https://gerrit.wikimedia.org/r/456305

Change 456651 had a related patch set uploaded (by Rxy; owner: Rxy):
[mediawiki/core@master] Add suppress related permissions to $wgGrantPermissionGroups

https://gerrit.wikimedia.org/r/456651

Change 456651 abandoned by Rxy:
Add suppress related permissions to $wgGrantPermissionGroups

https://gerrit.wikimedia.org/r/456651

Change 460727 had a related patch set uploaded (by Rxy; owner: Rxy):
[mediawiki/core@master] Add suppress related permissions to $wgGrantPermissionGroups

https://gerrit.wikimedia.org/r/460727

Change 460727 abandoned by Rxy:
Add suppress related permissions to $wgGrantPermissionGroups

https://gerrit.wikimedia.org/r/460727

Change 460728 had a related patch set uploaded (by Rxy; owner: Rxy):
[mediawiki/core@master] Add suppress related permissions to $wgGrantPermissionGroups

https://gerrit.wikimedia.org/r/460728

Change 460728 abandoned by Rxy:
Add suppress related permissions to $wgGrantPermissionGroups

https://gerrit.wikimedia.org/r/460728

Can someone from Legal and/or security check if there are any legal/privacy concerns about this? (E.g., enforcement concerns of Access to nonpublic information policy.) A web application with this grant could show an authorization dialog with potentially misleading description / a suppress grant that's hard to spot in the list of all grants, and if an oversighter carelessly clicks it through without realizing what grants are given, the application would then have access to nonpublic information as it pleases.

(Note that suppress would not be the first grant that gives access to nonpublic information - CheckUser already provides a grant.)

Presumably this kind of thing should be prevented by OAuth admins vetting such consumers, but then it would be nice to have some guidelines on what the vetting requirements should be.
(A simple approach could be that such consumers are never accepted. That would still allow people to use the grant with bot passwords / owner-only OAuth consumers for their own bots.)

Is this still desired / has it been approved by Trust&Safety to implement?

I'm sorry, but I don't really follow this task. What exactly is a "grant"? Just something that provides access to this information?

See https://www.mediawiki.org/wiki/Manual:$wgGrantPermissions and https://www.mediawiki.org/wiki/Manual:User_rights#Adding_new_rights

I have no idea why T&S would be asked instead of Security.

Currently it is not possible for clients using OAuth to access actions/information protected by the 'hideuser', 'suppressrevision', 'viewsuppressed', and 'suppressionlog' user rights. In other words, it's not possible for someone to write a tool to do Oversight stuff.

This task is asking to make it possible for such a tool to request access to those rights (a "grant"). Note the grant does not actually give any rights to a user of the tool, it just lets the tool take advantage of rights the user already has.

The potential risk would be someone writing a somehow-malicious tool and convincing oversighters to use it. On the other hand, someone could instead write a malicious tool without using OAuth and convince oversighters to use that instead.

I think it's worth T&S knowing about this, but yes, Security is a much more technically-minded team who would be better placed to actually work on this.

This is a trivial change, just needs approval (IMO more legal/security than T&S). And possibly some guidance around when applications with access to that right should be allowed.

Some thoughts:

• In general, I don't feel making such grants available is too risky since, as mentioned, we already allow some privileged rights via the API and while it would be instinctual for a security-conscious individual to want to limit these rights as much as possible, usability of the API must also be considered.

In T203129#5488782, @Anomie wrote:

The potential risk would be someone writing a somehow-malicious tool and convincing oversighters to use it.

• Indeed, though I'd hope this would be prevented during the OAuth consumer proposal phase. And further mitigated by the very hopeful assumption that individuals with oversight rights are at least somewhat less susceptible than the average user to social-engineering attacks.

I can bring this up for discussion at the Security-Team's weekly meeting, but for now I'd personally rate this proposal as low to medium risk.