Grants talk:IdeaLab/A place to work together

Automated test cases

While the current system of many private wikis may have security/confidentiality issues introduced after upgrades, and doesnt have extensive test coverage afaik, most of the potential vectors are pretty well known and are avoided. If any of these wikis have very sensitive content, I would expect they are not directly attached to the Internet.

I think the 'new solution' needs to have an aggressive set of automated tests which attempts to verify that private parts of the wiki have not become accessible due to core software changes, which the Lockdown extension does not appear to have. Including this would increase the cost of this proposal considerably, but not by an order of magnitude. Depending on the current risk level of running many private wikis on the Internet, this might even be worth doing as a separate 'idea'. John Vandenberg (talk) 12:01, 26 April 2014 (UTC)

I don't know MediaWiki database internals, but Duesentrieb does and he was fairly confident that the low-level system Lockdown uses is certain to prevent access to content that a user is not supposed to see. He's also one of the maintainers of the MediaWiki core database area, so an extension authored by him is unlikely to be spoilt by MediaWiki core upgrades. Again, the same can't be said about uploaded files; separate extensions exist for that and I've not reviewed them.

You're right about the internet, in fact WMDE's "really private" wiki is IIRC only accessible via intranet. Automated testing would probably be a separate/followup project; for this idea however, help by anyone (not necessarily dev) is appreciated in setting up a test wiki and trying to break it. :) mw:Security issues with authorization extensions contains some ideas of things to check. --Nemo 09:58, 27 April 2014 (UTC)

Page listings and Search

Generally, this is a great idea and I strongly support the proposal. I use Lockdown in several of my wikis. The transclusion issues seem to be pretty much resolved. However, there needs to be a rewrite of some of the special pages and search results, as they sometimes access the database directly and thus bypass any security layer. This should not be hard to do, but I am not sure about the performance implications. I am pretty sure it can be done, though :) --Mglaser (talk) 22:27, 5 May 2014 (UTC)

Do you mean that titles are leaked, or even content? I was told "only" titles, tracked at bugzilla:64787. Please file a separate bug if content is also affected. --Nemo 09:24, 6 May 2014 (UTC)

@Nemo bis:. Those patches on mw:Extension:Lockdown/hiding pages appear to be authored by User:WIKImaniac (de:Benutzer:WIKImaniac) a long time ago. We should do an audit to see how many of those bugs are still outstanding. Maybe WIKImaniac is interested in driving these patches home?? Do they have a labs account, etc? John Vandenberg (talk) 15:54, 29 May 2014 (UTC)

@Mglaser:, can you point out one of the classes that needs to be rewritten? e.g. a special page, or which part of the search framework which is problematic. John Vandenberg (talk) 15:50, 29 May 2014 (UTC)

Extension development and sysadmin involvement?

I've read that "MediaWiki Extensions or software features requiring code review and integration cannot be funded." and it seems this proposal is against this. Did I miss anything? Liangent 09:58, 10 August 2014 (UTC)

This doesn't need to be a IEG grant. Additionally, rules can be changed. :-) --Nemo 12:49, 10 August 2014 (UTC)

That rule has been changed, actually :) Though Nemo is of course right that just because this is in IdeaLab doesn't mean it needs to turn into an IEG grant...it could still be eligible for funding, provided someone on the project team had the ability to move it through code review. Siko (talk) 20:00, 30 December 2015 (UTC)

Non-Wikimedia use

I think this project is an excellent idea! I cannot comment on viability of the proposed specific technical solution, but the general concept of being able to have different permission levels for different 'areas' of the one wiki would have a great advantage not only for the Wikimedia Foundation but, even more importantly, for increased usage of MediaWiki in enterprise. Anecdotally I believe the inability to have 'secure' areas within a wiki is one of the bigger factors against corporations moving their internal databases to a single media-wiki instance. Instead, they run MediaWiki in parallel to other databases (or document storage drives) with permissions-based locks e.g. "my department's documents are in the 'N' drive and your department's documents are in the 'P' drive on the corporate network".

So, if this project was supported, I would LOVE to see some effort put in to get an external media-wiki user to invest time in giving use-cases for their needs, and assessing the results for installation on their own wiki(s). Having at least one non-Wikimedia user of MediaWiki give even a half-promise to investigate the applicability of this solution for their purposes would go a long way to making it a viable product. Wittylama (talk) 14:13, 24 November 2014 (UTC)

Hypotheses

This is the stated hypothesis:

"One wiki is easier to manage than dozens. Having a single wiki will help tidying up the information. If there's order, it's also easier to publish what doesn't need to be private; while if there's chaos, nothing will ever happen. Proof: nothing is happening."

Looking at the proposal, the actual hypothesis is probably something closer to this:

"Putting the same information in a private namespace on the same wiki, rather than on a separate private wiki, will result in more information being made public ...even though nobody new will have access to that information, because it'll be in a private namespace that they have no ability to access."

I'm pretty {{dubious}} about this. There might be "public relations advantages", in the sense that anyone can currently see that there are 30 private wikis by looking at https://noc.wikimedia.org/conf/private.dblist, but they wouldn't be able to see how many private namespaces existed on a private wiki, but I really don't see any reason why information locked down in 30 private namespaces will be more public than information locked down in 30 private wikis. It might actually make things worse, because setting up a private namespace will be quicker, easier, and less transparent than creating a new private wiki, and therefore more committees, teams, and projects might be willing to request one.

Also, there is just as little justification for "Proof: nothing is happening" as there is for a statement such as, "Proof: since nothing is happening, there must not be anything on these wikis that should be made public and hasn't already been made public". Which, BTW, is mostly my experience with officewiki. There are some pages that don't contain sensitive information, but those are mostly mirrors of public pages (e.g., copies of team or user pages that are already posted on Meta or mw.org), or things that are just irrelevant to non-staff (e.g., how to file an expense report). Making those pages public doesn't actually improve transparency. WhatamIdoing (talk) 19:26, 28 January 2016 (UTC)

A bunch of wiki silos vs. a bunch of namespace/category/individual-file silos

There was some mention of getting involvement of a non-WMF organization using MW in an enterprise case. I'd gladly sign up for that. NASA has implemented 10s of wikis over the past 4.5 years as a bottom-up solution to knowledge management. As the number of groups using MW increases, our number of wikis increases. We're quickly realizing this is a dangerous path with too many silos where people won't be able to find or share the information they need and duplication will run rampant. So we are talking about merging content based on access level, hopefully focusing on a large wiki that will suit most needs and a minimal number of small wikis for edge cases. We have avoided using Extension:Lockdown because it's hard to trust such an extension, opposing the open nature of MW, in a place where export control and contract proprietary information needs to be protected. Also, while I haven't actually spent time trying Lockdown, it seems like it would just end up in the same mess as Sharepoint. We have hundreds of Sharepoint sites, each with their own permissions scheme. I even heard about a group of about 50 people with over 100 sites based on their permissions "needs". I don't see how any admin could maintain such a permission scheme. I'd be afraid of MW + Lockdown falling into the same problem. In order for it to work, the permissions scheme has to be as simple as possible. --Darenwelsh (talk) 11:40, 13 May 2016 (UTC)

Strategic planning

This suggestion is related to that at Grants:IdeaLab/Strategy Alpha but I think they are complementary rather than competing. Fpr those interested who are watching this page, the issue is currently being discussed at Grants talk:IdeaLab/Strategy Alpha#Yet another portal?. Rogol Domedonfors (talk) 11:53, 14 August 2016 (UTC)