I think there's some value in providing a huge dictionary of things to test against, with tagging for what things are to help filter. This doesn't do a great job at it, and it would make 100x more sense as a library, but it's a little more than just string.contains().
Sure, but I’m not convinced that producing a blacklist and filtering system is that difficult. More importantly, it’s little things like this that slowly and insidiously degrade the user experience. Sure it starts with one 300ms API call, maybe most people won’t notice. But when you reach for solutions like this to every minor technical problem, the next thing you know it takes 5 seconds to sign-up.
My take on latency in general is this: You may just use the API to flag (not act) in an async way. This way, you can just alert/monitor and decide later whether or not to take any actions while keeping the flow non-blocking. Another approach would be to run it against existing handles to see what opportunities exist (ex: premium usernames, impersonators etc.).
Yes; I've gotten that request from another person on LinkedIn too for bulk checking existing usernames. Will work on releasing that shortly too. Thanks for being helpful and constructive all the way throughout the convo :)
Not a joke (I'm taking this in the spirit intended) but I can see there are TONS of things I need to be improving on:
1. latency: my original goal was to make it sub-10s but with checking for auth, cold starts, the actual lookup, couldn't get it to do better than 2-300ms. I need to improve this though and I will.
2. increased list size: currently, the lookup happens across 1.7million records (will go up to 2.5m in the next days/weeks) BUT I don't think that would ever cover ALL scenarios.
3. better categorisation
The problem with HTML and CSS is there are encapsulation boundaries where there shouldn’t be. Tailwind, by contrast, does not separate the layout from the styling; creating a more cohesive developer experience. Anyone making a point like this does not understand why Tailwind—and similar libraries—are superior to classical encapsulated HTML/CSS.
it really does have that AI writing style, and these are the sorts of bugs I imagine an AI could have found...I wonder if that's what they did (though they claim it was all manual source code inspection).
From reading it and mostly from the introduction, it felt like they rolled up their sleeves and really dug into the code. This was refreshing versus the vibe-coding zeitgeist.
I would be curious what AI tools assisted in this and also what tools/models could re-discover them on the unpatched code base now that we know they exist.
I can imagine they could have used AI to analyze, describe and map out what exactly happens in the code. Then again, it's Go, following the flow of code and what exactly is being checked is pretty straightforward (see e.g. https://github.com/hashicorp/vault/blob/main/vault/request_h... which was mentioned in the article)
> .I wonder if that's what they did (though they claim it was all manual source code inspection).
Give me one reason why they would do it by hand if they can automate is as much as possible. Vulnerability research is an area without any guarantees, you can spend months looking for bugs and find nothing. These guys are not stupid, they used LLMs trying to find whatever they could, they probably explored more blind alleys than we will know, and then got very good results. Many other companies are doing the same.
Edit: 300ms?!
reply