Well, that's why I am asking for practical experience using these tools. Maybe most form spam bots are (still) not advanced enough to complete PoW captchas. Have you tried Altcha or mCaptcha in production?
I have tried everything so far. Something like recaptchav3 will block most headless browsers but very invasive, solving it raises cost quite (for the auto solvers).
Notably no matter what the advertised repositories say So-called „pure play“ (%100% local, no tracking) kind of PoW captcha doesn't do anything for if you are a target and specifically having tools written for you.
For example: I work at a company for MMO game, and as such have to look at what is made. Our form requires numerous so-called invasive features featuring multi-step, TLS analysis, fingerprinting, WebGL, and more. People write dedicated tools to brute force login details or spoof spam, that includes full browser automation and don't care about 100% Usage of CPUs. (I do not have any say in this manner and its out of my scope, I do not "like" this kind of invasiveness)
It depends on your threat model and what is this for. A personal blog a regular one will be fine, any will do. Anything someone will write targeted tool for all self hosted PoW will do nothing.
If you are getting generic form spam simply renaming your field or adding one random invisible field is sufficient to stop automated bot traffic until someone writes a targeted for your.
Thanks for sharing! My current experience is that honeypot fields are often ignored by the bots we're dealing with, but adding hCaptcha is pretty reliable in getting rid of them.
What do you usually name them? You typically want opaque names on all fields and various combinations (some fields auto-filled in with JS that clones the email field, some need to be left blank, some filled in during the onsubmit JS hook..)
I can vouch for using Hetzner for storage (and cloud VPS). TIL Scaleway offers Glacier, which is even slightly cheaper than Hetzner. Might look into that for redundancy. Thanks!
And BEAM was the reimplementation of the Erlang runtime, the actual model is part of the language semantics which was pretty stable by the late 80s, just with a Prolog runtime way too slow for production use.
> Canola and other seed oils are made using toxic solvents which are not full removed from the final product.
This is simply untrue. Independent bodies all over the world regularly test commercially available oils for toxic solvents. While the solvent Hexane is indeed commonly used in the extraction of refined vegetable oils, it is later removed in the refining process.
For example Stiftung Warentest, an independent consumer advocacy organization tested 23 rapeseed oils available in German supermarkets and they all came out clean [1].
A few years earlier, they tested 25 "specialty oils" and found traces of Hexane in only one of them - but still way below the EU threshold of 1 mg/kg. [2]
Here is a study from Japan that tested a bunch of vegetable oils and came to the conclusion that none of the products contained dangerous levels of Hexane. The maximum amount the researchers found was 42.6 µg/kg (again way below the EU threshold) - but in most samples the amount they found was so low they couldn't even get a reading or they didn't find any Hexane at all.
Besides, for cold-pressed oils, no solvents are used at all.
These studies are done to rebuff claims by people whose cohort largely overlaps with those who believe that homeopathic medicine is legit. It's not gonna change squat in their minds.
reply