There is a whole subcommunity of highly respected physics quacks like that one guy from Lockheed obsessed with propellantless propulsion. They are very much into zero-point stuff and how they do it is semi litho.
I'd frame it such that LLM advice is best when it's the type that can be quickly or easily confirmed. Like a pointer in the right (or wrong) direction. If it was false, then try again - quick iterations. Taking it at its "word" is the potentially harmful bit.
In my experience (in our rather large MVC-style Laravel code base) DTOs are almost always an unnecessary abstraction. I'm much more content just shuffling actual Models around, with small methods that map these to whatever format the client then requires. I've refactored away many a DTO added by junior developers and the code is always much simplified.
Not probably, searching through plaintext (which they seem to be doing) VS iterating on the DOM have vastly different amount of work behind them in terms of resources used and performance that "probably" is way underselling the difference :)
Reminds me of the shortcut that works for the happy path but is utterly fucked by real data. This is an interesting trap, can it easily be avoided without walking the dom?
Yes, parse out HTML comments which is also kind of trivial if you've ever done any sort of parsing, listen for "<!--", whenever you come across it, ignore everything until the next "-->". But then again, these people are using AI to build scrapers, so I wouldn't put too much pressure on them to produce high-quality software.
It's not quite as trivial as that; one could start the page with a <script> tag that contains "<!--" without matching "-->", and that would hide all the content from your scraper but not from real browsers.
But I think it's moot, parsing HTML is not very expensive if you don't have to actually render it.
The regex approach is certainly easier to implement, but honestly static DOM parsing is pretty cheap, but quite fiddly to get right. You're probably gonna be limited by network congestion (or ephemeral ports) before you run out of CPU time doing this type of crawling.
I'd argue that the really old custom of providing the user a fixed username (e.g. user ID) upon registration, and requiring that for login, provides complete protection vs credential stuffing. It has other drawbacks of course, which is why you rarely see it in use anymore...
> Do you mean a username that is distinct from email or phone number?
No, he means a unique user id, generated by the server when you sign up for the service. Then for every login attempt, you provide the username/email + user id + password.
Because credential stuffing relies on the user reusing a username + password from another site. If you provide the user with a username they don't select, it won't be reused.
But then they have to remember the username AND the password? This doesn't help with users already having the password re-use problem. This would only work for those with a password manager, but then they are also less likely to re-use a password.
Also, wouldn't this prevent lost password recovery? if you can't identify a user by their email?
> But then they have to remember the username AND the password?
The commenter already acknowledged that the solution has drawbacks. The only claim made was that it solves credential stuffing, not that it doesn't inconvenience the user.
> This would only work for those with a password manager
It would also work for those without a password manager, because they'd have no choice.
> Also, wouldn't this prevent lost password recovery? if you can't identify a user by their email?
They're not mutually exclusive. You can have both. A compulsory unique user ID to login, and an email based password recovery mechanism.
I haven't used it for 45 years, but my CompuServe user ID was [72175,1425]. I like that they assigned it themselves with no input from me. (I'm cursed with a good memory for useless things.)
Yes, there are clear ergonomic reasons why we don't do this "assign a username" thing. But it would stop password stuffing.
You'd presumably do username recovery the same way you do password recovery, so it would only be accessible to an attacker who compromised the user's email.
