Talk:Requests for comment/Page protection as a component

Previous page history was archived for backup purposes at Talk:Requests for comment/Page protection as a component/LQT Archive 1 on 2015-07-10.

"We shouldn't distribute MediaWiki without a permission model", well we've done so for about 13 years. :-D Security issues with authorization extensions outlines some of the problems. IMHO two realistic goals for this RFC would be:

1. reduce hardcoded and scattered permission checks in core (e.g. checks for a specific default user group hardcoded in the code for a special page or action);
2. introduce pervasive and low-level hooks to override core's behaviour where needed, making it possible for Lockdown to be simpler to implement and to not need core hacks at all (bug 64787 and friends).

The current page protection scheme has always been very flat. It takes a pretty much "all or none" approach to page protection that's simply anti-wiki. Right now, there are two basic forms of page protection:

• autoconfirmed — allow only certain users who meet hard-coded requirements to edit a particular page; and
• sysop — only only certain users in a particular user group to edit a particular page.

These two options kind of suck. Page protection should be much more flexible. For example, it should be possible to protect a page from any user with less than 100 edits to allow users who are clearly established in the community. Or it should be possible to limit based on how new a user is (more than just saying the user must have been around for four days as the current system requires).

Tim and I have discussed this type of feature previously. He suggested doing it in groups or levels or tiers or whatever, so you could standardize and simplify the scheme a bit. On-wiki configuration of these tiers would be ideal, of course.

I'm not sure if this particular RFC would allow for better granularization of page protection, but if so, I'd stress that in making the case for implementing this idea. I'd focus on the "opens the page up to more people" argument rather than getting lost in gated trunk models and other things (which are honestly kind of separate issues).

I think the extension part really is a no-go for page protection. Though as Daniel notes above (I think), the waters are getting muddy here because it's unclear whether you want something more akin to better page protection or something more akin to a hybrid of Extension:Drafts and Extension:FlaggedRevs.

mz, great notes, I definitely want to help brainstorm an improved protection system -- but you should create a new venue for that. As you say, I'm already throwing people off the scent by mentioning "gated trunk". My plan for componentization is actually to change nothing at all, but to build in as much flexibility as we have the imagination to provide.

MZMcBride's proposal looks closer to Requests for comment/Itemise protection.

Adamw, you've mentioned gated trunk over and over. Could you actually explain what part of gated trunk needs control over the protection system that it doesn't already have.

Cause so far I haven't seen any reason why gated trunk would need any change to the protection system.

So far the only thing I've seen was "Protection shouldn't exist in gated trunk so needs to be able to remove the protection system but doing so with hooks would require handling a large number of individual hooks".

However in such a context I would argue that's a mistake. Gated trunk does not negate protection. As much as your ideal might be that a wiki with gated pages should never have a protected page. There will be cases where a wiki's admins will want to protect pages so that even gated edits can't be made. They may want this for their site script pages, etc... or they may have pages on the wiki where by policy they will never accept a contribution to by a non-staff. And this isn't strange inside the gated trunk world. Because Gerrit's ACL system already makes it possible to do such a thing.

So in such a case you actually shouldn't be touching the protection system at all. You may consider hiding the protection system a little to prevent abuse. Or telling the sysadmin to configure protection so that sysops can't use it and you require higher permissions. But besides that the only thing you should be doing with the protection system is suggesting that the person installing your gated pages extension should willingly go and start unprotecting pages.

Yeah, if gated trunk was the issue then it would already be fixed by an existing extension, FlaggedRevs. So, that's clearly not the problem this RFC wants to address. :-)

Adamw, to be honest this RFC already feels a little tainted. It started with a set endpoint in mind without debating whether the rationale for that end was there. The rationales for such an idea were never explained in proper detail. And even if we start expanding it at this point it's going to remain confusing and the way it started will probably continue to act against whatever you really want.

I suggest you start a new RFC. Instead of suggesting extensionification, componentization, etc... right from the start; start listing different ideas for improvements to the protection system. ie: "A fully controllable ACL system; With the ability to control rights per user. And specific conditionals like age and how many edits instead of just the autopromote settings." Then we can start discussing things like "Should this be part of core, or an extension?", "If it's in core, how do we handle the old system? Do we keep them both around working mutually? Or it it possible to rewrite the old system as a subset of the new system that just uses a different UI.", and "If it's an extension. What hooks, interfaces, and changes are we missing to make it possible to write? (A question that often requires actually trying to write the code and attempts to use the existing hooks first.)".

I think the RFC should be scoped down to reflect the summary that Adam himself made of it on IRC:

21:11:47 <awight> To summarize the [page] protection as a component thing, I noticed that there's a lot of security logic mixed in among classes which have other responsibilities.

Moving to extension, reinventing FlaggedRevs, ACL etc. are each an entirely different and huge topic which is completely unexplained in the current text; mixing them all is certain to block any progress forever.

The RFC seems to presume that to make a feature extensible it should be removed from core and put into an extension. I believe this is a fallacy. In the first place you don't even need to remove something from core to make it possible to plug in completely different code.

Being an extension is not a prerequisite for experimentation. Some features do belong in core, including experimental ones. We should encourage ideas of near-ubiquitous features and experimental incremental improvements of core features to be done in core, not move things to extensions just to improve or extend it.

In the case at hand. I see no reason to remove protection from core. If there is a good idea for improvement to our protection system the core code should be improved, such an improvement shouldn't be segregated to an extension only available to the few who bother to install it. And if it's a feature only useful to a few it should be built as an extension and we should make sure that core has enough hooks and interfaces to make it possible to write. But we shouldn't remove the already universally useful protection we currently have just to do that.

Dantman, You're correct that extracting functionality into an extension is not required. Componentization could be done within core, although I haven't seen any good arguments in favor of that. The built-in protection model is certainly not universal -- see the proliferation of User Rights extensions. Also, bundling extensions with core has been the norm since MW 1.18, I'm not advocating shipping with protection totally disabled. My instinct to extensionize is probably motivated by ignorance and prejudice, although it does seem to be supported by the trends in other open-source projects, among which core functionality is being consistently reduced and divided into decoupled components.

I do strongly agree with your point that potential improvements to the protection model should be distributed by default so that all users benefit.

Thank you for this input, I'll try to update the RFC to disentangle the extension vs. component facet of the debate. Honestly, this is very secondary to the main thrust of the work I hope to complete, and I would be perfectly happy if page protection remained in core, as long as the implementation is flexible and clear.

Unfortunately, far-reaching changes within core will be impeded by inertia.

Moving protection to an extension is totally inappropriate. Practically every wiki, even private ones, have at least one page which is "special" and requires a restriction that all the others don't, including for legal reasons (e.g. the main page or the copyright terms).

The page makes this assertion:

Wikipedia, for example, would be better served by a gated trunk model similar to the workflows used in w:DVCS development. In other words, "Kill the 'View Source' button" and always enable editing, even if the user's changes are saved to a sandbox and do not automatically update the public-facing default article contents. It is already possible to do something similar with Extension:FlaggedRevs.

However such a feature has absolutely nothing to do with the protection model. Moving protection into an extension doesn't help one bit to make this feature possible. In fact you could probably already develop it using the hooks we have available.

I've reverted your change to the RFC; please feel free to justify the deletion further, or better yet make changes or restructure without deleting the text.

The paragraph gives a concrete example of a feature which, in order to make sense, would basically have to disable a large portion of core functionality in order to work properly, so I see it as an appropriate statement among a list of shortcomings that my patch is designed to address. The built-in protection model is opposed to gated trunk because it prevents editing and creation of certain titles, neither of which should happen in gated trunk. In other words, if a person does write the gated trunk extension, it will have a lot of code which has nothing to do with gated trunk, but only exists to reverse the changes made in the name of page protection.