@Tgr Thanks for letting us know about this! It was my understanding that although the client has the editprotected grant, it wouldn't be able to edit protected pages unless the user interacting with the client also had those permissions. For example, my client with the editprotected grant wouldn't be able to edit the main page on English Wikipedia because my user doesn't have those permissions. Is this accurate?

I'm happy to remove editprotected and apply only createeditmovepage if that's more appropriate.

That is accurate, but users of an app have no control over what the app does. So at best, users who do have admin or similar rights on the wiki would have to avoid using the app out of concern that their access to protected pages gets abused, and so they would get excluded from the userbase for no good reason. At worst, they wouldn't be so conscientious and then a malicious or stolen app would be able to edit protected pages in their name.
(In the case of personal API keys, instead of using an untrusted app, the scenario would be uploading your keys to an untrusted server.)

createeditmovepage is already included. The other "low-risk" grants are highvolume, uploadfile and uploadeditmovefile (although the last two aren't really related to editing pages so including them under such a name would be confusing). For everything else, developers should make an explicit choice to include it if they want it, and the default should be to not include it (and if they do include it, the request will probably get rejected unless there is some measure of transparency - we know who they are, or the app is opensource, or the server is owned by a reputable organization, etc).

The other "low-risk" grants are highvolume, uploadfile and uploadeditmovefile

patrol too, I suppose.

Change 717613 had a related patch set uploaded (by Alex Paskulin; author: Alex Paskulin):

[mediawiki/extensions/WikimediaApiPortalOAuth@master] scopes: Split out editprotected

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

I don't disagree with anything said above. For any readers that don't want to dig into gerrit, the proposed patch adds a separate option.

I'll add that the whole point of the API Portal form is to be simplified, and that we expect people who need more granular control over permissions to use the form on meta. If we find that we need to add too many choices to the API Portal form, we risk losing that benefit and may need to reconsider our goals, or at least our approach to solving them.

This change, however, seems fine, and the preceding paragraph is forward-looking. Trying out the patch now.

Change 717613 merged by jenkins-bot:

[mediawiki/extensions/WikimediaApiPortalOAuth@master] scopes: Split out editprotected

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

In T290350#7342277, @BPirkle wrote:

I'll add that the whole point of the API Portal form is to be simplified, and that we expect people who need more granular control over permissions to use the form on meta. If we find that we need to add too many choices to the API Portal form, we risk losing that benefit and may need to reconsider our goals, or at least our approach to solving them.

I can certainly see the value in that, and I think it makes sense to bundle low-risk grants, but in the end we want the end user to understand what risks they take by granting access to an app, and end users will distrust apps which request permissions which they don't seem to need. On average, the app developer will probably be better off if privileged users can't edit protected pages with the app in the rare cases where they could than with privileged users not granting access because the app asks for suspicious permissions which it actually wouldn't use. (Note also that wikis tend to have various rules about what edits are appropriate to a protected page; the normal editing interface gives you prominent warnings when editing a protected page, even if you do have the right to edit it, so an app that edits protected pages without having custom UX or business rules for them might end up causing problems.) If you want to keep the portal interface simple, I'd just remove the page protection option entirely.

In the longer term, maybe a separate simple and advanced interface would make sense? That's something I'd like to do for the OAuth extension's interface as well. I think grants roughly fall into four groups:

• not risky: permissions which most users have anyway - edit, move, upload, patrol etc
• vandalism risk: permissions which typically require admin or similar access, and can be used to cause havoc but not for anything truly damaging - deletion, blocking, page protection, editing protected pages
• security or privacy risk: permissions which require higher-than-admin access, and can do serious damage - JS editing, checkuser, oversight
• internal: permissions which are too risky to hand out to anyone and are only used in Wikimedia production infrastructure

These should probably be managed in MediaWiki core and in extension definition files, similar to how $wgGrantPermissionGroups is handled. For a simplified user interface all non-risky permissions could maybe be bundled into a concept of "write access". Grants with a security or privacy risk should be handled with maximum granularity. Grants in the vandalism risk group are more borderline; I'd err on the side of granularity, but one could argue that if they are sufficiently low-risk to be bundled on the user group level, it's OK to do it on the grants level as well. I'd definitely separate them from the non-risky group at least, since most apps won't need them (and as mentioned above if you do need them, you should probably take your time to think how your app's UX needs to be changed, even for permissions which just extend another permission, such as editing protected pages or viewing deleted pages).