Ethical, Legal, and Security Considerations

Ethics

Are users' privacy expectations met by your software?
In order to meet the privacy expectations of users, it will be necessary to encrypt any personal data such as password, student ID (if included), and performance. If the client uses the program during a lecture on a screen which is visible to the students, then it will be necessary to hide the average student rating on the Student Randomizer page.

Could the use of your software result in racial, gender, religious, or any other type of discrimination? How does your software try to mitigate this problem?
Our software is used to select students by pure random selection. Due to this, there are no apparent ethical issues related to the selection feature of our software. Additionally, the program itself will not be responsible for determining the students’ performance in class, but rather tracks the performance rating given by the professor (user). Since the software won’t rate student performance, there aren’t any ethical issues related to student grades. To ensure fairness, the data tracking must be accurate, though, to prevent students from getting graded incorrectly based on their performance tracked through the program.

Can your software be abused by some users to cause harm to other users? or to the public at large? How do you mitigate it?
The software is intended to be used by professors to keep track of their classroom data. While the software itself may not use any bias in tracking student data, the subjectivity of the rating system could be unfair in some situations. When randomly selecting a student in class, the user (any professor using the software) is responsible for determining the student’s performance. Due to this, bias could be involved in the rating process, since the rating is subjective.

Legality

Is your software violating any licensing agreements? List all third-party software you plan to use and ensure that you have the right to use as you plan.
There is no violation of any licensing agreements. Gunicorn, Python 3.13, Django 5.1.2, and MySQL are all open source with permissive licenses which allow us to use, modify, and distribute the application without any licensing agreements.

Are there any intellectual property constraints placed by your client? or by the owner of some dataset you need to use? List them.
There will be some intellectual property considerations that will have to be taken such as the student data privacy. Student information like names or ID numbers in the database will be handled with care.

Can your users use your app to break the law? post copyright works on your webapp? steal information? Etc.
Users of the application are unable to break the law as the data within the app is imported by the user and only accessible with proper authentication. Additionally the applications does not provide any copyrighted works, the only importable data is short strings.

Security

The following user info will need to be stored:

• User email and passwords.
• Student names associated with what class they’re in.
• Student ids and rating information.

Django provides a built-in authentication system through django.contrib.auth. Interfacing with this will simplify user security, as it uses a SHA-256 hash to store passwords, encrypted through PBKDF2. Both of these are commonly used in the industry, and should be secure enough for the purposes of this project. The database will be stored on a server using Oracle Cloud, the only way to access the file system will be through SSH protected by a private key and 2FA.

To prevent XSS attacks, Django automatically escapes all user input into another format. However, it could be possible to bypass this through sending a request using a different encoding method. It is important to scan user input to ensure it only contains an allowed set of characters (ideally alphanumeric for everything but passwords) and to never display user input on pages as safe.

To query the server, Django uses POST and/or GET requests to a url, which then either loads a new page or redirects you elsewhere. Without proper authentication, simply loading a page like /student/<int:pk> could provide a user with another user’s information. As such, each page must check that the user is signed in, storing a cookie that resets weekly.