[SPIKE] Spam prevention on SimpleReport waitlist form

[emyl3]

Description

Since 2022, the support team has been receiving spam submissions for the "Join the SimpleReport waiting list" form. The support team has been manually sorting through these requests and deleting them as they notice them.

Action requested

Spike out options for preventing/lessening spam submissions to the waitlist form. Present options to team, get buy-in from product and design if solution(s) involves a change to users' experience.

Proposed solution

In an effort to reduce the amount of spam submissions, we should investigate and implement ways to prevent as much as possible these spam submissions.

Additional context

Slack thread with details about a wave of spam submissions.

Discuss in refinement how we can accomplish the following goals:

1. reduce spam submissions if possible
2. sanitize input from form submissions

[alismx]

Some possible options:

1. disable the form submission button to prevent accidental submissions
2. add a captcha
3. add a hidden field that bots would fill in, but people won't

[fzhao99]

Will go over this at standup Monday, but given the importance of / frequency of the spam on this form, think we should just implement option 3 of what Alis suggested - a honeypot form submission. Because there's CSS that hides the input field in question, we'd assume that anyone that fills it out is a bot and that can be disregarded server side

Just to validate / illustrate the idea, I threw together a prototype branch.

1. Pros
   1. Most lightweight option for us to set up - all our own code! Wouldn’t need to integrate / pay for a third party service
   2. Wouldn’t impact the user experience / accessibility as much as captcha does - did do a bit of reading on the accessibility to screen readers and most guidance suggested that as long as we make it clear in the alt text that screen reader users should disregard the field, we should be fine
      1. The Jekyll snippet we write can be reused / imported into other forms as well that we might mike on the static site in the future
2. Cons
   1. A passive solution - might not catch everything. Wouldn’t protect us from DDoS / form submission issues related to request volume, but this is probably acceptable given how important this form is

If there's a need to implement something more high-powered like a captcha, we can revisit, but probably isn't worth the hassle / degrading the user experience for something like this.

[fzhao99]

Closing since we made #7496