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

I think we should actually change the defaults we ship to MediaWiki to match what we've deployed in production, and default the editcontentmodel right for user to false.

Change #1181160 had a related patch set uploaded (by C. Scott Ananian; author: C. Scott Ananian):

[mediawiki/core@master] Ship with `editcontentmodel` turned off for ordinary users

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

Change #1181160 merged by jenkins-bot:

[mediawiki/core@master] Ship with `editcontentmodel` turned off for ordinary users

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

Change #1182663 had a related patch set uploaded (by Arlolra; author: Arlolra):

[mediawiki/services/parsoid@master] Use admin instead of alice to change contentmodel

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

Change #1182663 merged by jenkins-bot:

[mediawiki/services/parsoid@master] Use admin instead of alice to change contentmodel

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

@Pppery closed this task as Declined.

I don't think that's a correct read of the patch of interest. Whether the default in core is admins only or whatever is not what the WMF wikis can have (and I note WM-site-requests in the projects list, so this task at least has that meaning).

But I'm not fussing to reopen here because I think I'm also pretty much at the point that this permission isn't (ready) for arbitrary users to use and I have some doubt it will ever be ready at this point. Some discussion above had some "figure out a protection scheme" and some of it has a "figure out a -where-should-this-never-be-reasonable-by-default scheme" and that never happened in the decade (5 years since one of those was proposed I guess) this task has been open.

I think this should be reopened but marked as stalled on adding safeguards that make the right harder to abuse. ContentHandler already has ::canBeUsedOn() which can be used to prevent usage in certain namespaces. That way, all content models except wikitext can be disabled on mainspace, user talk, and other places which should always be wikitext (except Flow/LQT should be allowed in user talk of course). Extensions can already hook into the canBeUsedOn() logic of core content models.

I don't think we need a separate "content model protection", instead we can just make it a part of move-protection.

Change #1182924 had a related patch set uploaded (by C. Scott Ananian; author: C. Scott Ananian):

[mediawiki/vendor@master] Bump wikimedia/parsoid to 0.22.0-a19

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

Change #1182924 merged by jenkins-bot:

[mediawiki/vendor@master] Bump wikimedia/parsoid to 0.22.0-a19

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

What is the usefulness of changing the content model of an existing page? However, creating a new page with a different content model than the default can be useful. For example, required by MassMessages, TemplateStyles... However, I'm not sure changing the content model once the page has been created and has revision is really useful. Comparing revisions from different content models is probably unsupported or can't be meaningful. And it can be quite disruptive, since the new content model may disallow the use of page histories.

At least 2 users in this task have already mentioned it:

El T85847#2625474, @Harej escribió:

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.

El T85847#5861772, @Ammarpad escribió:

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)

Maybe MediaWiki should introduce a new user right that grants the ability to create a new page with an arbitrary content model, while keeping the editcontentmodel for changing the content model of an existing page. Then grant this new right to all logged in users.

New right

Mistakes still happen. That said, something that direction should probably be in the context of T380691: Page creation should have drop-down to specify content model.

Maybe MediaWiki should introduce a new user right that grants the ability to create a new page with an arbitrary content model, while keeping the editcontentmodel for changing the content model of an existing page. Then grant this new right to all logged in users.

That would be T248294, and is the only proposal here that I'm not completely against.