New Projects Guidelines

This document sets out rough guidelines for what projects can be added to the BOSS catalogue. All final decisions are left to current committee, who must vote on every project transfer request.

Guidelines

• It must be useful for the student community: either students directly or society-level tools. Please include attestations from the target audience about the usefulness of the tools.

• Projects should be maintainable: good code quality, small, and well-documented and require minimal intervention once running.

• Easy to host, with instructions. Static pages (where all logic happens on the client) are preferred. Any required backends should have containerfiles/dockerfiles written (as this is how we host applications).

• Well thought out structure and langauge choice:

  • The languages chosen should make sense for the problem solved (e.g. you shouldn’t use Javascript in the backend or use raw Python for CPU-intensive operations).
  • The code should be written in the recommended style of the language itself.
  • Our design priciples can be found on our design page.

• Security should be at the core of the project. Steps should be taken to minimise risk. We recommend reading the OWASP Top 10 and following the recommended procedures.

• Resource usage is minimal (including all dependencies such as databases). Your choice of language is also important here. Languages with large runtime overheads (e.g. Python) may work to your detriment.

• It must adhere to our GenAI policy, this can be done retrospectively, but it should be noted within the application itself. If you didn’t put the effort in to write good software, we will not put the effort in to hosting it.

• All projects should be willing to adhere to our licensing policy. All current copyright holders should agree to this. If the copyright holders do not agree to the new policy, alternative arrangements can be discussed with committee.

More specific requirements

Here are some requirements that are for specific types of projects:

• Any frontends should be accessible, utilising aria labels properly and should not have any keyboard traps. Please see W3C WAI for more infomation, or contact the committee.
• Data collection should be minimal and comply with GDPR. Zero data collection is much preferred.
• APIs and backends should be written in type safe languages, e.g. Rust. (NOTE: TypeScript is not type safe at runtime).

Outright bans

Some types of projects are completely banned due to security concerns (some exceptions may be made in extreme circumstances but all mitigations should be made):

1. Use of PHP: By design PHP effectively runs scripts on a page view, this makes expoitation trivally easy when access to the machine is gained, as an attacker can just alter the contents of a file, or add a php file in a certain location to get remote code execution.
2. Use of CGI: Similar to PHP, its design runs any file within a directory, allowing for remote code execution.
3. Use of ports that are not 80/443: This is a limitation of our setup, as the university may not authorise any other ports in the firewall config.
4. IOS/Android apps: it is preferred to make a web app which can then be installed on the device. Mobile apps require signing contracts with Apple and Google, which we don’t want to do.

Preferred setups

These are not requirements. They are our personal best practices and preferred structure. Some recommendations (such as using Postgres) also reduce the overhead of us hosting your software.

For websites/backends:

1. Static webpage (written with static site generator such as Hugo or Zola).
2. Frontend written in TypeScript with a static webpage generator.
3. Backend should only be included if necessary and written in Rust. If you are looking for methods to remove a backend, you may want to look at using WebRTC for local collaboration as well as the FileSystemFileHandle API to store files locally.
4. If there is a backend written, a Containerfile/Dockerfile is written and provided.
5. User login done through CAS with auth.bath.ac.uk or OAuth 2.0.
6. Data stored using Postgres.
7. Frontend should be web app compatible.

How to submit an application

If you have a project that you believe is a good fit for BOSS, you can submit an application. Please email BOSS with the following details:

• Summary of what the project is about, what problem it aims to solve and why this is a good solution.

• Brief mention about alternative solutions and why it is best for BOSS to host it.

• (If not a static site) Justification of hosting requirements, we have limited resources for hosting. So please include:

  • Estimates for CPU and memory usage, including what languages the code was written in.
  • Estimates on storage requirements. Please also include how often you expect to write to the disk, e.g. when users update settings. We have limited hardware and budget and don’t want to replace dead drives often.
  • Please also include whether you will want data to be backed up and explain the consequences of data loss.

• Include security evaluation:

  • What permissions does the container require (e.g. networking, HTTP port)?
  • What services does this require (e.g. Authelia, Postgres, Valkey/Redis, Memcache)?
  • What data is collected from users?
  • What data do you require access to?
  • Explain some example attack vectors you have considered and the mitigations in place.
  • Should this be publically accessible, or limited to only eduroam/VPN?

• What would handover look like for BOSS and any other societies which may use this tool.

Maintenance

During the onboarding process, we will setup a repo with as automated deployments as possible. This will hopefully make maintenance as easy as opening a MR, getting it approved and merging it. In some cases, this may vary, and may require additional steps with committee approving bumping application versions (if it is hosted on our cluster), but for our sakes, we hope to make this process as easy and painless as possible.

Retirement

If a tool is not used and there is little continued contributions towards a project, BOSS reserves the right to archive the project and stop hosting it. This should be communicated to all society members at least a week before any action is taken to allow for discussion.

FAQ

1. Does my project have to be complete to submit it?

   No, we prefer people getting in contact as early as possible in the development process, so we don’t disappoint you if we decide we cannot host it. The earlier you contact us, the more involved we can be in directing you to a solution that we will be happy to host.

2. Am I responsible for keeping it up to date?

   You will initially be assigned the project owner. This comes with some responsibilities to keep dependencies up to date and malware free. However, if the project works just fine, you do not have to continue work on it. Additionally, we understand you also have a degree, you can work on it whenever you are able to, we will not pressure you to iterate as fast as possible. If it gets too much, you can also find someone else to take over the project on your behalf.

3. How much does hosting cost?

   For most projects, we hope to keep this to £0. We only pay for backups of critical applications, and for most projects we can even get away with “good enough” backup system for free using our own servers. If you believe your project requires more, please contact our committee and we can determine whether we can afford the costs. For societies who require more complicated projects that depend on resources that we cannot offer, all costs will be invoiced to the society, but we hope to be able to provide rough estimates in these rare cases, so please get in contact with committee.

4. Can I submit an open source self hosted application?

   We love open source projects and you are free to request a system for us to self host for students. However, these large systems usually require much more resources and induce a larger maintenance burden while also increasing our attack surface. So, you will have to make the case on how the application benefits all students as well as doing research into the best solution for your problem (especially resource requirements).

5. Do I have to manage hosting if something goes down?

   In most cases, no, we hope to manage as much as possible for you. You should only ever have to manage updates. Our systems are designed to be as hands off as possible on a per project basis. But if your project continuously crashes, we will contact you to fix any issues with the software (or risk us putting a pause on hosting it).

6. What is the up time for my hosted projects?

   It depends, if you are just using static pages, we utilise Cloudflare, which means that it will only go down when the whole internet goes down for a few hours every couple years. If you require us to host applications on our own hardware, we cannot guarantee perfect uptime as for longevity reasons we only use one machine to host all applications with minimal redundancy. But we hope to deliver a service good enough that it will not be a problem, reducing downtime to only OS updates (done during the night) and the occasional power outages on campus.