Simple 3D Chatter application

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

Repository: Github

Demo: You may have to wait quite a bit to load

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 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.

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. It analyses the user’s typing patterns to check if the person typing is indeed the user him/herself.

The site was designed primarily for desktop use, as online courses are mostly attended from desktop devices. While the site may function on mobile, the design is not optimized for mobile use.

The landing page of the chat application is the login page , where users can either log

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.

Furthermore, 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: a username, profile picture, a trust bar indicating the message’s reliability, the date the message was sent and the message content 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 friend.

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¹. Using an SSL certificate provided by Let’s Encrypt, a certificate authority that provides free SSL/TLS certificates.

The server runs on this VM by first pulling files from the release branch on the chatter’s GitLab repository. These files are stored in a folder on the VM and afterwards the server can be run. 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.

_{1.   https://zeveraar.westeurope.cloudapp.azure.com}

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 employs the singleton pattern, which contains all connected Users, Channels and various data structures. Users are unique objects for each registered user, containing information such as what friends they have and what channel they are connected to. 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 such as which users are connected and what messages have been sent.

Another interesting object is the TimeTable class, containing an array of TimeSlot objects. Each TimeSlots object represent a single lecture a user might have during the a specific timeperiod. The object contains information such as the class description, location, start and end times.

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 files. This was used as a prototype and for ease of development. In the future, a mongodb based solution should be implemented. 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 shuts down entirely, it will save all cached objects.

Technical description

Homepage

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 lecture will be highlighted in pink. Users can hover over buildings to see the name of a building . By clicking on the pink building, they go to the group chat of that course. By clicking on the building named ACCO, it will be possible 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.

Three.js

The three.js library was used to create this map. The 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. The functions that where executed when hovering over and clicking on a 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 a hierarchy where the group instance is the parent and the cube objects are called the children, the problem was fixed by calling this function on all of the children.

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. They enable attackers to manipulate web applications by injecting malicious JavaScript code into a webpage. This form of attack is often referred to as cross-site scripting (XSS) and can lead to a variety of harmful outcomes, including data theft, unauthorized access and even full account compromise.

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. 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.

Websocket secure

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. 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 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 ahold of or modifies this key, it 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 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-grams 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 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

Firstly, exponential smoothing 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 parameter that was tested is the alpha-value to configure the exponential smoothing. 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}\). 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.

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:

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 provided to the KU Leuven API in exchange for a client code and client secret. These are stored at 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.

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;
      
    }

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 an 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. 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, 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.

Keystroke analysis