Look, we can debate the proper and private way to do Captchas all day, but if we remove the existing implementation we will be plunged into a world of hurt.

I run tucson.social - a tiny instance with barely any users and I find myself really ticked off at other Admin’s abdication of duty when it comes to engaging with the developers.

For all the Fediverse discussion on this, where are the github issue comments? Where is our attempt to convince the devs in this.

No, seriously WHERE ARE THEY?

Oh, you think that just because an “Issue” exists to bring back Captchas is the best you can do?

NO it is not the best we can do, we need to be applying some pressure to the developers here and that requires EVERYONE to do their part.

The Devs can’t make Lemmy an awesome place for us if us admins refuse to meaningfully engage with the project and provide feedback on crucial things like this.

So are you an admin? If so, we need more comments here: https://github.com/LemmyNet/lemmy/issues/3200

We need to make it VERY clear that Captcha is required before v0.18’s release. Not after when we’ll all be scrambling…

EDIT: To be clear I’m talking to all instance admins, not just Beehaw’s.

UPDATE: Our voices were heard! https://github.com/LemmyNet/lemmy/issues/3200#issuecomment-1600505757

The important part was that this was a decision to re-implement the old (if imperfect) solution in time for the upcoming release. mCaptcha and better techs are indeed the better solution, but at least we won’t make ourselves more vulnerable at this critical juncture.

  • th3raid0r@tucson.socialOP
    link
    fedilink
    English
    arrow-up
    0
    ·
    1 year ago

    Back to my original point, it’s fantastic that the work is planned, but unless they roll back the removal, v0.18 is going to be a huge headache, and not just for the admins of servers running v0.18, but everyone else too.

    • redcalcium@c.calciumlabs.com
      link
      fedilink
      English
      arrow-up
      4
      ·
      edit-2
      1 year ago

      Another option is to put the instance behind cloudflare and enable the highest security settings on the signup/login page using a page rule. Just be careful not to apply it to the whole site to avoid cloudflare blocking federation traffics.

      • th3raid0r@tucson.socialOP
        link
        fedilink
        English
        arrow-up
        1
        ·
        1 year ago

        Yeah that’s definitely an option for me, I love cloudflare. I just know many who prefer to host from home or not using a cloud firewall solution.

        Fun fact, the OWASP managed rules break a bunch of things too. I’ve managed to carve out enough exceptions in the rule to be useful just now, but it took some trial and error.

        Then I’ll have to change that again in the new version if it ships the new API and removes websockets. As it stands websockets largely bypasses a lot of what Cloudflare does - so an API is likely to cause more issues not less as we figure out that “Hey, the POST action here causes OWASP to trip because it’s not as sanitized of an input as it could be”.

        Another poster said this would be trivial. I mean, it is for static stuff. But doing all the federation, allowing API interactions, and being somewhat resilient to malicious actors is a hard balance to find when changes move at a quick pace.