Comment by vlovich123
5 months ago
That still doesn’t explain why you can’t even start typing until that check proceeds. You could condition the outbound request from being processed until that’s the case. But preventing from typing seems like it’s just worse UX and the problem will fail to appear in any metrics you can track because you have no way of measuring “how quickly would the user have submitted their request without all this other stuff in the way”.
Said another way, if done in the background the user wouldn’t even notice unless they typed and submitted their query before the check completed. In the realistic scenario this would complete before they even submit their request.
I developed the first version of Google's equivalent of this (albeit theirs actually computes a constantly rotating key from the environment, it doesn't just hard-code it in the program!).
The reason it has to block until it's loaded is that otherwise the signal being missing doesn't imply automation. The user might have just typed before it loaded. If you know a legit user will always deliver the data, you can use the absence of it to infer something about what's happening on the client. You can obviously track metrics like "key event occurred before bot detection script did" without using it as an automation signal, just for monitoring.
That doesn't make sense. The server would wait to process anything until after you received the signal. If it doesn't arrive within a reasonable period of time that tells you something, the same as right now.
If you mean that you can infer client side tampering with the page contents you could still do that - permit typing but don't permit the submit action on the client. The user presses enter but nothing happens until the check is complete. There you go, now you can tell if the page was tampered with (not that it makes much difference tbh).
The typing actions have to be observed by JavaScript. It's not different to any other JS blocking page load because it's needed for the site to work, that's just how the web works.
8 replies →
This perfectly explains the trade-off. But from a pure UX perspective, freezing the input pipeline feels uniquely hostile. They could buffer the keystrokes invisibly in the background instead of locking the cursor, which creates the jarring perception that the site is actively fighting the user.
can you reformulate your message?
Mike is saying that if you allow users to type before the scripts are fully loaded, there is no way to tell the difference between a human and bot.
Blocking until load means that human interaction is physically impossible, so you are certain that any input before that is automated.
If you allow typing, this distinction vanishes
1 reply →
[dead]
[dead]
Many cloud products now continuously send themselves the input you type while you are typing it, to squeeze the maximum possible amount of data from your interactions.
I don’t know whether ChatGPT is one of those products, but if it is, that behavior might be a side effect of blocking the input pipeline until verification completes. It might be that they want to get every single one of your keystrokes, but only after checking that you’re not a bot.
It's still possible to let users already type from the beginning, just delay sending the characters until checks are complete. Hold them in memory until then.
Instagram was uploading the images while the user were adding post details, back in 2012!
https://news.ycombinator.com/item?id=3913919
No one seem to use or care about their own product anymore. Only uses dashboard and metrics, which does not explain the full situation.
3 replies →
I just checked the network inspector, the only thing it does per key press is to generate an autocomplete list. It doesn't seem too hard to wait with the autocomplete generation until after whichever checks you run pass.
I wondered if ChatGPT streams my message to the GPU while I type it, because the response comes weirdly fast after I submit th message. But I don't know much about how this stuff works.
Likely prefix caching among many other things
You cannot know what verifications they use. I could argue the disabled textbox is some sort part of the verification process. Humans will click on it while bots won't.
Seems like a trivially simple verification to defeat.
You can defeat all client side verification by definition if you know what verification is run.
Because the way they have the server architecture setup and how it loads the screen. You don’t even want all the bots hitting servers
Keyboard response feels 10x slower in ChatGPT Projects (possibly for reasons other than react state).
Sounds like anti-distillation to me. But, know what? Meh.
I’d be inclined to agree with the “meh” if their entire product weren’t built off pirated content
[flagged]
Remember you’re talking to a vibe coder who just stares at code being printed out by AI.
That’s a big assumption. It’s a brand new account, might be a bot. PR/astroturfing is a great use case for agentic AI