routerl

To be fair, most bot detection can't and isn't trying to catch 100% of bots. Generally the idea is to prevent repeated abuse, rather than stop every single instance of it.

In the case of the scalper bot you've linked, the goal of bot protection would be to make the bot's transactions so computationally expensive/slow that they miss out on most of their intended purchases.

I'm super interested in curating a dossier of these sites and experiences like yours, if only because we're genuinely interested in preventing issues like these and don't do the types of things that lead to these complaints, like IP-range profiling.

Disclosure: I work at friendly captcha.

> They all put up browser surveillance / captcha blockwalls to "stop bots" (even despite bots being legitimate shoppers these days!) that make the sites just straight up not work on most of my browser configs.

What do you mean by this? For example, we do escalating proof of work and I'm not sure how this would make a site not work, even for very exotic configs with high risk signal (e.g. spoofed user-agent, proxies, etc). It will definitely consume more CPU cycles, but I don't see how it would affect functionality.

Disclosure: I work for Friendly Captcha.

Have you thought about adding a proof of work challenge? Your bandwidth is spared and attackers get increasingly expensive computational puzzles.

Disclosure: I work for Friendly Captcha, which uses the above strategy.

It's less rare than you'd hope. Disclosure: I do developer relations at Friendly Captcha, and our widget is one of the scripts that uses generated offline audio (but with no microphone recording) and reads the buffer back on sites that otherwise have no use for audio.

We do this to check whether the browser is what it claims to be, not to track who you are. Similarly, font rendering, floating-point math results, WebGL renderer strings, and whether built-in functions are patched is all much harder to fake. These considerations determine how hard the proof-of-work puzzle should be, and site owners can see it as a risk score. We don't do cookies or browser storage, IPs aren't stored, and nothing gets used to recognize you on another site or on a later visit. The biggest players in automated traffic prevention can't (and usually don't) say this much, because of conflicts of interest between automated bot detection and their other products (e.g. ad sales and IP-profiling).

Your example is really fair though. I chatted with our engineers, prompted by this thread, and we found nothing in our detection that currently uses the audio hashes we collect, so we've started talking about removing the collection.

From the perspective of wanting to maintain the integrity of the American federal government, it seems like all this DOGE stuff (and the whole Trumpist movement in general) serves the purpose of a red team, in the cybersecurity sense; people with nebulous intent have gotten access to everything.

So now, if Americans care about the integrity of their government, there needs to be a blue team: how can this catastrophic level of access be dealt with, and how can it be safeguarded against in the future. Alas, I'm not seeing this perspective being enacted. The obvious security compromise is being allowed to stand and continue, usually on the basis that "separation of powers" and "checks and balances" are relied on to be effective; congress will stop this, or the courts will stop this. But we're watching these mechanisms fail.

So, what's the plan here? Where's the counter-offensive? We're watching a system being hacked, and I've yet to see anyone talk about a recovery plan, or a prevention plan.

It seems to be an article about all those "harmless" lies we tell students.

The vast majority of people think mathematics is about numbers, when it is actually about relations, and numbers are just some of the entities whose relations mathematics studies.

Nobody is born with this misconception; we teach it, and test it, and thereby ingrain it in the minds of every student, most of whom will never study mathematics at a level that makes them go "wait, what?". The overwhelming majority of people never get to this level.

I suspect this is also why statistics feels so counterintuitive to so many people, including me. The Monty Hall problem is only a problem to those who are naive about probability, which is most people, because most of us don't learn any of this stuff early enough to form long lasting, correct instincts.

It's not fair to students to bake "harmless" lies into their early education, as a way to simplify the topic such that it becomes more easily teachable. We've only done this because teaching is hard, and thus expensive. Education is expensive, at every step. It's not fair or productive to build a gate around proper education that makes it available only to those who can afford it at the level where the early misconceptions get corrected. Even those people end up spending a lot of cognitive capital on all those "wait, what?" moments, when their cognitive capital would be better spent elsewhere.

OP here, I'm adding a feature that will allow users to save specific words to lists, and export the lists in formats that can be imported to flashcard apps.

For anonymous users, I'm using OpenNMT, via Argos. Logged in users get DeepL translations, which correctly translates 气功师.

Thank you, and thanks for checking it out!

I use Pleco almost every day :)

I did! Jieba is the first step in my segmentation pipeline. As far as I can tell, Jieba's default config tends to work better for simplified, but in my case the custom dictionary I feed it has significantly more traditional entries than simplified entries, especially for historical terms and slang.

It supports traditional and simplified, as well as pinyin and bopomofo :)

It's already possible to switch instantly between pinyin and bopomofo, and I'm working on letting users switch between simplified/traditional, but this is also a non-trivial problem. For now, the app will follow the user's lead: if you enter traditional text, it will return traditional text, and same goes for simplified.

Thanks for the kind words, and the bug report!

The (awful and incorrect) translation you've pointed out comes from the segmenter being too greedy, not finding the (non-existent) word in any dictionary, and therefore dispatching the word to be machine translated, without context. This is the final fallback in the segmentation pipeline, to avoid displaying nothing at all, and my priority right now is making the segmentation pipeline more robust so this rarely (or never) happens, since it sometimes produces hilariously bad results!