Introduction

In response to the challenges posed by the COVID-19 pandemic, the necessity of a digital communication platform for students has become increasingly evident. To cater to this demand, a new chat application called Zeveraars [1] was developed to provide KU Leuven students with a user-friendly platform for communication. This paper discusses the implementation of Zeveraars and the challenges faced during the development of this virtual campus.
In the first section of this paper, the idea behind the application will be explained. A general overview will be shown of the chat application and how the chat application looks like. In the second section, the software architecture behind the chat application is briefly discussed.
Thereafter, a technical description of the chat application will be provided. It will be focused around the features implemented, such as the 3D map seen in the home window of the application and the security measures implemented in the application.
Furthermore, the paper discusses the teamwork required for its development and the team’s improvements compared to the first semester.
Finally, the paper addresses some potential future work, followed by a conclusion.

Zeveraars: A Chat App for KU Leuven Students on Virtual Campus Arenberg

Overview

The chatter app Zeveraars is designed for KU Leuven students. After registration, users are taken to a virtual campus of Arenberg III, situated in Heverlee. This virtual map is an interactive 3D environment with different buildings. Each building on the map represents a chatroom for a particular course. In these chat rooms, users can chat with other KU Leuven students attending the same course. This helps the students stay connected with each other and ask questions, even when they cannot physically attend classes on campus. A user can only enter the chatroom where they have an active course at that moment to keep the public chats directed towards the courses.
In addition to these chat rooms, the chatter app also provides the option to add friends and have private conversations with them. This enables students to directly communicate their queries and issues with one another, without involving other users.
To ensure that an outsider with malicious intents cannot spread misinformation through someone else their account, a security feature was added: keystroke fingerprinting; which analyses the user’s typing patterns and speed and compares this with their “older” self and other users to check if the person typing is indeed the user itself.

UI of site

The site was made for computer since online courses are attended mostly from a computer. The site might work on mobile but the design is not adjusted for it.
Users can access the site by visiting the following URL on their computer, see footnote 1. The landing page of the chat application is the login page , where users can either log in if they already have an account or navigate to the registration page to create a new one. Users can also access pages that provide more information about the site and keystroke fingerprinting. Once logged in or registered, users are directed to the home page , which features a 3D map of the Arenberg campus. When clicking on the Acco building, a sidebar is shown on the left side of the screen where the user can see their friends and add new ones.
A navigation bar at the top of the window is available on every page, featuring a home button, a KU Leuven button, and a profile button. Clicking on the profile button in the navigation bar leads users to the profile menu, where they can view their username, userID, and profile picture. From this menu, users can also access the settings menu , change their current settings, and log out. Users can easily log out or access the settings by clicking the corresponding button.
A public chat window , consists of two main parts: an overview of the chat, including the building, current course, and participants, and the chat area, where old messages are displayed, and new ones can be typed. Each chat message has several important elements: the username and profile picture, a trust bar indicating the message’s reliability, the date the message was originally sent, and the message itself. More information about how the trust bar works will be provided later.
The chat window for chatting with a friend retains the overview, but it now only displays the frien

Settings page

The Zeveraars website offers various options. Firstly, users have the option to change their avatar whenever they like, by uploading a photo from their computer.
Another option available on the settings page is to switch to a dark mode which can be easily activated by clicking the button located in the settings page . Clicking this button again changes the theme back to light mode.
Finally, when registering new users, it is crucial that each user has a distinct identifier. This is important for security purposes and to prevent accounts from being the same. Utilizing UUIDs, which stand for “universally unique identifiers,” is one approach to accomplish this.
Each user’s UUID, obtained after registration on the Zeveraars website, is the same as the username they chose during registration, with an @ sign added in front. This username must be unique upon registration. However, some users will eventually wish to alter their username. Because of this, members of the website Zeveraars have the ability to alter their username to any name they choose. This is possible because the UUID always stays the same and is independent of username changes.

User-friendly design

The design of a website is the first thing a user sees and should make navigating the website as easy and intuitive as possible. To complement the easy navigation, the navigation bar is introduced that appears on every page. Another feature is the keyboard shortcuts that are available in the different windows. A user also gets an alert whenever they receive a message to make sure they never miss a message. Additionally, the ACCO building has a different color to distinguish itself from other buildings. The layout of the site was also designed with the usability in mind.

Keyboard shortcuts

On the website, there are three different shortcuts: enter when signing up or logging in, enter while sending messages and finally, Ctrl+f to display the chat window’s search bar.

Instead of using the Sign In button to send the information when the user wants to log in/register on the website, the enter button can be utilized. This saves time and makes it more efficient. This shortcut can also be applied while sending messages. This accelerates and simplifies typing while in a conversation.

The last shortcut is Ctrl+f, which opens the search bar in the chat windows. The user can use this search bar to look for previous chat messages that contain a particular term or phrase. It will cycle through them upon pressing enter until the user closes the search bar. If there are no messages found, an alert ’no messages’ will appear. Closing the search bar can also be performed with Escape. When the user closes the search bar the highlight will disappear and the user will be taken back to the most recent message.

Notifications

Pop-up notifications enable the user to react to new messages effectively and rapidly. The user should receive pop-up alerts after logging into the website, regardless of where they are on the site. These pop-ups are only shown when receiving a direct message from a friend. The notification contains the message sender’s username , and will automatically close after six seconds. The user also has the option to manually close it. The popup alerts are made using Toasts from Bootstrap.

Azure

Microsoft offers a cloud computing platform called Azure . It enables customers to access many services via the cloud, including processing power, storage, data management, and networking capabilities. Students receive 100 dollars in credits, that can be used for all these services.

To be able to host a website and run a server, it was decided to use an Azure Virtual Machine (VM). This VM has an Intel(R) Xeon(R) Platinum 8272CL CPU and Windows 10 with a GUI, which makes it usable as a normal computer. Because no exceptional load was expected, the VM uses 2 GB of memory.
The website is hosted on this VM using Internet Information Services (IIS), which is an extensible web server created by Microsoft. A free domain name is then provided by Azure to access the website seen in footnote . Using an SSL certificate provided by Let’s Encrypt, a certificate authority that provides free SSL/TLS certificates, https can be used using this domain name.
The server runs on this VM by using a terminal, for example Git Bash. First, the server files are pulled from the main branch from the chatter’s GitLab repository. These files are stored in a folder on the VM and after using the cd command in the terminal and the path of this folder to navigate to the server files, the server can then be run by using the command “npm run server”. A server will start up on the VM and listen on port 8080, this port is configured in the Azure portal to allow incoming traffic and the firewall on the VM is also adjusted to allow incoming traffic from this port. A user on the website will make a WebSocket connection to this server using

<wss://zeveraar.westeurope.cloudapp.azure.com:8080>.

Software architecture

The website consists of four major components: front-end, back-end, protocol and database.
The front-end component is responsible for handling three technologies: HTML, CSS, and TypeScript. These technologies work together to display the site to the user. HTML builds the structure and formats content, CSS determines the style, and TypeScript handles all the front-end logic, including encoding user input, page navigation, and displaying messages to the user.
The back-end component handles all the sites’ operations logic. There are three essential classes for the chatter logic: Server, Channel and User. The Channel class is an abstract class with two subclasses: PublicChannel and DirectMessageChannel. The Server is used as a single instance, which contains all connected Users, Channels and various data structures such as a map from sessionID (a token to track and maintain information of a user during the user’s interaction with the site) to UUID for ease of use. Users are unique objects for each registered user, containing information such as what friends they have and what channel they are connected to (if any). Channels are objects containing information regarding chat rooms. In our implementation, we use PublicChannels for classrooms and DirectMessageChannels for private channels between two friends. These classes contain information like what users are connected, what messages have been sent, and who can all connect.

Another interesting object is the TimeTable interface, containing an array of TimeSlot objects. These TimeSlots represent a single class a user might have at some point in the week and contain information such as the class description, start and end times, and location.
Protocols are used to facilitate communication between the front-end and the back-end. Whenever a user takes an action which the server needs to be informed about, such as a message in a channel, the front-end gathers all the necessary data and sends it as a protocol to the server. The protocol contains the information relevant to the server to take the necessary action(s). Once, for example, the server has successfully added the message to a channel, another protocol will be sent back to the appropriate users via their connected websockets. The user will receive this protocol and the requested action will take place. The data in the protocols is serialized as JSON objects for efficient transfer and processing.
The final component is the database, which stores the system’s data as JSON-objects saved to text files. This is more easy to use than for example a SQL database, as JSON-objects can be easily manipulated using TypeScript. Whenever the server starts we start by loading in the server from the database. This object contains all the knowledge of the channels and users that can be loaded in from the database. If at any point during execution a channel or user is needed it will be loaded in from the database and cached to the server object. Caching provides performance improvements as loading from the disk is way slower than from memory. They can also be uncached at any point during execution, upon which it will be stored to the database. Of course if the server closes it will save all cached objects.

Technical description

Homepage/ 3D map

As previously stated, once the user has logged in successfully, they are redirected to the home page of our chat application. This homepage shows an interactive 3D-map of the Arenberg campus . On this map, the building in which a user has a lesson at that moment will be highlighted in pink. Users can hover over buildings to see the name of a building , click on a building in which they have a lesson at that moment to go to the group chat of that lesson and click on the building named ACCO to see a list of all their friends . Furthermore, the user can also interact with the map by dragging the mouse to change the camera angle and zoom in and out.

The home page when clicked on building Acco.

A view of benches, trees and bushes on the 3D-map.

Three.js

The three.js library was used to create this map. This map is built starting from a scene with direct and ambient light and a green plane called the ’ground’. On this ground, cuboids are created to represent buildings, if a building has a more complex structure, the Group() function is used to make multiple cuboids represent the same building. This led to some initial problems when hovering over and clicking on these complex buildings, because the functions that where executed when hovering over and clicking on single cube objects, did not execute when hovering over and clicking on objects that are part of a group. After realizing that this group function creates an hierarchy where the group instance is the parent and the cube objects that are part of the group are called the children, this problem was fixed by calling this function on all of the children of the parent from the object the mouse is hovering over or clicking on.

Pop-ups

The text box that reveals information when hovering over a building is instantiated as an empty HTML div-element. When hovering over a building, the corresponding information is added to that box, and the content of the text box is cleared when the mouse is no longer hovering over the building.

Redirecting

When clicking on a building that houses a lesson for the user at that moment, the name of that building is stored in sessionStorage together with the time tables. Thereafter, the user is redirected to the chat window which will connect to the correct aula based on the aula name stored in sessionStorage.

Added elements

To make the map a little more interesting to look at, some textures for the ground, background, and paths were added, as well as little, non-interactive objects to make the virtual campus look more like the real campus. Initially, downloaded models from sketchfab were used to add trees, bushes, and benches, but after discovering that not all machines were able to render the objects in a convenient time, self-made objects , which as a consequence looked a little simpler, were used instead to make sure that every user was able to access the homepage without complications. The objects are created using basic geometric shapes such as cuboids, cylinders, cones, and icosahedrons. Using simple shapes like these can improve 3D performance since the number of triangles required to construct them is reduced, resulting in better optimization.

Security

When putting a site on the internet, security is a major concern for different reasons. The main reason is to protect user data since sensitive information (eg. passwords, personal information) is stored on the site. There are other reasons like maintaining trust from the user and remaining operational without hinder. To make sure the site cannot be easily breached and keep user data safe, several approaches were taken. The following sections provide a detailed discussion of these approaches.

Javascript injections

A common way to alter a site’s appearance is by using JavaScript injections. Normally this behaviour isn’t really harmfull since only the page of the user itself is changed and not anything else, but avoiding it is a better option since it can also be abused for getting other user’s information if the script the user injects is also shown in the URL.
To prevent JavaScript injections two measurements were taken: first of all, any input the user writes on the site is encoded. This means that all the dangerous characters are changed so that they can not alter the code of the site. Doing this has an added benefit that now the user’s input cannot cause problems in the back-end. When the user input needs to be displayed, the data gets decoded again so the original data is displayed to the user. The second measure is to never use ’innerHTML’ on data the user inputted. ’InnerHTML’ can be used to display data on a site but has the weakness that all the data gets treated as HTML and can thus alter the site’s appearance. As to prevent this, ’textContent’ is used instead.

WSS

Real-time data transfer is made possible by the communication protocol known as WebSocket (ws), which establishes a continual connection between a client and a server. WebSocket is frequently used in web applications to enable features like real-time data visualization, online gaming, and (in the case of this website) chat rooms. The Secure WebSocket (wss) protocol provides an additional layer of encryption and can be used for wss communication. This connection between two end points is protected by using the Transport Layer Security (TLS) protocol, which prevents data from being intercepted or altered. The utilization of wss is especially significant for web applications that handle touchy information, like monetary exchanges or individual data. Secure WebSocket correspondence is started by a client sending a handshake request to a server. The wss connection has been established when the server issues a positive handshake response.
The main benefit of ws- over wss communication is that it is quicker and uses fewer resources, but as previously stated, wss offers a higher level of security. Taking into account factors like the sensitivity of the data being transmitted, the speed of the connection, and the availability of resources, the choice between the ws and wss protocols is dependent on the specific requirements of the application. Because this website keeps biometric data about the users, wss was one of the required features. This data is used to perform user verification via keystroke-fingerprinting.
In the previous semester, this application used the WebSocket protocol to send data between the user and the server. However, as WebSocket connections are not secure, the website has now implemented the Secure WebSocket (wss) protocol to provide a higher level of encryption. However, this change was not without technical difficulties. Initially, a self-signed Transport Layer Security (TLS) certificate was obtained using OpenSSL. However, when testing the website in a browser, an error was received stating that the certificate authority was invalid. As a result, the website obtained a certificate through Certbot, an extensible client for Let’s Encrypt, a Certificate Authority (CA) that offers free Secure Sockets Layer (SSL) certificates. Certbot generated four files: cert.pem, privkey.pem, chain.pem, and fullchain.pem. The cert.pem and privkey.pem files were used for the SSL certificate, which is used for both the website and the server.
To be able to use the certificate for the website hosted on Internet Information Services (IIS), it had to be in .pfx format. This was done by using OpenSSL, which combined the cert.pem and privkey.pem files into one .pfx file. For the server, an HTTPS server was first created using the cert.pem and privkey.pem files, which was then used to create a WebSocket Server.

Database

The database has been symmetrically encrypted using the Advanced Encryption Standard (AES). This standard ensures the data is safely stored away and is practically impossible to decrypt without knowledge of the private key. An Initialization Vector (IV) is used to add random values to the AES encypted data. This helps to ensure that encryption of the same text is less predictable and produces different results each time. This is essential to the security. For example if some data gets exposed and decrypted, like a number of usernames, these can not be found in the database, for these are randomized. Furthermore it makes sure that no patterns exist in the database. An easy example of this issue can be shown with a badly encrypted image . Even though the image is encrypted, the outlining of the object in the picture is still visible. One can imagine that such patterns can be equally dangerous for text.

The main danger to this database implementation is the fact that one key is used for encryption and decryption, which is assumed to be safe. If an attacker gets a hold of this key, or modifies this key this would be detrimental to the database. One of the industry standards to solve this issue is using a Hardware Security Module (HSM), a special device designed for safely storing your keys and providing encryption and decryption functionalities. Furthermore a method of key rotation could be employed where keys are used that expire on a set interval.

Keystroke fingerprinting

What is keystroke fingerprinting?

Keystroke fingerprinting or -analysis is the process of identifying individuals based on their unique typing behavior. Every individual has a distinct typing pattern, which can be analyzed and used to create a digital fingerprint. The technique is frequently utilized for security purposes, like in this chat application, to authenticate users. The typing behavior of the user is matched against previously stored timings, and the timings of other users to verify their identity. The website uses N-grams to log the user’s keystrokes. N-grams are continuous sequences of words or symbols, or tokens in a document. In technical terms, they can be defined as the neighboring sequences of items in a document . The paper provided by the didactic team stated that bi-grams or N-grams with N = 2 are sufficient enough to perform user authentication.
The trust level is the degree of trust each message has. If the N-grams of a specific message correspond with the N-grams in the memory of that user, this message will have a minimal trust level of 50 percent. This trust percentage can however be higher if the user’s N-gram’s differ from the N-grams of other users in the system. If the trust level is higher than 75 percent, the message will be perceived as trusted and therefore will be displayed with a green trust bar. Furthermore, if this is the case, the N-grams of this message will be buffered into the memory. This buffering was implemented to make sure that short messages won’t directly influence the N-grams in the memory. Also it was implemented to reduce the memory footprint and enhance performance. Using a buffer allows for more effective use of resources and can also help help data loss in case of unforeseen system failures or crashes. Once the buffer is full, these N-grams will be loaded into the memory.
To have an initial data set of N-grams to perform this user authentication, users are asked to retype a verification text. If a user hasn’t submitted this text yet, their trust level will not be calculated as there is no data to analyse the keystrokes of the message yet. The website assumes that only the authentic user is able to fill in this verification text.

Metric analysis

The evaluation of similarity of keystrokes is done by using some metrics. Firstly an alpha-value was used to implement exponential smoothing. This was implemented with the idea to give newly typed N-grams more weight, because user’s typing behaviour can change over time. Also an a-measure percentage was used. A-measure measures the asymmetry of a probability distribution about its mean. In this system it is used to calculate the similarity between 2 sets of N-grams. If both sets contain the same string (the same 2 keys), and the corresponding timings are similar, the degree of similarity will increase. A lower a-measure indicates better accuracy, meaning that the system can more accurately distinguish between genuine users and impostors. Another measure that was used is r-measure, which indicates the strength of the relationship between an independent and a dependent variable. The r-measure function takes an ordered list as input and calculates its r-measure. The r-measure is computed as a fraction, where the numerator equals the sum of the elements of the list. The denominator is obtained by squaring the length of the list, and if the result is even, the denominator is divided by two. If the result is odd, the denominator is first reduced by one and then divided by two. The final measure that was used is the threshold. If the evaluation of the N-grams is lower than this threshold, these N-grams will be evaluated as similar. If the algorithm is testing the N-grams of a message against those of other users, they will be evaluated as dissimilar. These 4 parameters were tested by analysing the keystrokes of multiple people and by evaluating which metrics gave the most true positives and -negatives.
The first metric that was tested is the alpha-value. For every configuration of parameters the degree of correctness was calculated. This degree of correctness is the percentage of mistakes it makes by calculating: \(\frac{TP + TN}{TE}\) [2]. In figure , one can find the trend-lines of the evaluations per alpha-value. As the choice for alpha = 0,1 overall evaluates the keystrokes the most correctly, this parameter was chosen.
The second metric that was tested was the threshold. Here, the same test was run as before, but only for alpha = 0,1.

performance of user verification for alpha = 0.1

The figure above indicates that the parameter configuration with the highest threshold, that still correctly evaluates other users keystrokes, is 30. This corresponds to a threshold of 0.5, a-measure percentage of 1 and an r-measure percentage of 0. One can also see that the evaluations of the own keystrokes perform the best between a threshold of 0.5 and 0.6 (The true positives and true negatives are maximum here). So further analysis for a threshold between these values was done. This analysis shows that calculations against N-grams of others are evaluated correctly for configurations 4 and 5. Calculations against the user’s own keystrokes however perform better with a higher threshold, as seen at configuration 48. This means that keystroke verification works best for:

	own N-grams	others N-grams
threshold	0.59	0.5
a-measure (%)	75	1
r-measure (%)	25	0

Trust bar

When a user sends a message, the application records and compares their timings to previous records to establish some sort of trust level. The trust level is then displayed as a trust bar, where a full green bar indicates a high likelihood of the person being authentic. Conversely, a low-filled red bar indicates that the user’s typing behavior is inconsistent with past records, suggesting that they may not be who they claim to be.

Known flaws

If the user sends a short message (messages of length 0 or 1), the N-gram can’t be calculated because there is no timing available. this was fixed by keeping a last trust level for each user. This last trust level is the trust level of the last message that this user sent. Unless a new message is short, the trust level of this message will be saved as the last trust level.
If a small amount of users are registered, analysis against other users’ keystrokes won’t always perform 100 percent correctly.
If users have similar keystrokes, it’s very easy for an imposter to mimic one’s keystrokes.

KU Leuven API

In order to show the user in which building they currently have a lecture, the student’s individual class schedule should be known. To do this, the chatter app makes use of the Individual Class Schedule API, a data service offered by KU Leuven . In the process of building this feature, Mr. Jan Du Caju and Mr. Philip Brusten of ICTS provided guidance to ensure a successful implementation.
The KU Leuven API uses the Authorization Code Flow of OAuth 2.0 as seen in Figure. After logging into the chatter, the user is shown a KU Leuven login button that is located in the navigation bar. When clicked, the user is redirected to the login prompt of KU Leuven. After the user enters their KU Leuven credentials, a window is shown asking for their consent to use their class schedule. If they agree, the user is then redirected back to the home page of the website with an authorization code. This redirect is possible because the uri of the home page was previously given to Mr. Du Caju, who in return provided a client code and client secret. These are stored in the server and both are specific to the chatter application itself. Now that the client has the authorization code, it is sent to the server where it is used in combination with the client code and secret to obtain an access token. With this token, the server can access all the individual class schedule data of the user. The user’s classes of the day are retrieved from KU Leuven, including their respective locations, and then sent back to the client.
The retrieval of the access token and the user data both happen in the server using curl commands. These commands make POST requests to the KU Leuven server, including the necessary parameters such as the authorization code, redirect uri and access token in its headers.

Currently, due to technical difficulties with the data service and time constraints, self-generated timetables are used instead of the real timetables. The real class schedule can presently be obtained from the KU Leuven, but because of loss of function of the data service close to the deadline, it was decided to use the fake timetables instead.
The process of obtaining the authorization code and access token is done in the quality environment of the KU Leuven. This environment is made specifically for testing and only KU Leuven accounts that are activated in this environment can make use of its features. The user also needs to be on a KU Leuven network such as campusroam, or needs to have Ivanti Secure Access Client installed and running to access class schedule data. The Ivanti Client is a VPN which connects to the KU Leuven B-zone, using KU Leuven credentials, to allow the user access to data provided by KU Leuven. To be able to let random students obtain their class schedule via the chatter app, a switch should be made to the production environment.

Javascript/TypeScript

Unit test

During the development of the project, it was made sure to unit test all the functions that did not involve extensive DOM manipulation. The unit tests were designed to make use of mocks, however testing client-side code was challenging since browser components are not readily available in Node.js. In such cases, JSDOM was used to simulate the browser environment.
To mock session storage, A class called MockSessionStorage was created. This class implements the same interface as SessionStorage, making it possible to use it for testing purposes. This mock was extensively used during the unit testing of client side code.

export class MockSessionStorage implements Storage {
  
  public getItem(key: string): string | null;
  public setItem(key: string, value: string): void;
  public removeItem(key: string): void;
  public clear(): void;
  public key(index: number): string | null;
  
}

There aren’t any integration tests due to time constraints. However, since each function was tested individually, there is confidence that each function works as intended. Furthermore, the functionality of the KU Leuven API has not been tested, along with the uploading a new profile picture.

Team work

As mentioned in the intermediate report, the team took some serious measurements to improve the teamwork in the second semester. The group started this semester with a presentation on how they were going to regulate their teamwork and an extensive meeting about how they visioned the second part of their project and how they could distribute the different tasks to create their chat application. This resulted in a clear outlining of what everyone was working on and how the different parts would come together in the end.
Furthermore, the branching structure improved a lot. Since everyone was assigned clearly outlined tasks, it became a lot more obvious to only branch from main and therefore not creating a project tree with a depth bigger than two. Establishing some rules for naming the branches made it also more clear what was being done in each branch.
Additionally, the explanation of the features and their implementation towards the other team members has become clearer and more extensive. Each member explained their work and research in a HackMD-document. Although most of the code has documentation, this documentation is not very extensive and was often added later on. So in this front, more improvement should have been made.
Finally, Ibrahim made sure to give a clear overview of what everyone was working on and had finished each Tuesday meeting. It was very helpful to know how far along everyone was and which parts of our project needed more help to finish everything on time. In Figure , an overview per week is given of which team member was working on which part.

Future work

During the start of the second semester, some big ideas for the chat application were discussed. While most of these ideas were successfully implemented, some failed to make it through. This section further discusses the latter, the ideas that could potentially be integrated into the chat application with additional time.
Currently, upon clicking on a building on the 3D map, the user is directed to the associated chat window. The initial plan was to redirect the user to a web page of the building instead, where all the auditoriums within the building would be showcased. This web page would serve as an additional layer between the 3D map and chat window, allowing for a more real campus experience.
One more functionality that did not make it through is the visual response that users would receive when hovering over the building. This response would comprise enlarging the building and displaying additional details about the chat windows. These details would include the number of attendees, how far the lesson is, and the auditoriums located in the building. Currently, all this information, except for the auditoriums present in the building, is exhibited within the chat window itself.

Conclusion

In the end a functional chatter app was made. Azure virtual machine is used to host the website and run the server. The app has a working chat system that allows users to communicate with each other during online class. Users can also add friends for easy private communication. A virtual campus was made on the home page to represent campus Arenberg III. Via the Individual class schedule API of KU Leuven , the home page should have been able to show the user in which building his lesson is being lectured at that time. However, due to some technical difficulties and time constraints, a fake timetable is used instead to execute this feature. Adequate attention had been paid to user-friendly design, including notifications for personal messages, and keyboard shortcuts were also provided for more experienced users.
In addition, security is definitely taken into account: JavaScript injections are prevented, the Secure Websocket (WSS) protocol is used, and the database is symmetrically encrypted using the Advanced Encryption Standard (AES). Finally, a users typing pattern is analysed. The necessary parameters for this were calculated by experimenting with different values until an optimum was found. The result of the keystroke analysis is shown in a ’trust bar’ next to each message.
During the second semester, teamwork was greatly improved to make the process of writing code and merging different branches more streamlined. Unfortunately, not all problems were solved in the new approach, but the team did experience positive change and there was a noticeable improvement in working together.

Authors: Amélie Van Loock, John Gao, Ibrahim El Kaddouri, Guust Luyckx, Thomas Evenepoel, Vincent Ferrante, Barteld Van Nieuwenhove and Maité Desmedt.