Hieu_30

I watched someone click through four consecutive warning screens to approve a transaction last month, not because they didn't see them, but because they'd learned that most warnings are noise. Two were legitimate risk flags. Two were standard boilerplate that fires on nearly every transaction. From the outside, all four looked identical, red text, a button, a decision made in under a second.
That's the actual failure mode in warn-and-let-through security design, and it's not a UX polish problem. It's structural. A warning only stops someone who was already leaning toward stopping. Everyone else learns, transaction by transaction, that clicking through is what you do, and the warning stops functioning as a warning somewhere around the tenth time it fires on something harmless.
I used to think the fix was better warnings, clearer language, fewer false positives, more precise risk signals. Better warnings help, but they don't solve the actual mechanism of the failure. Even a perfectly calibrated warning still depends on a human reading it correctly and choosing right, every single time, under time pressure, often on a device optimized for speed over deliberation. That's a lot of weight to put on one moment of attention.
Hard-blocking removes that dependency at the specific moments where the cost of a wrong choice is high enough to justify it. Newton's policy checks resolve to a binary, the transaction settles because it satisfied the policy, or it doesn't, not a warning a user can dismiss. There's no click-through path around a failed policy check the way there's a click-through path around a phishing banner.
I don't think that makes hard-blocking the right default everywhere. Plenty of legitimate transactions look risky by some reasonable metric, and a system that blocks too aggressively just pushes users toward workarounds or abandons the product entirely. The judgment call isn't warn versus block in the abstract. It's which specific decisions are important enough, and clear-cut enough, to take the choice out of a rushed user's hands entirely, versus which ones genuinely need a human's context to resolve correctly.
That's actually a harder design question than it sounds, because it means admitting that user autonomy and user protection aren't always the same goal, and sometimes optimizing for one costs you the other. A warning preserves autonomy and mostly fails at protection once fatigue sets in. A hard block guarantees protection on that specific check and costs some autonomy on every transaction it touches, including the legitimate ones.
I don't think there's a clean universal answer to which side to pick. What I do think is that most of the industry has defaulted to warnings, not because warnings are the better tradeoff, but because they're the easier one to ship, and the phishing banner nobody reads anymore is the visible cost of that default.
So the question worth sitting with for anyone designing this: is the goal to inform the user, or to actually stop the bad outcome, because after enough repetitions, a warning stops being able to do both.
$NEWT #Newt @NewtonProtocol

Друг строил платежный продукт и в прошлом году получил кошелек, который был помечен риск-скоринговым API: кошелек заблокировали в процессе онбординга со счетом 87 из 100 и больше ничем. Никаких объяснений, списка сигналов, никаких возможностей обжаловать — только написать в поддержку и ждать. Оказалось, что этот кошелек принадлежал человеку, который много лет назад просто взаимодействовал с деактивированным DeFi-протоколом, никак не связанным с тем, что человек делал на самом деле.
Та история застряла у меня в голове, потому что счет был не совсем «неправильным». Он просто был непроверяемым. У команды друга не было способа понять, что именно его вызвало, невозможно было узнать, устарела ли модель, и невозможно было отличить реальный риск-сигнал от устаревшего шума, который алгоритм переносил дальше — и который никто не мог проверить.