this is what they used to look like back in december 2022. why did you feel the need to change them? do you have evidence that AI was able solve it? i can't wait until the near future when AI will be able to solve all captchas... even those google click-all-squares-with-a-traffic-light puzzles. captcha will get so difficult that no human can understand and the internet will be free once again.

I also think it's ridiculous. It's next to impossible to read. It's super difficult to make a post

>>7844 Seconding this. Recently need to refresh it almost 10 times or so before getting readable one

New captcha idea: add image captcha as an alternative to text captcha. BO's could upload pics or mass download them w/ tags from boorus. Board would add random noise, twirl etc. to pics. With some minimum amount of pics it could be enabled and instead of text captcha you would get one like "select all lolis" There would be no reason for spammers to try to defeat it since it wouldn't work on any other site. Text captcha is used on most of sites not utilizing recaptcha or hcaptcha. So a solver for one is easy to sell. Heres a link to some premade solution https://github.com/Kamuso/captchouli

I suppose one way to determine why the generated captchas are so unreadable would be if the captchas that didn't complete correctly (or were skipped with the Reload button) are automatically saved somewhere along with the failed attempts, the correct answer, the level of distortion and any other data that can help find a pattern and fix the problem. In this way perhaps a balance could be found between readability and security. One solution that I found interesting is the one proposed in >>7665 to make the letters use an cursive/ronde font. This would not require applying as much distortion (since most OCR programs do not recognize this typeface, or only partially at best) while at the same time maintaining an easy-to-read font (at least for those who have completed primary school). A similar way to achieve this would be using the mathematical type letters: https://en.wikipedia.org/wiki/Mathematical_Alphanumeric_Symbols?useskin=vector#Latin_letters Mainly the script/calligraphy ones, perhaps also intermixing some Fraktur letters such as 𝔞, 𝔅/𝔟, 𝔠, 𝔇, 𝔢, 𝔣, 𝔨, ℜ, 𝔘/𝔲 and 𝔛/𝔵. >>7891 >add image captcha as an alternative to text captcha. Wouldn't that affect the accessibility of the site? I mean, it's not like blind users can participate in the chan (at least not with the current captcha), but maybe someday the admins will want to add an audio captcha or something (which might be difficult to implement with an image captcha). >https://github.com/Kamuso/captchouli The problem with that Go module/package in particular is that it would need to be connected to Lynxchan somehow (which is written in Node.js). I found https://github.com/zealic/go2node although I don't know if it is the best solution.

>Captchouli This library has a known exploit and is no longer being supported with updates. As a result, it's literally not worth the effort to integrate since it can be defeated more easily than the current captcha. >Another image captcha I'm not opposed to an image-based captcha, but there's some problems with it. We don't want to use an existing provider (Google Captcha, hCaptcha) because of privacy reasons. Most providers of captcha solutions require expensive licensing and are closed-source, and that's if they're even letting you self-host which most are not. There's also the issue of where the images come from. Google and others have a vast supply of unpublished images to utilize. Captchouli sorta worked around this by having it pull from boorus, but it's not impossible for a spammer to pull from the same sources. Basic image manipulation can help deter this a bit but it's not bulletproof. A lot of captchas now are clearly generating images with AI, which would be the most viable for us, but would absolutely require our own hardware to quickly generate a pool of captchas to pull from. >Accessability I'm not sure we'll ever add audio captchas, unless Stephen builds it into the engine. I think the bigger concern is whether it requires JS. We've kicked around the idea of having "WarioWare" captchas for a long time but there's no getting around a hard JS requirement if they're enabled and we're obviously hesitant to do that. The current captchas can be generated and served to users without JavaScript.

>>7975 >but would absolutely require our own hardware to quickly generate a pool of captchas to pull from. Well it depends, I was doing some tests with https://colab.research.google.com/drive/1wEa-tS10h4LlDykd87TF5zzpXIIQoCmq (using Anything 4.5 as model, with all optimization options disabled and on a Tesla T4 GPU) and to generate a 128x128 (or 256x256) image does not take more than 2 or 3 seconds. Doing some research I discovered that it is also possible to use Stable Diffusion on devices like Raspberry Pi or smartphones: https://github.com/straczowski/raspberry-pi-stable-diffusion https://ivonblog.com/en-us/posts/android-stable-diffusion/ Although it is only worth it with a GPU, otherwise it takes 20-45 minutes to generate an image (I guess it depends on the size in pixels). The issue here would be to determine how viable it would be to use this on a server without creating bottlenecks (keep in mind that it would be necessary to generate 9 images per user and that must be multiplied by the number of users who leave the chan open in your browser) and if the cost is worth it (I imagine that a server with a GPU isn't exactly cheap). Another option would be to find out if there is any service to generate images on demand through an API. >I think the bigger concern is whether it requires JS. Not necessarily, you can add below each captcha something like this: Problems to read/load the captcha? <a href="/path/to/the/captcha.mp3" target="_blank">Click here</a> to try with audio captcha. That way with javascript enabled it would add a player to the page similar to how thumbs.setPlayer() does. Otherwise it would open a separate window/tab where, depending on the browser, it would play the file or ask the user what to do with it. To generate the audio file you could use something like eSpeak, Festival, FreeTTS and similar. Maybe with background noise and/or distorting the voice so that it is not so easy to solve using voice recognition as it happens (to some extent) with reCaptcha: https://github.com/dessant/buster/ https://github.com/ecthros/uncaptcha

are you shitting me

i see we're doing this again

While we're on the subject, what fonts are being used in these captchas now. Some of them are pretty wild. >>8505 This one for example. What font is this?

>>8506 >What font is this nigger poop stain

now see look at this. this isn't hard, is it??

Another problem is not distinguishing between 0 the number and o the letter after n. Usually you put a forward slash through the number.

>>8622 I'm pretty sure all 0 are zeros in the captcha.

WHAT IN THE ABSOLUTE FUCK

>>8757 I got a woodblock font for my captcha the other. It was really nice.

lawl

>>7844 One way to avoid (or at least mitigate) unreadable captchas like those of >>8252, >>8505 and >>8757 would be to keep a record of each captcha that the user fails to complete, where each one could be saved as a JSON with a structure like this: { "image": String (path to the original captcha or the base64 encoded image) "attempts": Array (all failed attempts of the user at the time of guessing the captcha) "font": String (name of the font file that was used to generate the captcha) "answer": String (correct captcha answer) "parameters": String (additional parameters that were used to generate the captcha) } That way it should be easier for programmers to eliminate fonts that cause a lot of problems or adjust others that have similar letters/numbers (like 6 or b).