Simple but secure online group formation

Hi guys,

Have coded an online groupware tool to be used by groups of students in university classes, to help them complete their group assignments.

Am having a bit of trouble working out how to improve the initial registration and group joining mechanism - I'm aiming for it to be simple and secure.

Currently it works as follows:
* I (the admin) create a class on the system and add a number of empty groups (group 1, group 2, group 3, etc) inside the class, each with a maximum number of members defined.

* Students then register an account on the system (username, email, name, etc) or log in via a special form if they already have an account.

* After registering or logging in via the special form, they are taken to a page listing available classes and units. They click a group (and confirm) to join it.

* Students can only have one active group enrolment in a class, and groups with the maximum amount of members are greyed out and can't be joined. I/class lecturers am able to disable an enrolment in a group, allowing the student to join a different group in the class. I can also modify the max members in a group if needed.


This works quite well - students form their groups and join up together, selecting the same group, or they are placed in groups and join the appropriate group number/name, etc.


The problem is, it's possible for students to join the wrong group - either accidentally, or deliberately (e.g. to look at the work another group has done). Of course if they do this with their main/only account, they'll need to have their enrolment disabled before being able to join their proper group, but they could potentially create other accounts solely to "spy"...

I'm after some suggestions on how to prevent (or at least deter/hinder) this, while keeping the enrolment process fairly simple.

We're dealing with uni students who don't *need* to use the system, so any kind of effort, coordination or intelligence can't be assumed... which kinda puts a damper on things like requiring an existing group member to approve of new enrolments.

Any ideas?

My current "solution" simply involves making sure the maximum member number is set to the number of people in the group once they've all joined, but that results in a fair bit of "we have a new group member, please increase our limit" email. I guess I could allow group members to increase the limit themselves...

Thanks very much.

Unfortunately there's no way to do this without human intervention.

You might need to provide a list of the valid groups a person can join, you might need to have a group leader approve/deny people from entering a group. etc.

How I would likely handle this is to change things a bit:

* Allow people to have multiple groups.
* Allow people to create their own groups.
* Have the group owner allow or deny people into their group.
* Allow group leaders, and people to remove themselves from groups.
* Allow group leaders to promote a new group leader. (No need to disband the group when the leader leaves)

IMO this solves a few issues: first if people need to be in multiple groups they can be (they could be in multiple classes). Secondly in groups someone tends to take charge anyway. If the leader wants to use this tool they can manage their groups how they want or need to.

I believe this would require a trivial amount of effort on the students part while maintaining a reasonable level of flexibility.

As you said they don't need to use it, those with the desire to use it won't be significantly hindered in putting forth the minimal amount of effort required to set up a new group, and approve or deny classmates access.

-MBirchmeier

Thanks for the response... will address points



They can be in multiple groups, but not more than one in the same class. This is not likely to change, as people should never be enrolled in two groups in a single class.



At the moment the system is being used partially for some research I'm conducting, so I need to keep control of this. In the future, I imagine staff (people in charge of classes, who have a special semi-administrative account) would be able to create groups, but probably not students - Don't see the added benefit being worth the potential for abuse.



A previous system I made which was similar had a group leader role, and it didnt work out. Sometimes the group leader goes idle, or doesn't log into the system for a few days... and everyone else in the group would suffer. People also complained about the concept of a group leader promoting feelings of inadequacy etc. Hence I deliberately dropped any group member roles in the new system.

Allowing people to remove themselves from a group just makes the system more abuseable - they can join a group, look at all their work, leave, repeat...


In the end, I can't really see any other method except for "group member must approve new join attempts" that would really work... Perhaps if I make it so that any current group member can approve of the join attempt, it would lessen the "group member idle = all goes to hell" issue...

And maybe disable the need for approval if it's within 24 hours of the first person joining the group, on the basis of:
* That's when most/all the other group members will also be joining.
* There isn't likely to be any/much work to steal even if someone else joins in this timeframe.

Thoughts?

It seems to me like the basic problem is that there's no way to tie one student to one account. If you have a list of student id's, you can avoid ghost accounts, though this doesn't preclude students using old accounts of others. Once you can do that, you can tie in access control with these accounts, like disallowing unenrollment, and enrollment into other groups. You'll probably need a history of transactions too, to accomplish that. After that, any out of ordinary transactions will be dealt with by superuser intervention.

Everything is very well logged - while it isn't really possible to link an actual person to an account (speaking from a security perspective, that isn't even completely assured with biometrics), any action done by any user is logged.

Classlists and whatnot are unfortunately not a sure thing at this stage - perhaps in the future I could hook the system up to the uni enrolment database and require student IDs to join groups, etc, but that isn't a possibility at the moment.

Also, being too strict on that kind of thing makes it a bit inflexible, which causes problems when the inevitable late enrolments, late unenrolments, group changes, etc happen...

Yeah, i guess that's the doozy. If there's any way of limiting the number of accounts to only the students themselves, it would solve the problem.

The other way would be to get them to sign up during a registration period with their student id/names and generate a user account based on that after vetting the list, and disallow all registrations after that. You could tie the account solely to their student email address.

With face to face contact for registering new accounts after the registration period, it'll stop most from trying to create fake accounts.

I'm going to toss this out there:

If things are truly logged, let the students know that access and file downloads are logged, and let them at it.

Search the logs twice a quarter/semester for any unusual activity (twice as many students accessing a group, someone accessing all groups, someone only visiting a group once and downloading all material) and let them have at it. Presumably they're bound by an honor code, and if evidence of cheating is found come down on them.

That being said I'm guessing that if you trust the students cheating will occur eventually. I'm also going to wager that anyone cheating on an electronic system has probably cheated other ways too and just not gotten caught.

If using this system though I would disable deletes and make sure there's some sort of versioning system. Nothing to say a student won't go out with a bang and delete everything, which is kind of your worst case in this scenario.

-MBirchmeier