Feature Proposal: Protecting an application's code needs DENYTOPICRAW

Motivation

Good applications require substantial investment. To choose Foswiki as a platform some clients need a means to protect their IP. Presently much of the underlying code can be taken by someone with READ permission just adding ?raw=on

The purpose is to restrict users from using the raw view action in order to protect the wiki markup code.

Concerns about this have been mentioned a few times. Here's a couple of examples I know of:

Description and Documentation

A permission level similar to ALLOW*READ but that caters explicitly to denying access to the application's wiki markup code. A user could be granted access to see the effect of the application without seeing the code that constitutes how it is implemented.

Enrique Cadalso says:

It seems there is nothing developed yet in that direction. Moreover things like that are seen as dangerous by some people (http://foswiki.org/Development/EncryptDataInTopics) and in any case they could be seen somehow against the wiki open source spirit. There have been some attempts to achieve this functionality. Back from TWiki the now obsolete and not ported to Foswiki HideInEditModePlugin was abandoned and now the EncryptDataInTopics proposal but nothing working.
Another way to do this:

  • Move the core of the code to templates stored in /foswiki/templates directory. This forces changes to be done in the filesystem only by administrators (or foswiki extensions BuildContrib style - so you're managing updates to this important application). The use of template in topics is ruled out by access control (http://foswiki.org/System/SkinTemplates#Security_and_usability)

The proper way to doit today

  • Write a Plugin that checks a custom ACL - checkAccessPermission('SPIN', 'IncyWincy', undef, 'ThisTopic', 'ThatWeb', undef) will return true in the earlyInitPlugin or initPlugin and redirects to something you do allow.
  • Similarly, you can post process the output in a plugin using completePageHandler to check if there are some text signatures that you know should be secret and do something.

Examples

Impact

We'd need to start by handling the way Foswiki handles the raw parameter. This is dealt with in ./lib/Foswiki/UI/View.pm - to see a page in raw mode would need not only READ but READRAW (or just RAW) permissions.

It may be necessary to think about INCLUDEs too.

%WHATDOESITAFFECT%
edit

Implementation

-- Contributors: MartinCleaver - 17 Jun 2011

Discussion

+1

Seems as if a checkAccess("RAW"...)) in View.pm should do the trick.

-- MichaelDaum - 17 Jun 2011

Martin, you raised a concern already against your own proposal, but I'm not sure what your concern is.

My concern is that Foswiki is architected from the ground-up for topic-level ACLs only. The machinery to support finer ACLs on parts of topics (like formfields) or in this case - something even more exotic, a particular representation of a topic, just isn't there. We could trivially implement something that denies view to ?raw=... but there are so many other ways to access the Foswiki::Meta::setEmbeddedStoreForm() - how are we going to secure all of them? There are plugins to consider (and audit!), the rendering model probably needs a re-think.

Or are we only considering DENYRAW to protect against users with read-only access? (still, you'd want to ensure there's nothing in your site that allows rendering of arbitrary macros from a stray URLPARAM etc).

-- PaulHarvey - 17 Jun 2011

I contemplated doing something more like DENYDIRECTVIEW - both this and DENYRAW can be implemented entirely using a Plugin - absolutely no core changes should be required.

however if you really are wanting to protect it, put it in a tmpl file

-- SvenDowideit - 18 Jun 2011

I think the use case of Martin's proposal was not clear. Imagine the following situation: guest visits foswiki site. how to prevent her from sneaking into data and implementation details using the raw url parameter? Not possible currently, however a frequently asked question. From all I know a tmpl approach is not possible. Sure, there are other ways plugins can read the raw topic text and expose it. There's no way to prevent this. That's not the vector Martin wants to stop.

Any other way to prevent a raw view?

-- MichaelDaum - 18 Jun 2011

Then this should be easy to do as a plugin. I don't think it should be a core feature unless we can make the feature reasonably complete (deny all known vectors to the embeddedStoreForm/raw text), although perhaps we can improve core to support such a plugin.

-- PaulHarvey - 18 Jun 2011

like I said,

its pretty trivial to add a new ACL type, and to test it from within a plugin. I've done more intrusive things in the earlyInit handler. Similarly, its not that hard to deny other things that way - all without changing the core (unless there are bugs found)

-- SvenDowideit - 19 Jun 2011

Ah I could imagine using a plugin, worth the experiment, though not practical. In other CMS systems lots of these kinds of actions are controlled via roles.

-- MichaelDaum - 18 Jun 2011

Adding a new ACL type might not be enough. If the snooper may register and create sandbox pages, then %SEARCH's $summary(showvarnames) would show some of the content. Sure, that isn't as easy as ?raw=on but my point is that there may be other avenues to investigate.

-- MichaelTempest - 19 Jun 2011

Should be a plugin if implemented in my view

Idiots protect anything just because they can.

It is an essential part of the wiki way, and of the principle of allowing anyone to take advantage of each others "code" and build on it, that you can copy the code from each other.

This is a feature that is meant to limit, disable, criple, prevent, disallow, hide, make secrets. All the negative things that I personally hate and what makes me so supportive of Foswiki and the values and principles it has represented for more than 11 years.

Just because something is possible and just because some paranoid admins asks for it does not mean that we have to implement it. Sometimes it is better not to implement something if it goes against the values of the product.

I pick up many design ideas from Twikis and Foswikis on the internet. We gave these guys Foswiki for free and it is only reasonable that they share their apps with everyone else. You can still protect confidential information with the access rights we have today. This is about hiding source code of applications. We as an open source project that makes a wiki should avoid implementing features in the core that goes against the core values behind both OSS and Wikis.

I am against it. If implemented it should be a plugin.

-- KennethLavrsen - 19 Jun 2011

I don’t think it is shocking news for anybody that most of the Foswiki content, including applications, is already bound to be “limited, disabled, crippled, prevented, disallowed, hidden and made secret”. Being Foswiki a corporate wiki, it is supposed to be in Intranets, behind corporate firewall, not accessible for everybody. For the same corporate reasons most of internet sites based on Foswiki will protect their content allowing only limited access. If you developed an enterprise wiki you should not be outraged if enterprises try to use it in an “enterprise way”. The home page of Foswiki states “you and your team members”, not everyone else. For instance, right now I would like to access the source code of TWikiSuccessStoryOfMotorola, but alas!, they don’t reasonably “share their apps with everyone else”.

I have always though that the “free and open source” is the “enterprise collaboration platform”, not the content I can develop using that platform. I can’t share with everyone else the application I develop using Foswiki for a paying customer because that code is not mine, it belongs to the customer that is paying for it. The customer is not paying for Foswiki but for my knowledge of Foswiki and for the code I can produce using Foswiki.

If you do not provide enterprises with the features they believe they require then they will just choose the next tool available one click away. And so will do the developers. If you just don’t want to provide those features because they are against the “core values behind both OSS and Wikis” then maybe you should re-evaluate “selling” Foswiki as an enterprise wiki, because, hello!, “to choose Foswiki as a platform some clients need a means to protect their intellectual property”.

By the way, is it really necessary to use terms as “idiots” and “paranoid admins” to defend those "core values"?

(I hope Foswiki community will forgive my use of the “T” word).

-- EnriqueCadalso - 20 Jun 2011

Don't take Kenneths harsh words the wrong way Enrique, but he's right to a certain degree. If admins/powerusers start to hide their applications from occassionally users, how could they possibly learn how to build applications on their own? Foswiki is, by its definition, first of all a Wiki! If you really need special restriction features, let's do it via Plugins, or don't use a Wiki for these kind of content/application.

But of course you're also right regarding companies keeping powerful applications, that could/would be informative and instructional to a much greater public, on their own, thus making reinventing wheels necessary, again and again. Well, I guess the main problem is the corporate/competitive world we're living in today, where there isn't as much room for collaboration as we would wish for. Should be getting better the more the Wiki philosophy becomes mainstream, shouldn't it? wink

-- FranzJosefGigler - 20 Jun 2011

Kenneth, your opinion the way you expressed it above is totally over the top. Foul language and plain insults have no room here. We don't need this. It dies out any fruitful conversation. It paints a very bad picture about the culture in our Foswiki community.

Basically, I fully agree with Enrique. Looking at other systems - and that is what customers will inevitably do when foswiki doesn't satisfy their needs - they will find the missing feature. These do implement fine-grained control mechanisms for all sorts of actions a user can do with a system and bundle them into roles as bunches of access rights. Role-based access control is know to be the RightThing(tm) to do for complex interactive systems. Nothing new. Foswiki doesnt have that. That's more of a real concern why this proposal might fall short in the end as it only addresses the tip of the iceberg opening a can of worms how to actually make it a bullet-proof undertaking. These concerns have been expressed by Sven and Paul above already. And they are right, too.

However, just to deal with raw by inventing role based access control for foswiki is a bit over the top for such an easily fixable feature requirement. The customer does not care if it is done as a plugin or by adding two lines of code to the core as long as his requirements are addressed. You can't come with "ideology" when you don't want to implement this feature.

-- MichaelDaum - 20 Jun 2011

Thanks everyone for the conversation.

Quick clarification: how is role-base-access here different to permissioning using groups? Can you give me an example?

-- MartinCleaver - 20 Jun 2011

Foswiki brands itself as free and open as opposed to some other wikis. You can't simply bypass this with every fad/request/wish the 'customer' (our user's users) has.

Promoting Foswiki as open and having built in measures to prevent openness is in contradiction with that.

There is a difference between preventing users to view a page (privacy restrictons) and in creating barriers for intellectual property (copyright).

But I don't have a problem if someone would create a non-core plugin with that functionality.

-- ArthurClemens - 20 Jun 2011

@Martin, think of a role as a matrix Actions x Permissions, where actions can be quite application specific, like "moderate", "publish", "invoice", whatever. A role is one preconfigured matrix that has got a lable like "project leader", "project contributor" being freely configurable. This matrix is then assigned to people fulfilling this role using the application. Sometimes applications not only control permissions of a user's actions but also the complete appearance, following a more persona like approach to reduce interface complexity for certain roles/personas.

The raw feature here could be one such Action in a RBAC matrix among many more.

RBAC is also related to workflows where a document's state may be changed by a specific role, e.g. "bug owner" is allowed to close the bug after it has been fixed.

All Enterprise Content Management Systems use RBACs, more or less fine-grained. Controlling access is certainly an enterprise feature. Foswiki and its predecessor have been called Enterprise Wiki because it has got quite okay ACLs compared to other wikis like MediaWiki. A lot of users have migrated from MediaWiki to Foswiki just for this reason: access control.

So there's nothing evil about controlling access in the field of Enterprise Wikis.

A lot of corporations just want a wiki as their intranet knowledge base and still require to implement an already existing information policy. Sure, being exposed to web2.0 technology does have an influence on information policies and corporate culture as a reaction. But wikis should not enforce openness at all costs just because they are wikis. If the tool can't protect information from being seen by the wrong people, then it goes out of the fence faster than amen in church. Corporations don't redesign their information policies and decision processes just because there's a wiki now. Instead, they are seeking a platform to exchange information among teams and partners securely and reliably and with ease. That's why they put enormous efforts into controlling access to information, up to a level that might hurt the overall goals of the enterprise. But that's a different story that can't be dealt with on a technical level, a problem that most probably exists with or without a wiki.

-- MichaelDaum - 20 Jun 2011

I stand by every word I said including the way I said it.

And those that cannot understand it that way, can read what Arthur wrote above.

Foswiki (and TWiki) are unique tools and we should not sacrifice the core values. I see everyday how more and more people where I work learn to make small apps by looking at what others have done before.

We do not make money from the number of downloads. Let those that want to limit, disable, criple, prevent, disallow, hide, make secrets go somewhere else. Let Foswiki be the tool for the trusted and empowered people.

-- KennethLavrsen - 20 Jun 2011

In thinking about this a bit, my first reaction was with Kenneth, it just didn't seem right. But thinking about the use-case for hiding group membership - and all the work it took to make sure the %GROUP APIs didn't reveal members to which the user didn't have view rights, using raw=all or raw=debug undoes much of that by exposing the settings that should potentially be filtered by the GROUPINFO macro. Also running a public site vs. an intranet site applies different pressures on what to keep hidden.

Unfortunately as with all tools, they can be applied for "evil" or fair use. There are some very legitimate reasons to protect the raw contents - especially the debug views.

-- GeorgeClark - 20 Jun 2011

Ok, but “small apps” is not what is intended to be protected. On the contrary, that free dissemination of small applications may the proof of concept that makes Foswiki to become attractive to enterprise users as a tool to develop more complex application, and encourages managers to invest resources in that development. And there is no evil in that, they just don’t have the knowledge to go deeper, it is not its role.

It is naïve to expect that complex applications are going to be replicated by common users. Though it is nice to dream about, the fact is that even smaller applications in most environments require a wiki leader to be ported to another context. A complex application even with access to the code is difficult to replicate without documentation. Moreover if it is a complex application it is not to maintain a phone book or a task list but to deal with sensitive data, embedded in the business process. Then we are ruling out this enthusiast user that wants to copy the small application because he just won’t have the rights to use that data without proper authorization from the management, the same management who will decide to invest resources in professional development to deal with his business data.

I have also been in a place where someday I look and see that I have lost track of what’s going on in the intranet wiki, because users have made it their own, and it is indeed a wonderful feeling, but I also know that replication is limited to that small applications and mostly through a leader.

The contradiction I see, again, is that you have developed a tool to the enterprises and now you want the enterprises behave in a different way they usually do. I mean, if you sell butchers knives you can’t expect the butcher just to chop tomatoes and behave like a vegetarian. I believe a better choice for a potential corporate user should be to use or not to use this particular feature instead of to use or not to use Foswiki.

-- EnriqueCadalso - 21 Jun 2011

And let us forget, there are already ways of doing this:
  • Hide the site
  • Use a dodgy hard-to-get-right filter in the web server
  • Put the application content in templates
So what are we accomplishing by not providing an elegant way to do it?

-- MartinCleaver - 21 Jun 2011

As it can be done as a plugin, its really simple - write a plugin! And that has always been one of the simplest deciding factors wrt it being in the core or not...

Unless someone actually sits down and commits to re-writing the ACL system so that it can be (optionally) replaced using RBAC or some other system. (yes the existing system will need to remain for many years because we care about existing users too..) I'd suggest focusing on satisfying your need.

Note that CommentPlugin already adds a custom ACL - its not a new concept - and doing so will mean that upgrades will also work...

I've added this approach to your list on the top of the topic. to be clear that right now this is the most correct, best and most long term sustainable option (and tbh, the fastest and least error prone).

If you want some help writing one, email me....

-- SvenDowideit - 21 Jun 2011

For completeness, what's the process and pros & cons for putting applications in templates?

Thanks, M.

-- MartinCleaver - 21 Jun 2011

Sure enough, the following change to lib/Foswiki/UI/View.pm does the right thing.

    if ($raw) {
        $indexableView = 0;
        $logEntry .= ' raw=' . $raw;
        if ( $raw eq 'debug' || $raw eq 'all' ) {

            # We want to see the embedded store form                                                                                                                                                                                           
            $text = $topicObject->getEmbeddedStoreForm();
        }
        $session->logEvent( 'raw', $web . '.' . $topic, '(checking)' );
        Foswiki::UI::checkAccess( $session, 'RAW', $topicObject );
        $session->logEvent( 'raw', $web . '.' . $topic, '(passed)' );
    }

Just make sure you are not admin when checking for permissions stick out tongue

The next step would be to put this into a plugin.

-- MartinCleaver - 19 Aug 2011

Changing this to Discarded Proposal. Similar functionality is merged into Foswiki 2.0.

-- GeorgeClark - 16 Nov 2015
Topic revision: r26 - 16 Nov 2015, GeorgeClark
The copyright of the content on this website is held by the contributing authors, except where stated elsewhere. See Copyright Statement. Creative Commons License    Legal Imprint    Privacy Policy