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 Moodle with administrative privileges compromising the Moodle installation. Any lower layer (e.g. operating system) security considerations are outside the scope of this project.

2) An unauthorized attacker accessing Moodle with a user's account.

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.

-- Thanks for your comments. I've updated the model to answer some of your points. Aa 01:55, 6 October 2008 (UTC)

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.

We need to know how the communication between the school server and the XOs (e.g. theft deterrence) is currently authenticated to get an idea of what we can work with.

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 supports blogs based on context (user, course, moodle installation), but it looks like this isn't exposed in the user interface. This should be added, as it enables usage of EduBlog alongside standard Moodle in a more intuitive fashion. We could use moodle/block/blog_menu as a base. The solution with the current implementation is to have students create their own personal course.

Proposal

Write a moodle block based on the "Blog Menu" block that comes with moodle exposing the various contexts for blogging.

Wordpress

Edublog can already sync a post to an external Blogging System, currently only blogger is supported. We plan to add support for Wordpress publishing. The goal is to be able to upload posts remotely to a Wordpress instance, and also create new blogs as they are created on Moodle. We plan to use Wordpress MU for managing multiple users and blogs.

This Wordpress MU could be seen as the public centralized face of the Edublog system. Since Edublog will be deployed on each school server, having an outside an idependent public site with the blogs has a few good things:

• Minimizes School bandwidth
• Custom Installation (with blogger we couldn't do everything we needed to do
• ...

Create a theme for an external Wordpress installation where public blogs will be replicated and accessed from the internet, using the same guidelines from the Moodle (EduBlog) theme.

Write modifications

Goals

Enable direct blog postings from write.