- Who can become a member of the network
- Security and privacy
- Hardware requirements
- Final Remarks
This document contains the terms and conditions for institutions that want to join the Mconf Academic Web Conference Network (that will be simply called Network from now on) that is described in this page.
In the rest of this document, the components of the network will be referred to by:
- “Core”: The core services in the network include the load balancer, the monitoring server and the Chef server.
- “Pool”: The pool of web conference servers (Mconf-Live nodes).
- “Web Portals”: The web portals or websites of the eventual institutions that want their users to access the service through their own web portal to, for instance, use their own visual identity.
- “Partners”: Institutions that have joined the network, having a server in the infrastructure.
Who can become a member of the network?
Currently, any education and/or research institution that agrees with the terms described here can join the network. It includes universities, NRENs and research/study groups that are willing to contribute and benefit from the network.
The resources in the Core of the network are currently maintained by the company Mconf Tecnologia. This company was created by some members of the project Mconf and is currently responsible for maintaining these servers and making sure the service is available and updated at all times. This service is provided by the company as an effort to promote and improve the network and the software.
The resources in the Pool of the network are maintained by the partners that provided the resource. Each server in the Pool is associated to a partner and to a person that is responsible for it. Mconf is responsible for monitoring the servers and contacting the partner responsible for it if problems are found, but the partner is responsible for solving these problems. The servers might be disabled by the Mconf until the problem is solved.
Partners are responsible for making their servers available at all times. The servers shouldn’t be disconnected or powered off without first notifying Mconf, to make sure the users won’t be affected (i.e. a conference won’t be suddenly stopped because the server was powered off).
Partners are also responsible for the data stored in their servers in the pool (conference logs and temporary recordings) and for keeping the metadata of their servers up-to-date (the metadata informed when joining the network).
Mconf does not have administrator access (shell access, or ssh access) to all servers in the Pool. Each server is administered by the partner that provided the server, and the partner is the only one with administrator access to their servers. The servers in the Pool are accessed by Mconf only via:
- The web conference API: Used to create, end and join meetings, for example. See more about the API here and here.
- The Chef client: It is an application that runs in each server to update the web conference software automatically. When a new version is released and the recipes (i.e. scripts) are updated, there is a process in the servers in the Pool that detects these changes and run the recipes in the server. Since this recipes are arbitrary code that Mconf is running in the servers in the Pool, they are all open source, so partners can know exactly what is running in their servers. Read more about it in this wiki page
The servers in the Pool can be used by any user that has access to the network. In other words, users can create web conferences in any server in the Pool, not only in the ones provided by their institutions.
For end users
For users that access the network through an institutional Web Portal, support should be provided by the Partner that maintains the web portal. In other words, a Partner is responsible for their web portal and for giving support to their users.
For users that access the network via mconf.org, the support is given by Mconf. The web portal at mconf.org provides ways for the users to give feedback and get help, and support is given by email only in English and Portuguese.
However, if a Partner recommends to their users to access the network via mconf.org, support to these users should be given by the Partner, and not by mconf.org. Mconf will still receive any feedback and requests for help via mconf.org, but for a higher quality end user support, the Partners themselves should provide it to their users.
Technical support for Partners
For partners (and future partners – who want to join the network), technical support is given by Mconf. They can contact Mconf via any of the contact methods described in the contact page.
Security and Privacy
There has been no effort yet to make the communication in Mconf secure in terms of privacy. Mconf does not use HTTPS, SSL or secure RTMP (RTMPS) on the web conference servers, so the data shared within a session (audio, video, chat, and others) is not encrypted. On the other hand, the web portals connected to the network can (and should) use HTTPS (mconf.org already does). So the information about your users, such as their username and password, are cryptographed, while the information that is exchanged during a meeting is not.
All API requests must have a checksum that is computed using a secret key, that ensures some safety in the API calls (e.g. arbitrary people or institutions won’t be able to start or end meetings in the servers). All partners have access to the Core services, but partners have access only to their meetings, so they won’t be able to modify meetings from other partners. In other words, an institution A will not be able to either end or get information from meetings created by an institution B.
When recording a session, the recorded data will be temporarily stored in the servers in the Pool until the end of the conference. After that, the recorded conference will be moved to the web portal (or to a recording server) of the institution whose user started the recording. The consistency and privacy of these temporary files is responsibility of the Partner that provided the server, and under an unlikely circumstance of a server crash this data could be lost. After the files are moved to the web portal, they will be under the responsibility of the web portal admin. Under any circumstance Mconf will provide guarantee of recording success or prevention of unauthorized copy.
For the web conference server that institutions must provide to join the network, you can see the hardware requirements in this wiki page.
After the web conference server is installed, it is responsibility of Mconf to check if the node is working properly, and a communication will be issued reporting the node status after the verification. After that, the node will be available in the global map.
The software updates are based on Chef, so there will be a process running in the partner’s server checking for updates. When a new version is available, the application will change the server status to “unavailable” in the load balancer, wait for all web conferences to finish, and then run the script to update the software version on that server. After the upgrade is finished, the application will change back the server status to “available”. The scripts that run on the web conference server are open source, so institutions can see exactly what they’re doing. More details in this wiki page.