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.socialOPEnglish
    4·
    1 year ago

    I think that’s a heck of a loaded assumption there that I’m relying on the Devs here

    Cloudflare ✅ Strict Firewall Rules ✅ Hosting on an actual cloud provider rather than my home ✅ CSAM ✅

    However, that’s come with other tradeoffs in useability, speed, and fediration experience.

    Just today I found that the OWASP managed rules in Cloudflare end up blocking certain functions of the site, sure I’ll be adding an exception/rule for that, but it’s not a straight forward task. Heck, the removal of websockets will require quite a few changes in my Cloudflare config.

    Sure, someone truly concerned with security knows to do this - like myself.

    • wpuckering@lm.williampuckering.comEnglish
      1·
      1 year ago

      However, that’s come with other tradeoffs in useability, speed, and fediration experience.

      Like what? If properly configured none of the things listed should negatively impact hosting a Lemmy instance.

      sure I’ll be adding an exception/rule for that, but it’s not a straight forward task.

      It honestly should be to someone who would be hosting any public web application using Cloudflare. Cloudflare makes all of this quite easy, even to those with less experience.

      Heck, the removal of websockets will require quite a few changes in my Cloudflare config.

      What config are you referring to? In the Cloudflare console? For websockets changing to a REST API implementation there should be nothing at all you need to do.

      Sure, someone truly concerned with security knows to do this, but that’s definitely not going to be everyone

      And it shouldn’t have to be everyone, only those who take on the responsibility of hosting a public web application such as a Lemmy instance.

      No matter the capabilities inherent in what you choose to host, the onus rests on the owner of the infrastructure to secure it.

    • sunaurus@lemm.eeEnglish
      1·
      1 year ago

      Can you elaborate which functions are blocked by the managed rules? I haven’t noticed anything legit being blocked yet, just a bunch of obviously malicious things.

      • th3raid0r@tucson.socialOPEnglish
        0·
        1 year ago

        Yeah, I can’t seem to upload photos without whitelisting /pictrs/ from the OWASP managed ruleset. It wasn’t being “blocked” but it was trying to do a managed challenge and the lemmy-ui’s code didn’t really understand what to do with it. so it would just throw an error on upload.

        • sunaurus@lemm.eeEnglish
          2·
          1 year ago

          I would recommend reconsidering that solution - I’ve already seen some malicious image uploads which Cloudflare has caught and prevented. For example:

          Maybe you can check which specific rule from the ruleset was being triggered? For me, legit uploads are still working with the default ruleset (as you can see by the screenshot I uploaded in this very comment), so maybe you enabled some extra rules?

          • th3raid0r@tucson.socialOPEnglish
            1·
            1 year ago

            Interesting, well, I guess I sound vague because the error was pretty vague:

            Cloudflare OWASP Core Ruleset

            949110: Inbound Anomaly Score Exceeded

            So yeah, your example is from the Standard Managed Ruleset, I wouldn’t even think of Disabling that, and I think this issue is limited to this OWASP one only. I think I’m still safe here, but I think I can just exclude only this one particular rule as you noted.

            EDIT: Nope that’s the one you cannot edit. Strange, I’m fairly certain these files are fine and it’s probably not that - I may have to exclude the entire ruleset here.

            Double Update: Yeah, so this OWASP one is far to sensitive. I’ve validated my files with AV and other solutions and tried other machines and such. Apparently it’s tripping some XSS rules, SQL injection detection rules, and a few other things. Mostly seem like false positives on account of the EXIF and other file header data.