Adversaries do not have to wait for LLM models to evolve to mimic human process, they can simply evade the detection JavaScript that evaluates similarity. JavaScript is visible, can easily be reverse-engineered.
I don't think I've ever known of a captcha that handles the actual result decision in the front end. It's universally just the javascript required for some fancy puzzle UI, which forwards the state to some other endpoint to determine where you're redirected to (CF turnstile) or what signed token should be included in the form request (reCAPTCHA)
I should have been clearer and specific: state management is done on the backend, but collecting behavioral biometrics and device fingerprint is done using JavaScript, which can be manipulated.
You can do it server side. But even so I would think this sort of heuristic detection is unreliable, annoying to real users, and not difficult to circumvent if the attackers actually tried.
Please also collect responses from people, you'd find a pattern: a new attack is launched, people make noise, and later go back to installing packages the same way. Enterprises already use private registries to combat such attacks, vulnerable folks include individual devs and small teams.
Same reason linux or databases need to be open source. A sandbox is not a nice to have or a feature anymore, it is as fundamental building block to running any software. You cannot depend on closed source building blocks, not as closed source product and especially not as open source product.
Cooldown sounds like a good idea ONLY IF these so called security companies can catch these malicious dependencies during the cooldown period. Are they doing this bit or individual researchers find a malware and these companies make headlines?
I am thinking about Django releases. They release a "Release Candidate", which you have to download by other means to test it. I rarely do it. But when a new official is out, I install it very easily in a testing environment and run my tests against it. I think this is what most people do, and the phase where supply attacks get caught, because in that 48 hour window all the tests in the world are run.
It's not a lack of care about privacy, the 7 days delay is like a new stage between RC and final release, where you pull for testing but not for production.
For researchers who notice new releases as soon as they are published and discover malice based on that alone, I agree, and every step of that can be automated to some level of effectiveness.
But for researchers who aren't sufficiently effective until the first victim starts shouting that something went sideways, the malicious actor would be wise to simply ensure no victim is aware until well after the cooldown period, implementing novel obfuscation that evades static analysis and the like.
Novel obfuscation, with a novel idea, is hard to invent. Novel obfuscation, where it is only new to that codebase, is easy(ier) to flag as suspicious.
While bad actors would be wise to ensure low-cooldown users are unaware, I would not say they can "simply" ensure that.
Code with any obfuscation that evades static analysis should become more suspicious in general. That's a win for users.
A longer window of time for outside researchers is a win for users -- unless the release fixes existing problems.
What we need is allowing the user to easily change from implicitly trusting only the publisher to incorporate third parties. Any of those can be compromised, but users would be better served when a malicious release must either (1) compromise multiple independent parties or (2) compromise the publisher with an exploit undetectable during cooldown.
Any individual user can independently do that now, but it's so incredibly time-consuming that only large organizations even attempt it.
Building automated analysis tool that help identify the use of GPL-licensed SDKs in mobile apps, promoting license compliance and supporting sustainable open-source development.
I opted for Bunny Shield exactly to combat bots, in particular ones that spoof User Agents and rotate millions of IPs. It works great, detecting the vast majority of bots and challenging them. Much more user friendly than Cloudflare too, which typically resorts to challenging everyone (not that CF was ever an option due to various concerns).
I also added various rate limits such as 1 RPS to my expensive SSR pages, after which a visitor gets challenged. Again this blocks bots without harming power users much.
* global distributed caching of content. This reduces the static load on our servers and bandwidth usages to essentially 0, and since it is served at an end point closest to wherever the client is, they get less latency. This includes user logged in specifics as well.
* shared precached common libraries (ie. jquery, etc) for faster client load times
* Offers automated minification of JS, CSS, and HTML, along with image optimization (serve size and resolution of image specific to the device user is viewing it from) to increase speed
* always up mode (even if my server is down for some reason, I can continue to serve static content)
* detailed analytics and reporting on usage / visitors
There are a lot more, but those are a few that come to mind.
reply