freedomofpress / securedrop.org

Code for the SecureDrop project website
https://securedrop.org
GNU Affero General Public License v3.0
40 stars 9 forks source link

Implement spam prevention techniques on instance submission form and contact form #452

Open msheiny opened 6 years ago

msheiny commented 6 years ago

Issue first came up in #441 and #451 is the PR that begins implementation details. Sounds like we have a decision to make regarding prevention of spam to an internet facing form here.

To summarize current debate:

eloquence commented 6 years ago

Agree a basic Captcha that's not Google would be great here. We do get some unwanted non-Tor traffic from landing pages, and while it doesn't go directly to the forms, sending traffic to Google on any SDO views is still not ideal. If necessary, I would be comfortable launching with a CF throttle only -- I think the initial risk is acceptable -- but let's look at alternatives.

conorsch commented 6 years ago

The old securedrop.org has some local plugin handling captcha validation logic

Good distinction: we should definitely strive for a no-third-parties approach here. This one looks like it'd fit the bill: https://django-simple-captcha.readthedocs.io/en/latest/usage.html, but I defer to @harrislapiroff on applicability.

As for the THS bypass, I'm ok with that for launch. Tor is generally a poor vector for sending high volumes of traffic, and our monitoring is getting strong enough that we should be able to react quickly if we're letting in too much spam.

eloquence commented 6 years ago

So, it turns out that Wagtail actually has Recaptcha enabled for all forms on SDO, they're just blocked from appearing outside the admin UI due to our recently implemented CSP. So right now forms are broken.

Recapping suggested actions:

harrislapiroff commented 1 year ago

[Backlog pruning 5/10] @eloquence This is an old issue. Is spam still an issue the securedrop team is struggling with or can we close?