bobbiechen

Unfortunately, well-behaved bots often have more stable IPs, while bad actors are happy to use residential proxies. If you ban a residential proxy IP you're likely to impact real users while the bad actor simply switches. Personally I don't think IP level network information will ever be effective without combining with other factors.

Source: stopping attacks that involve thousands of IPs at my work.

I totally agree - I've sung in a few choirs myself but even I myself hesitate to attend choral events sometimes. It takes effort to appreciate the depth involved, even with modern choral music (think Eric Whitacre) or even gospel choir, compared to other forms of entertainment.

I also agree with the article that understanding the blend of voices is best "when you are singing in the midst of the action" rather than on a recording. But also, that means it's hard to gain familiarity with specific songs or genre-specific styles, which is another barrier to entry.

I agree. Looking back five years, I couldn't have imagined where I am today.

I like the idea of "effectual" / "working forwards" (rather than "causal" / "working backwards") especially when the future is uncertain. To quote Cedric Chin quoting Saras Sarasvathy (via https://commoncog.com/when-action-beats-prediction/):

> If you use causal thinking, you’ll say something like “ok, we’re making carbonara tonight” and then you will work backwards from the end goal (carbonara for, say, five people) to checking for ingredients in your kitchen, to purchasing the ingredients you don’t have, to prepping and cooking carbonara for your dinner party. > > If you use effectual thinking, you’ll say something like “ok, what ingredients and tools do I have right now, and what can I make tonight?” You work forwards from existing resources; the end product is unknown. > >In a business context, causal thinking is “we need to increase sales by 12% by the end of the quarter, what levers do I have available to do that?”; effectual thinking is “we have some spare capacity next quarter: one designer and three software engineers, what crazy new thing could we build that might have value for the company?”

It's not for everyone but it works for me - my path has been very path-dependent and I'm glad to be able to chase interesting and unplanned opportunities.

How would you detect someone who tests a single image using a new free tier, and then (if successful) uses that image against a targeted customer account?

Working in a similar area (bot detection) I think it's very difficult to proactively stop such targeted attacks, but maybe in this space you can do something interesting like duplicate detection across a consortium.

I like this. Most people try to teach card games by listing every rule, but it's much easier to play a simpler version then add in new rules.

I play the Chinese card game Zhao Peng You (Finding Friends, part of the Sheng Ji family of games https://en.wikipedia.org/wiki/Sheng_ji), which is a trick taking game with a trump suit that changes between games, a trump number that changes between games, and a team selection mechanic rather than fixed teams. It's insanely hard to learn everything at once, so we usually start new people with fixed teams and trumps just to get the feel of a team-based trick-taking game, before adding in the complications.

Every software/tech company, maybe? Specialist skills seem to matter more in "hard" engineering (physical world) roles , where it is slower and more expensive to iterate and scale. Sure, you can learn them on the job, but it will cost a lot more time than hiring someone who already knows.

Gall’s Law: all complex systems that work evolved from simpler systems that worked.

>The Revised Uniform Fiduciary Access to Digital Assets Act (RUFADAA), a law developed to help fiduciaries deal with digital files of the dead or incapacitated, can come into play. But Haneman points out that most people die intestate (without a will), leaving matters up to tech platforms. Facebook's response to dead users is to allow anyone to request the memorialization of an account, which keeps posts online. As for RUFADAA, it does little to address digital resurrection, says Haneman.

I think in practice, all the major services do allow removal given proper evidence like a court order. For example, Facebook: https://m.facebook.com/help/1518259735093203/?helpref=uf_sha...

I wrote about RUFADAA and some of the other implications of death in the digital world earlier this year: https://digitalseams.com/blog/what-happens-to-your-online-ac...

With AI replicas of people, I do think this is another case where scale makes a big difference. Anyone could put in huge time, money, and effort before to imitate a dead person. But it's entirely a different problem when the barrier to imitation is so low and so easy.

Perplexity claims their traffic was confused with Browserbase's - I think this is inevitable at scale without better ways to identify traffic (or more specifically in this case, AI agents / fetchers), based on working in this space.

Zooming out for a second, we might be in an analogous era to open email relays. In a few years, will you need to run an agent through a big service provider because other big service providers only trust each other?

_How to Measure Anything_ by Douglas Hubbard includes a chapter on Monte Carlo simulations and comes with downloadable Excel examples: https://www.howtomeasureanything.com/3rd-edition/ (scroll down to Ch. 6)

The main example is, you're considering leasing new equipment that might save you money. What's the risk that it will actually cost more, considering various ranges of potential numbers (and distributions)?

I think it's harder to apply to software since there are more unknowns (or the unknowns are fatter-tailed) but I still liked the book just for the philosophical framing at the beginning: you want to the measure things because they help you make decisions; you don't need perfect measurements since reducing the range of uncertainty is often enough to make the decision.

I like the terminology "crawler" vs. "fetcher" to distinguish between mass scraping and something more targeted as a user agent.

I've been working on AI agent detection recently (see https://stytch.com/blog/introducing-is-agent/ ) and I think there's genuine value in website owners being able to identify AI agents to e.g. nudge them towards scoped access flows instead of fully impersonating a user with no controls.

On the flip side, the crawlers also have a reputational risk here where anyone can slap on the user agent string of a well known crawler and do bad things like ignoring robots.txt . The standard solution today is to reverse DNS lookup IPs, but that's a pain for website owners too vs. more aggressive block-all-unusual-setups.

Stytch | Hiring a Designer and Software Engineers | ONSITE / HYBRID in San Francisco, California | https://stytch.com

About us: Stytch is the identity platform for humans & AI agents. We're making it easy to build authentication, authorization, and security + fraud prevention for both humans and AI agents.

Today we just shipped IsAgent, a tool to identify AI agent traffic and build agent-ready experiences: https://stytch.com/blog/introducing-is-agent/ - I've also got a Show HN post up with more details if you're curious.

We're hiring a designer and some software engineers to build dev-friendly products to make auth and AI readiness easy. More specific details on the job postings here: https://jobs.ashbyhq.com/stytch

Wow, I use the Google Photos widget in much the same way with photos of my wife. What a great idea.

Reminds me of indie hit Balatro's soundtrack being commissioned on Fiverr:

>This month I contacted Luis Clemente on the freelance website Fiverr and he delivered an absolutely amazing soundtrack for Joker Poker. Really knocked it out of the park. I was very nervous about this because it was (at the time) the only money I had spent or planned to spend on the game.

(from https://localthunk.com/blog/balatro-timeline-3aarh)

So true. I recently wrote about how Merlin achieved magical bird identification not through better algorithms, but better expertise in creating great datasets: https://digitalseams.com/blog/what-birdsong-and-backends-can...

I think "harsh reality" is one way to look at it, but you can also take an optimistic perspective: you really can achieve great, magical experiences by putting in (what could be considered) unreasonable effort.

Agreed, I thought it was going to be something automated, but 250 accounts in 7 hours seems pretty manual. That does make it harder to stop.

* 2025-06-09 first user account created, verified, 2FA set up, API Token provisioned

* 2025-06-11 46 more user accounts created over the course of 3 hours

* 2025-06-24 207 more user accounts created over the course of 4 hours

I do run https://bademails.org , powered by the same disposable-email-domains project, and I'll be the first to say that it only cuts out the laziest of attempts. Anyone even slightly serious has cheap alternatives (25 to 100+ accounts for $1 on popular email hosts).

It's hard to self evaluate productivity. In a much simpler domain (decoding a cipher with a tool vs. by hand), I thought I was going much faster, but the stopwatch showed it was about the same: https://bobbiechen.com/blog/2020/5/28/the-making-of-semaphor...

Not feeling tired afterwards is a real improvement though, and I think that feeling is reliably self-reported.

I don't think vibe coding replaces website builders. There is value for non-tech-savvy small business owners to be able to update their websites as WYSIWYG drag-and-drop and deploy without ever having to figure out how to deploy their app through v0, Replit, etc.

I run my blog digitalseams.com and personal site bobbiechen.com (as well as my parents' small business site) through Squarespace even though I have the full-stack skills to do it myself. There's just other things I'd rather spend my time on (though to be fair, I'm also fond of Squarespace as I was an intern there).

Plenty of bots pretend to be Chrome via user agent, but if you look closely are actually running Headless Chromium. This is a very useful signal for fraud and abuse prevention.

(Take this with a grain of salt as I only learned about the Fiat-Shamir heuristic via this HN thread last week https://news.ycombinator.com/item?id=44458168, and I only have basic experience in theoretical cryptography)

There exists the concept of a zero-knowledge proof: check out the Wikipedia page for some intuitive examples of how these work in an interactive context. Basically, by asking someone who wants to prove something (the prover) a bunch of questions (challenges), you can get probabilistic confidence that they actually know that thing: https://en.wikipedia.org/wiki/Zero-knowledge_proof#Abstract_...

You want it to be interactive because that makes it much harder for the prover to "fake it" on the spot. But it would be more convenient if you didn't need to be online and actively talking to each other - so we want a non-interactive way to do the same thing.

The Fiat-Shamir transform (or heuristic) says that we can transform interactive protocols into non-interactive ones by relying on "random" challenges. If the prover can't control the randomness, then it's about as good as you interactively challenging them (and you can e.g. make them do more challenges to make up for it).

How do we get randomness? In computing we don't really have anything totally random, but cryptographic hash functions are believed to be very difficult to predict the output to. So, in cryptography there's the "random oracle model" where you say, "Well, I don't know if this protocol is safe with these real-life hashes. But if the hash function was a truly random oracle, I can prove it's safe." (The Fiat-Shamir transform is only provably secure if you believe in the random oracle model).

In the past, researchers have constructed new protocols that are safe in the random oracle model, but once you use a real hash function they're breakable because of real-world implementation details. As the abstract of this paper says, "So far, all of these examples have been contrived protocols that were specifically designed to fail." See https://crypto.stackexchange.com/q/879 for some discussion of the mechanics of how it might happen, once you choose a real hash function.

This new paper advances the field by showing an attack that targets a real-world protocol that people actually use, GKR. It shows (and again, take my interpretation with a grain of salt) that when you pick a real hash function, the attacker can construct an input (circuit) that results in whatever output the attacker wants.

---

What's the real-world impact?

There do exist real non-interactive zero-knowledge proof systems, mainly used in blockchains. Instead of publicly exposing all the info to the world and doing computation on the (slow) blockchain, you can protect privacy of transactions and/or bundle a bunch of updates into a cheaper one (ZK-rollups). Theoretically these could be attacked using the methods described in the paper.

It's unclear to me whether those are affected here (though my guess is no, since they could have mentioned it if so).

Anecdotally, I heard that at these firms, all the "interesting" work is moving to Florida office because of the longer non-compete period. New York and other offices still exist but the most promising proprietary stuff goes to Florida.

Thank you!!

If I understand correctly:

* The prover commits to a starting value (public input)

* Instead of waiting for an interactive challenge, they hash it and use the resulting hash output as if it were a challenge

If we believe the hash is a random oracle (as we do for cryptographic hash functions), then it is hard for the prover to manipulate the challenges. Is that it?

This is an interactive example, isn't it? It doesn't help me understand non-interactive proofs like SNARKs/STARKs, where the verifier isn't communicating live with the prover.

Anyone have a good explanation on the intuition of non-interactive zero-knowledge proofs? For example, I thought the "paint-mixing" analogy for Diffie-Hellman key exchange (https://en.wikipedia.org/wiki/Diffie–Hellman_key_exchange#Ge...) really helped me handwave the math into "mixing easy, unmixing hard".

https://blog.cryptographyengineering.com/2014/11/27/zero-kno... was a good intro for interactive ZK proofs but I haven't been able to find something for non-interactive ones.

This blog post comparing ZK-STARKs to erasure coding is in the right flavor but didn't quite stick to my brain either: https://vitalik.eth.limo/general/2017/11/09/starks_part_1.ht...

Great high-level overview. One of the challenges about learning about bot detection is that it's adversarial, and revealing info about your techniques can help the attackers evade you.

I do work on a bot detection product, and I've seen some group chats where crackers are sharing notes about how they're evading detection tools. The more unnerving part is that the public groups are less serious, and there are certainly better private groups aiming at anything with a good financial reward.

I do think the answer is two-pronged: roll out the red carpet for "good bots", add friction for "bad bots".

I work for Stytch and for us, that looks like:

1) make it easy to provide Connected Apps experiences, like OAuth-style consent screens "Do you want to grant MyAgent access to your Google Drive files?"

2) make it easy to detect all bots and shift them towards the happy path. For example, "Looks like you're scraping my website for AI training. If you want to see the content easily, just grab it all at /LLMs.txt instead."

As other comments mention, bot traffic is overwhelmingly malicious. Being able to cheaply distinguish bots and add friction makes your life as a defending team much easier.

I'm a fan of installing sl(1), the terminal steam locomotive. I mistype it every couple months and it always gives me a laugh.

https://github.com/mtoyoda/sl

Related: "If an AI agent can't figure out how your API works, neither can your users" (from my employer's blog)

https://stytch.com/blog/if-an-ai-agent-cant-figure-out-how-y...

I am less optimistic. Even paid products like Netflix or the Amazon Kindle are ad-monetized now.

I think the current useful state of consumer LLMs is a temporary subsidy, and the incentives to add ads are too large. And that will change everything, even tools that should work for the user. I recently wrote a blog post on this: https://digitalseams.com/blog/the-ai-lifestyle-subsidy-is-go...

(Author of the post here)

Agreed - I'm pretty skeptical of invasive behavioral data like mouse movements. It feels like a popular meme from an earlier time, jiggle your mouse more before clicking the CAPTCHA checkbox, but in practice it's not a very high-value signal anymore (especially with the rise of mobile). TLS fingerprinting is a significantly more useful signal for us at Stytch.