Analysis Phase for a Privacy-Focused Web Form

Now that I had finished gathering a baseline set of requirements and organizing them based on priority and functional/non-functional, the next step was to perform an analysis. This step involved comparing the different implementation approaches that were available to me and choosing the best approach that checked the most boxes. I ended up choosing an open-source tool called Formbricks, and the reasoning for this decision is outlined below.

 

Recap of Requirements

Before I go over the implementation approaches that I considered during this phase, I would like to first recap the must-haves which need to be considered in the final MVP.

 

Functional

  • FR-01 — anonymous form submission
  • FR-02 — privacy policy visible to users
  • FR-05 — secure admin login
  • FR-06 — admin can read submissions
  • FR-07 — admin can permanently delete submissions

Non-functional

  • NFR-01 — no IP logging
  • NFR-02 — no cookies or tracking
  • NFR-03 — HTTPS/TLS
  • NFR-04 — encrypted at rest
  • NFR-05 — no third-party data transmission
  • NFR-06 — input sanitization

 

So, to recap based on this list, the client asked for a maintainable solution with security features built in. A maintainable solution would be one that is easy for someone to create new forms and manage data without needing specialized knowledge such as coding. Furthermore, due to the limited timeframe for completing this project, scope creep was another factor to consider as well. Developing a reasonably secure client-side web form is one thing. However, developing a custom admin portal with secure authentication, encryption at rest and in transit, and the ability to manage submission data is a different beast. It may not be possible within the 8 weeks left in this course, and I wanted a solution that is most useful for the client given the allotted time.

 

Options Considered

The first option I considered was to build it from scratch. This is because I had quite a bit of experience creating web applications and also since I would have much more control in the final output. The two biggest constraints that were against this option was scope creep, and maintainability. First, FR-05 required an admin to be able to securely login to manage submissions, which not only requires secure authentication, but also the development of an admin portal as well. Furthermore, FR-10 requires the implementation to be maintainable with someone with limited coding knowledge as well, which means the solution must support no-code interface for managing forms and submissions. A simple web form that is secure would be reasonable given the 13-week constraint, however, building a full admin portal to manage the submissions, and with secure authentication, and no-code features for easy maintainability is well beyond the scope of the 13-week timeline. Since these two requirements are non-negotiable, I looked into third-party solutions, preferably open-source that satisfy the requirements, while giving me enough control in terms of self-hosting and privacy.

Baserow was the first third-party alternative that I explored. It’s an open-source no-code database platform, that allows for self-hosting, and includes form-builder as well. However, after further digging I discovered that Baserow is mainly a database tool. There’s no real admin dashboard in the traditional sense, since when an admin logs in, the UI is a spreadsheet of rows of data. For a non-technical user, managing and having to navigate through the database interface might be difficult. While FR-09 isn’t a must-have (the administrator portal might have an accessible dashboard for easy viewing of submissions), it was something to consider when looking at other solutions.

CryptPad was another open-source tool that I looked at. While it does have a feature for building a form and a self-hosting option, I quickly realized that it’s primarily marketed as a privacy-focused real-time collaborative office suite, an alternative to Google Docs. What really ruled this option out was that users must log in to submit a form response, and there is no way to submit a response as a guest. Since this built as a collaborative tool, anyone interacting with a document or form, must be treated as a collaborator. This isn’t feasible since creating an account not only adds friction but goes against FR-01 which is anonymous form submission, since the user’s data is now tied to an account.

Nextcloud was the third option I explored. It’s open source with the option to self host, and it has strong privacy protocols build in, and it has a Forms builder available also. The issue with Nextcloud is that it is an entire workspace suite, with real-time document editing, video conferencing, and data storage as well. When an admin logs in, the client would have to go through an entire productivity platform just to enter the form function. There is simply too much overhead in maintaining an entire collaboration suite when only the form feature is needed.

 

Solution

Formbricks seems to be the solution that best aligns with the requirements. It is open source, and you can self-host using a NodeJs instance inside a Docker container. The database that it uses is Posgres, and the frontend is simply Next.js, meaning it is incredibly light. Furthermore, adding its strict adherence to privacy such as encryption at rest and in transit, this satisfies requirements NFR-01 to NFR-05, and FR-01 . Furthermore, Formbricks also has secure authentication protocols such as OAuth and single-sign-on (SSO), which aligns with FR-05. Formbricks has an admin dashboard as well that the client can sign into as well, allowing for deletion and managing of submissions, satisfying FR-06 and FR-07. Furthermore, it allows for custom styling using your own stylesheet, which aligns with the stretch goal of tailoring the form to the brand aesthetic of the non-profit.

           

Leave a Reply

Your email address will not be published. Required fields are marked *