29 August 2011, 18:54

I've now read most of the Walled Gardens/Isolated Institutions code to get an idea of what it'll take to get it merged into core before 1.5. I tested the public version from 18 June 2010*, which contains everything in Mahara 1.2, and probably quite a bit of what eventually made it in to 1.3.

It modifies a lot of different areas of the code, but it's less invasive than I feared it would be. Because Mahara has moved on significantly, there will still be a lot of work to bring it up to date with the latest master, clean up the code for review, and ensure that the WG restrictions are implemented efficiently and don't impact negatively on non-WG sites.

The isolated institutions feature will also make future development of Mahara harder, by requiring another set of checks to be performed for any new part of the site in which users interact with one another.

More detailed comments on specific areas follow.

Institution Trust Pages

The new pages that deal with the institution walled garden settings and the trust relationships between institutions will be relatively painless to bring up to date: they're mostly independent from the rest of the system.

Viewing Untrusted Users' Pages

Many pages relate to a single user or owner: profiles, views and collections, requesting friendship, sending messages, etc. For these it's easy to restrict access efficiently. The existing policy is that isolated users can't see profiles, views, or request friendship of anyone outside their trusted institutions, and free non-admin users can't see profiles, views, or request friendship of anyone who's a member of an isolated institution.

Isolated users can reply to messages sent to them by a site admin, but can't compose a new message to anyone outside their trusted institutions.

Trying to access any one of these pages displays an error message (currently along the lines of "Access to this view has been restricted as a result of restrictions enforced by Walled Gardens").

Listing Users, Groups and Institutions

The hard parts to deal with (at least the way Mahara is currently written) are the many pages which display lists of users, groups or institutions. The policy in the current WG code depends on the page. Untrusted users are either

• filtered out (for example, the user search page), or
• listed but greyed out so you can't link to their profile (e.g. on the group members page and view feedback), or
• sometimes they're just displayed normally and when you click through to their profile you get the WG error message (e.g. in forum threads).

Aside from the potential usability issues (users who you can see in some places are not visible in search results), providing links to error pages is never really desirable behaviour, and we'll have to make an effort to fix it up.

These listings are the most invasive part of the WG feature. There are around 15 places I noticed where additional sql is inserted into the db queries, to filter or pull extra information about users, groups, and institutions. It does a very good job of isolating untrusted users, but looks like it's not completely exhaustive and doesn't implement restrictions quite as fully as it should (details further below).

Sometimes there is extra overhead added when lists of users are checked through one by one, querying friend & institution trust relationships for each one.

I'm not sure how we'd go about making this less invasive, and less prone to messing things up for non-WG users, but it would have to involve combining as many of these queries as possible into a single place, and trying to implement WG restrictions in fewer parts of the code. That would be a great thing to do, but it would also be a big job and have its own risks.

With the current code, it will be very hard to prove that the WG restrictions are always enforced correctly. So when describing the feature to prospective institutions, I'd be inclined to limit expectations. Instead of saying "With this great new Isolated Institutions feature, it's the same as running a separate site just for your school!", it'd be more prudent to say something along the lines of "You can now prevent your users from seeing people who are outside your institution on pages x, y, and z".

Group Membership

One hole in the existing WG code is that if you create an "Invite only" group, you can send group membership invitations from the bulk invite page to anyone on the site regardless of institution. I suspect the bulk invite stuff got merged in from master after the main WG development. Admins of controlled membership groups can also add anyone on the site to their group, but this is potentially less of a problem because of the built-in restrictions around who can be an admin of a controlled group.

Because site admins and staff can *always* add anyone to a group, and users can join groups *before* their institution becomes walled off, there will invariably be cases where users whose institutions don't trust one another are in the same group, even if the above holes are fixed.

Once you're in a group with another user, trusted or not, you can interact pretty normally on the forums and in the group area without restriction. Frequently you'll see a link to a user you shouldn't be able to see (but you get an error message when trying to link through to their profile). This happens in forums, and other group pages, but also on the my friends block, and probably other places too.

New and Future Pages

Recent versions of Mahara have many more places where the WG restrictions will have to be hacked in. For example, the new Shared Pages page, the Topics page, probably also the Group views block (views shared by users you're not allowed to see), the group members block, group info block, and the Institution contacts page.

The new Online users page and associated queries will need some decisions made, because the institution's online users setting (new for 1.5) probably ought to override the WG setting when there are 2 or more institutions in the trust relationship.

The WG settings will have a substantial impact on new features we plan to add in the future. For example, the frequently-requested "search all content on the site that's visible to me" feature, and the indexed text search plugin, would need to take account of WG settings. It may need to be respected in group blogs, group tags, and we'll have to work out how to fit it in cleanly with the upcoming groups revamp.

Group Visibility

The visibility of a group on a My groups block or on the Find groups page is dependent on the institution(s) of the group admins. The idea is that if the group admin(s) are untrusted, the group is untrusted. This seems like a reasonable stopgap until such time as all groups can have institutions associated with them. It will stop isolated users from being able to find groups owned by site admins, but they can still be added to site-wide groups manually if the group is controlled membership. I didn't test what happens with groups that have no admins - Mahara tries to avoid that situation.

In the My Groups block it appears that even when one of the group admins is visible to you, you can't see groups unless they're also public groups. This is too restrictive.

Site Content

Isolated users can't access public site views, or see groups which are owned by a site admin. This is a potential problem for multiple-institution sites which make heavy use of site views in the "links & resources" menu on the home page. We'd need a workaround that would either relax this restriction, or try to make sure those links are hidden for isolated users.

Isolated users also can't access public views owned by an untrusted institution, and can't look at the profile of a site admin.

Institutional Admin Powers

With WG, institutional admins gain pretty destructive powers. They are able to break friendship, view access, and group membership between all users in their institution and all users in untrusted institutions. One good thing is that users are informed when this happens: "Due to the changes imposed by walled garden settings, you were removed from the friend list of %s. Sorry for any possible inconvenience."

If we leave those buttons in place, institutional admins will need to be very careful about pressing them, because in many ways they're more destructive than deleting users. The reason is that friend, group, & view access relationships aren't part of a portfolio, so these relationships can't be restored using leap2a from a backup unless the entire site is rolled back.

I don't think these powers need to be available at all on a user-centred portfolio site, but if some sites are really going to feel the need for them, then we should at least add a site-wide option to remove the buttons.

Public and Secret URL Pages

The WG policy around views has a strange consequence. The isolated users are prevented from looking at public or secret url pages owned by untrusted users. But because they're public pages, we can only enforce the restrictions when a user is logged in and we know who they are. Isolated users can therefore just log out and gain free access to any untrusted public page. On sites where anonymous comments are enabled, logged out users can even leave feedback on pages they cannot see when logged in.

We also need to decide how the new institution-level restrictions on creating public pages will fit in with the WG restrictions. Isolated institutions may want to stop their users from creating public pages. But if they choose to do that with the current rules, turning off public views will also turn off secret url pages, preventing all sharing with non-registered users (parents).

On the other hand, if an isolated institution chooses to allow its users to create public pages, then the current restriction (free users get prevented from visiting public pages owned by isolated users) is inappropriate.

The isolated institution is trying to achieve two different things: it's partly trying to protect its users from being spied on by untrusted stalkers, and partly trying to prevent its users from seeing (or just being distracted by) untrusted content. But the normal institutions don't care if their users see content created by anyone, so a sensible policy is to allow the free users to see isolated users' public content, and at the same time prevent isolated users from seeing the free users' public content (though obviously as mentioned above, if the isolated users log out, we can't prevent it).

Francois suggested that we remove WG restrictions on public views when they're accessed directly, and be satisfied with making public views less discoverable by isolated users, keeping the links hidden where this is practical. I'd like to see the same approach taken to logged-in access, because that would mean the access list on a view is actually doing what it says it does (logged-in really means logged-in), but I appreciate there's no easy way to get around the WG restrictions in this case.

New Profile Restrictions

The new rules for profile views are also going to be changed soon, so that rather than forcing logged-in user access, it'll be possible to have profile views that are accessible only to a user's institution(s). This probably won't be drastically affected by the WG, unless we need to try to force access to all trusted WG institutions rather than just the ones the user belongs to. But we will have to try and stop the isolated users from manually giving access to untrusted institutions.

*WG code from git://gitorious.org/~rkabalin/mahara/rkabalins-mahara.git, luns_walled_garden_public branch, last updated 2010-06-18.

30 August 2011, 5:04

Hello Richard, you have done a huge revison work, thanks a lot for your comments and costructive criticism :)

I mostly agree that the current implementation of Mahara isolated institution is not ideal, especially this is related to scalability, so I agree that we should reduce the number of checks and combine them so that there will be less occurances of isolation related areas in the code. Ideally, it should bring isolation checks to the very low level, so that the user adding new page would not worry much about checking isolation permissions.

30 August 2011, 5:09

I agree with you that the powers to break existing friendships and revoke memberships should not be there. That would go against the spirit of the project.

Sites that want to enforce these things should just start out with isolated institutions.

It really feels weird telling Bob that he can no longer be friends with Alice because of his school's policy.

30 August 2011, 9:02

That is absolutely fine, in fact my initial idea was not to break existing friendship/membership when trust realtionship is removed (see "Other issues" in the initial specification), but then we agreed to make this optional: http://mahara.org/interaction/forum/topic.php?id=1163#post5722

14 August 2012, 1:26

Hi Ruslan,

Just wondered if there's been any further discussion about updating this for 1.5 and merging into core. I just checked out your presentation from last year's Mahara UK conference where you said it was being used successfully for a 300 school deployment, and made me wonder if they are still running 1.2, or if the code has been updated somewhere.

Any update appreciated,

Mark.

14 August 2012, 3:45

Hi Mark I think Ruslan's on holiday at the moment but he'll no doubt answer you shortly. I am in that school area of 300 schools so we are using the system - and we are still on the same version as when Ruslan did his presentation. (politics -don't ask!)

05 September 2012, 8:18

Hello Mark, the code has not been updated, it is still 1.2 based. Some people expressed their interest in the feature, but it did not go any further yet as noone is willing to fund the upgrade/integration project.