I did some experiments on my test wiki and found that with editcontentmodel enabled for all users, I still was not able to make changes to another user's vector.js. In this screenshot I, as generic user Gimp2, tried to change the content model of Gimp's vector.js page. MediaWiki rightfully did not allow it.

Okay, all blockers resolved! I'm going to submit a patch to core to grant editcontentmodel to 'user' (equivalent to 'move'). And then a patch to wmf-config which grants 'editcontentmodel' to wikis at the same level they've granted move, to keep the permissions on basically equal settings. Individual wikis would be able to further request configuration changes to adjust if necessary. Once the core patch is merged and we have a date for deployment, I'll send out an announcement to wikitech-ambassadors.

Change 309061 had a related patch set uploaded (by Legoktm):
Grant 'editcontentmodel' permission to 'user' group

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

Change 309061 merged by jenkins-bot:
Grant 'editcontentmodel' permission to 'user' group

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

Change 309066 had a related patch set uploaded (by Legoktm):
Match 'editcontentmodel' permission with 'move'

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

I'm a bit concerned about this access for projects that don't have some special Flow related requirement (actually most projects - special flow things should have their own utility). editcontentmodel users are able to "break" pages such as encyclopedia articles from being accessed by readers. Such a break can not be reverted by logged out users, and would require another user to have knowledge of the contentmodel change utility to restore such an article.

I understand the utility for letting (massmessage) holders use this - and suggest that it is deployed to (massmessage) holding groups instead of (move) holding groups by default. (Any of course any project could request it be included in any group as per most permissions).

Thoughts?

@Legoktm ping to you regarding my above comment - please let me know if I'm missing some part of the "big picture". Us enwiki people can discuss and request a project specific update if there is a consensus against this there.

In T85847#2618026, @Xaosflux wrote:

I'm a bit concerned about this access for projects that don't have some special Flow related requirement (actually most projects - special flow things should have their own utility). editcontentmodel users are able to "break" pages such as encyclopedia articles from being accessed by readers. Such a break can not be reverted by logged out users, and would require another user to have knowledge of the contentmodel change utility to restore such an article.

I understand the utility for letting (massmessage) holders use this - and suggest that it is deployed to (massmessage) holding groups instead of (move) holding groups by default. (Any of course any project could request it be included in any group as per most permissions).

Thoughts?

The reason Flow has a separate system is because of this bug actually - editcontentmodel wasn't granted to enough people to make it obey the permission system. MassMessage didn't have enough development resources to implement a totally separate system, so it is kind of crippled until this bug is finally fixed. And in the future I know at least CollaborationKit (for WikiProjects) plans to take advantage of this functionality by providing structured content models on normally namespaced pages.

Like any new feature, there's always room for people to abuse it. We are widening the amount of users who can convert pages (to autoconfirmed on enwp), but it's also increasing the number of people who can revert malicious changes. I've long stated that conceptually this is equal to the 'move' permission, and I think

sorry, hit submit too early.

...I've long stated that conceptually this is equal to the 'move' permission, and I think, we've done a good job in keeping it mostly the same. Similar permission level granting, special page to make and undo changes, convenient revert link in summaries, API ability, etc. The only thing not there is a link in the UI to make the change (move has a tab, this has nothing). But not exposing it in the UI is a conscious choice because most users should really never have to use it. But we don't want to enforce that technically with permissions.

And I just realized we didn't have rate limits for this, so submitted a patch for that: https://gerrit.wikimedia.org/r/309224

So making "undo" work for these will not be enabled until the permission is changed?

Here are examples:

https://test2.wikipedia.org/w/index.php?title=Law2&action=history
https://en.wikipedia.org/w/index.php?title=User:Xaosflux/Test1&action=history

Click undo - does not work, instead errors out.

I thought we had fixed that in T73163, but apparently not. Filed T145044: Clicking undo on an edit that changed the content model results in a MWException, thanks.

https://en.wikipedia.org/wiki/Wikipedia:Village_pump_(proposals)#restrict_changecontentmodel_permission
has been created to discuss if this is something that the English Wikipedia will want to restrict to less users

+Consensus needed tag; this is under discussion on enwiki - and we should not assume that all other projects need to have most users altering content models for pages.

I'm not convinced, per above, that rolling this right on WMF wikis to all
users or even autoconfirmed users is a good idea. This right is for a very
specific work.

This task should be declined. It is just pointless disruption to let zero-rights-users screw with the content model of random pages. Utilizing massmessage requires advanced permissions to send out the messages anyway. Obviously someone with advanced permissions can handle the rare and trivial creation of the page in the first place.

In T85847#2622611, @Alsee wrote:

This task should be declined. It is just pointless disruption to let zero-rights-users screw with the content model of random pages. Utilizing massmessage requires advanced permissions to send out the messages anyway. Obviously someone with advanced permissions can handle the rare and trivial creation of the page in the first place.

I'm more than happy to engage with people over this issue, but I ask that you actually read what's been said here (and other places, sorry the discussion is so fragmented) - because your statements make it clear that you haven't. If you're going to make statements like "pointless disruption" or "rare and trivial creation", you need to back them up with facts. Because as I've stated here and elsewhere, it's not pointless, nor is rare.

In T85847#2621417, @MarcoAurelio wrote:

This right is for a very specific work.

I don't follow how that is an argument to not grant this right to a wider set of users. For example, the "transcode-reset" right is granted to autoconfirmed users - wouldn't you say that is needed only for very specific set of work?

With the difference that transcode-reset does not disrupt pages. This does, and it's not okay. This is for a very specific work that massmessage-senders and sysops can perform. Others do not need this, so there's no point on adding a right that will have no use for them and that has room for abuse.

In T85847#2625371, @MarcoAurelio wrote:

This is for a very specific work that massmessage-senders and sysops can perform. Others do not need this, so there's no point on adding a right that will have no use for them and that has room for abuse.

It is currently true that it is really only useful for mass message senders, but this will not be true in the long term as new features come out that involve custom content models. (An extension I am working on, CollaborationKit, is one such example of that.)

That considered I personally am open to the idea of restricting arbitrary content changes while allowing people to create non-default content model pages through pre-specified workflows.

In T85847#2625371, @MarcoAurelio wrote:

With the difference that transcode-reset does not disrupt pages. This does, and it's not okay. This is for a very specific work that massmessage-senders and sysops can perform. Others do not need this, so there's no point on adding a right that will have no use for them and that has room for abuse.

We should empower users to be bold. :-) I favor as liberal permissions as possible in nearly all cases as I think that's the wiki way. In the case of editing a content model, it should not be any more disruptive than moving/renaming a page.

In T85847#2626070, @MZMcBride wrote:

We should empower users to be bold. :-) I favor as liberal permissions as possible in nearly all cases as I think that's the wiki way. In the case of editing a content model, it should not be any more disruptive than moving/renaming a page.

Yup, the wiki way is wonderful. Classically speaking:

1. User A makes change X
2. User B sees change X, quickly evaluates its merit, and can enhance it (or undo it)

There's a symmetry of power in the wiki way. Both "A" and "B" are equally powerful to make the change, so "A" can be bold.

The wiki way ends up breaking when it's possible for user "A" to make changes that user "B" doesn't notice, doesn't understand, or has to work harder than user "A" to undo.

@Legoktm and @andymw, thanks for making sure that we note the blockers for opening up wider access (T145316, T145344, T145489). The discussion on those subtasks (mainly T145344 as of this writing) is educational.

Putting a note here that at least on enwiki, changing the content model of a userjs page away from js can open it up for public editing. See last discussion on https://en.wikipedia.org/w/index.php?title=Wikipedia:Administrators%27_noticeboard&oldid=757400754

Judging by this task still being open, I take it this hasn't happened yet?

Seems like. Also, the concern I noted before about this privilege allowing one to potentially sidestep editing restrictions on user CSS/JS pages needs to be resolved.

It seems like there are some legitimate cases for this (such as Flow talk pages, although Flow is not used quite enough to have WMF-wide decision made based specifically on it) and there are some possibilities that this can prove pretty pointless and maybe even harmful. For example, what is the case for having content model changes available in the main space? That just seems like a possible abuse tool for making pages render badly for some time.

If such a possibility is really needed, then it should be split off into additional settings on different types of content models. The permanent ability to turn an article into a JavaScript page is not a needed one.

In T85847#2618178, @Xaosflux wrote:

https://en.wikipedia.org/wiki/Wikipedia:Village_pump_(proposals)#restrict_changecontentmodel_permission
has been created to discuss if this is something that the English Wikipedia will want to restrict to less users

FYI, the discussion Xaosflux was pointing to is now found at:
https://en.wikipedia.org/wiki/Wikipedia:Village_pump_(proposals)/Archive_134#restrict_editcontentmodel_permission

(This is probably not needed anymore, but it took me so long to find where this VP discussion was archived [a search of "all village pumps & archives" didn't find it, for some reason], I figured I'd post it here.)

But is that still happening? If so it's a real blocker IMHO.

Edit: I'm refering to T85847#2959070.

I suggest this task be closed. If necessary any current use cases can be addressed in a more narrow fashion. Per Harej, a non-default model might be created via workflow rather than modifying an existing page, or we could narrowly allow swapping Talk pages between wikitext and Flow, or admins can grant a permission by-need-and-approval (like TemplateEditor).

Anything that interacts with javascript, even indirectly, always requires the most strict scrutiny. The initially-overlooked issue of other users' js pages is bad. It's dubious why we would offer general users an option to change the model of mainspace articles, even if it is easily revertible. And we shouldn't impose a preemptive result regarding future content models. Use of content models should develop further before we consider whether generic model changing can&should be a common and appropriate activity for untrused users.

In T85847#4526245, @MarcoAurelio wrote:

But is that still happening? If so it's a real blocker IMHO.

Edit: I'm refering to T85847#2959070.

I think the current status post https://gerrit.wikimedia.org/r/c/mediawiki/core/+/309815 (I haven't tested this recently) is that only people who can currently 'edit' the page and 'editcontentmodel' the page can turn it into a not-CSS/JS page. At that point it is publicly editable, but ResourceLoader will just ignore it and won't load it. And to convert it back to CSS/JS, you'd need to be able to edit the page under it's new content model, which means only sysops/interfaceadmin and the user themselves could convert it.

In T85847#4527133, @Alsee wrote:

I suggest this task be closed. If necessary any current use cases can be addressed in a more narrow fashion. Per Harej, a non-default model might be created via workflow rather than modifying an existing page, or we could narrowly allow swapping Talk pages between wikitext and Flow, or admins can grant a permission by-need-and-approval (like TemplateEditor).

I'd like to continue to go forward with this, and I think this line of argumentation was addressed in T85847#2626070 and T85847#2632672.

Anything that interacts with javascript, even indirectly, always requires the most strict scrutiny. The initially-overlooked issue of other users' js pages is bad.

I believe the JavaScript/CSS issues have already been fixed, but it's been a while since I looked into this.

It's dubious why we would offer general users an option to change the model of mainspace articles, even if it is easily revertible.

I think what you're asking for is T145174: Perhaps should have a notion of titles that must use default content model.

And we shouldn't impose a preemptive result regarding future content models. Use of content models should develop further before we consider whether generic model changing can&should be a common and appropriate activity for untrused users.

The default wiki permission model works in such a way that users are generally trusted first (AGF, etc.) and then lose trust. IMO the content model system has been crippled since it's always been tied to namespaces instead of being freely changeable. which is why I'm pushing for this change.

We should really get this done, now that TemplateStyles is deployed and it's on user level by default. It's really annoying to rely on an admin any time you want to create new template styles or change the content model of a page in your userspace. There is no reason to keep this from autoconfirmed users, especially not from security perspective. It's not really a new thing that you can vandalize wiki pages by creative means.

If it will be done, is there a way to avoid contentmodel change from something to sanitized css, using abusefilter?

Seems like a nice to have feature to me, but you can just change it back if abused? Changing content models is even easier to revert than page moves (because of the redirects).

In T85847#4586773, @MGChecker wrote:

Seems like a nice to have feature to me, but you can just change it back if abused? Changing content models is even easier to revert than page moves (because of the redirects).

No, I can't. Our community decided to allow templarestyles editing to autopatrolled users only. Ruwiki community (@Jack_who_built_the_house, pay attention) decided to allow this to engineers group or to admins. Both of us asked phabricator changes, and the tasks were declined because it can be done using abusefilter, without a need to watch the pages, or to change it back manually. If it can't any more, it's a problem. Thank you.

This shouldn't be blocking using templatestyles, when creating a new template style (e.g. https://test.wikipedia.org/wiki/Template:389573/styles.css) is is already in the correct content model.

I'm not following why developers would be refusing to allow access to communities that have specifically reviewed and requested access for certain groups though? Do you have the phab numbers to review?

Sometimes page moves and similar actions change the content model of TemplateStyles pages to wikitext, and currently you're unable to change it back without asking a sysop, which can be kind of annoying.

If a few communities changed their permissions like that, they can decide to reduce the availability of this permission. However, I personally don't get it why template styles should have more protections then the associated templates themselves…

In T85847#4587104, @Xaosflux wrote:

This shouldn't be blocking using templatestyles, when creating a new template style (e.g. https://test.wikipedia.org/wiki/Template:389573/styles.css) is is already in the correct content model.

Sorry, I do not understand how can it help.

I'm not following why developers would be refusing to allow access to communities that have specifically reviewed and requested access for certain groups though? Do you have the phab numbers to review?

Of course, here you are: T188287, T187729. And also https://he.wikipedia.org/wiki/Special:AbuseFilter/90 and https://ru.wikipedia.org/wiki/Special:AbuseFilter/168.

@IKhitron ok, I must have misunderstood you , I though you wanted to allow an existing group to use the 'editcontentmodel' right and were denied.

In /309066, @Legoktm wrote:

The 'editcontentmodel' permission is conceptually equal status to 'move', so grant it to all groups that have 'move' permissions, and revoke it wherever it's been set to false.

I don't think this is a good comparison. A page can be locked from move (effectively removing 'move permissions,' from a subset of users on the particular page). The same thing cannot be said for content model. For example 'Earth' is move-protected on enwiki (I have not checked, but I believe it's), thus deterring any page move vandalism. But if, CM change were granted to 'all groups that have 'move' permissions", that means a determined vandal can easily (4 days-10 edits) cause a great disruption on Wikipedia by converting 'Earth' to plaintext or by converting 'United States' to JavaScript Content Model. The same vandal cannot move these pages to any title even though they have 'move' permission.

Recurring problem by several vandals can only be combated with high level page protection, or (expensively) with AbuseFilter. Both ways would be a one step forward, two steps backward situation if they were to be ever needed.

So to make it truly "conceptually equal status to 'move'", a 'contentmodel-protection' must be created to allow locking "highly visible pages that have no reason to be moved for their content model to change". (1)

So that we can lock Earth, Universe, United States.... and possibly millions other mainspace articles. In fact, I cannot think of any reason for any of the 6M enwiki articles to have a CM change. So we'd end up needing something like this

$wgContentModelChangeDisallowedNamespaces = [ 0, 1, 2, 6, 14 ] // possibly others or turn it to allow-list 

That's not pretty either. For me, I'd even remove this unneeded right from sysop group on Wikimedia and grant it to only interface admins or stewards. It is very rarely needed right, and most admins are not even aware they have it, and that fact in itself is a good argument why they don't need the right. It'd be good also to know the answer to the question "how many content model changes are made per year on English Wikipedia?"

I too, think that this task should be declined, the risk is high... the benefit very close to nil. (The main extension needing this is no longer "in active development", and not in use on all?/most large wikis due to myriad of its problems that clearly need more attention than this risky configuration)

Second declining this as a base mediawiki config, and as a default WMF wikis config.

So to make it truly "conceptually equal status to 'move'", a 'contentmodel-protection' must be created to allow locking "highly visible pages that have no reason to be moved for their content model to change". (1)

Yeah, we'll need to do that too. No rush.

On Wikimedia wikis the right should be limited to autoconfirmed users, akin to move.

I also see how some wikis might want to restrict this to extended-confirmed. It is conceivable that mainspace pages might need to be moved, but as Ammarpad notes, the same might not be true for changing content model.

Change #309066 abandoned by Hashar:

[operations/mediawiki-config@master] Match 'editcontentmodel' permission with 'move'

Reason:

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