User:Aa/EduBlog/EduBlog analysis

Moodle Theming

Goals

Provide a streamlined interface matching the Sugar experience. A secondary goal is to reduce network traffic and rendering costs on the laptop.

As the 5 week project involves writing a detailed manual for teachers, this is one of the key areas that should be worked on first. After writing the documentation, a "UI freeze" should be imposed, and no major changes should be made to the UI.

Comments

The current theme included in EduBlog's moodle is lacking. Hiding the trace only makes it harder to navigate for administrators and future usage. UI cleanness should be achieved by proper configuration. Themes are kept in folders in moodle/theme and are picked up automatically by the system.

See more information on themes and a couple of tutorials.

Suggestion: Modify one of the existing themes at: [1] (keep it lightweight)

Authentication

Goals

Implement an easy to deploy, secure, and transparent authentication system (In that priority order) for Moodle running on school servers.

A basic Threat Model

Below is a list of threats to the blogging system I can think of. A "user" is a kid (student) or a teacher but not an administrator.

1) An unauthorized attacker accessing the system with administrative privileges compromising the Moodle installation.

2) An unauthorized attacker accessing the system with a user's account for spamming and/or possibly further social engineering.

3) A authorized user accessing with another user's account.

Questions and Comments for the Threat Model

1. What are the source, nature, judge, and containing environment of the authority that distinguishes 'authorized' users from 'unauthorized'?
   • In particular, how does a user become authorized?
2. Threat #1, '...administrative privileges', seems to confuse two issues: 'layering violations' like attacking the operating system underlying the Moodle software and 'compromise of administrative Moodle accounts' by any means, e.g. secret-stealing, replay attacks, session hijacking, brute-force, ...
3. Threat #2, '...for spamming and/or possibly further social engineering' seems to be intended to suggest a notion of 'legitimate' content (including a notion of permissible rates of resource consumption). If so, this could be clarified.
4. Threat #3, "an authorized user accessing with another users's account" should be revisited based on the response to Question #1.

Comments

Speak to server-devel about planned password-less XS Moodle authentication system. Giving kids passwords is not a good idea... A public key authentication system using the XOs and Moodle's keys would be ideal.

More down-to-earth, though highly insecure, is the possibility of using MAC addresses for authentication (run a lookup of the IP's MAC address in the server's ARP cache and validate it against a list of allowed addresses). This is especially insecure in the case of teacher's machines that have higher permissions.

Course management, permissions

Goals

Maintain an intuitive blogging and administrative workflow inside Moodle.

Comments

Users can be uploaded en masse through the "Upload Users" option in the administrative interface. This should be the method of manually adding kids and their authentication information to the database. The required input is a file in CSV format described here: [2].

Currently, the blog menu in the course context has the following links:

 View my entries
 Blog preferences
 View course entries
 View site entries

Which are probably best laid out as:

 View my blog
 View my class blog
 View my school blog
 Blog preferences

The code for the blog block is in moodle/blocks/blog_menu/block_blog_menu.php and could be used to make a similar block for oublogs.

Currently OUBlog doesn't support blogs based on context (user, course, moodle installation). This should be added, as it enables usage of EduBlog alongside standard Moodle in a more intuitive fashion. The solution with the current implementation is to have students create their own personal course.