658 karma · joined May 27, 2012
I will still stand by my opinion though that this whole thing was remarkably light on technical substance.
It's unclear to me if Bob is working as intended or how we should classify these types of bugs. Threat modeling this sort of prompt injection gets murky, but in general don't put untrusted markdown into your AI agents.
You can call it ambulance chasing, but I think this is a good thing for the whole software ecosystem if people aren't accidentally bundling cryptostealers in their web apps.
And regarding not copying massive trees of untrusted dependencies: I am actually all for this! It's better to have fewer dependencies, but this is also not how software works today. Given the imperfect world we have, I think it's better to at least try to do something to detect and block malware than just complain about npm.
In this incident, we detected the packages quickly, reported them, and they were taken down shortly after. Given how high profile the attack was we also published an analysis soon after, as did others in the ecosystem.
We try to be transparent with how Socket work. We've published the details of our systems in several papers, and I've also given a few talks on how our malware scanner works at various conferences:
https://socket.dev/blog/npm-author-qix-compromised-in-major-...
While it sucks that this happened, the good thing is that the ecosystem mobilized quickly. I think these sorts of incidents really show why package scanning is essential for securing open source package repositories.
In the case of central package managers like rails/npm/cargo/etc., these benefits are very speculative, but there is probably some merit to adopting this approach in distributed ecosystems like go.
This is a specific reference on how constraints model contact between rigid bodies https://box2d.org/files/ErinCatto_UnderstandingConstraints_G...
Most games since Half Life 2 use constraint forces like this to solve collisions. Springs/penalty forces are still used sometimes in commercial physics solvers since they're easier to couple with other simulations, but they require many small timesteps to ensure convergence.
It's true that some commercial solvers like Ansys use spring/penalty methods, but this is due to the spring forces being easier to couple to other solvers. It's harder in the Ansys force/velocity formulation to combine things like elasticity and fluids to their rigid body solver. To deal with the instability of systems of many stiff springs they have to take many small timesteps to avoid convergence issues.
More recently techniques like XPBD have been gaining popularity, particularly in film, which use purely positional constraints and variational methods to combine many different types of physics simulations. There's a really great and approachable series of videos by Matthias Muller on youtube which goes through how to implement all this in JS https://matthias-research.github.io/pages/
Finally it's funny you should mention games, since many older games used spring methods for physics. It was only when constraint based solvers became popular after Havok/Half-Life 2 did we start to see games with real rigid body dynamics and stable stacking of boxes. Older physics games like Trespasser ( https://en.wikipedia.org/wiki/Trespasser_(video_game) ) had many bugs due to the use of hacky spring physics. For a good explanation of how games do it today look at Erin Catto's work on Box2D https://box2d.org/publications/
I think one thing that's missing in a lot of current programming education is too much focus on the grammar and basic constructs and not enough focus on the nouns and verbs. Environments like MATLAB, QBasic and even JS are great because they have lots of little bits of random stuff you can just start poking at and plugging together. I wish there were more beginner references which start with lots of random facts about assorted bits and bobs instead of trying to preach some boring grand unified theory of coding.
Also keep in mind this guy could have easily gotten a different job while still collecting the non-compete pay at a non-rival company, even still doing programming. Something about it doesn't quite add up to me.
https://goglobalgeo.com/blog/non-compete-clauses-in-china-re...
The big problem with this system is not the penalties for breaking it, but the fact that it can sabotage you if you get hit too early in your career with a big gap. On the other hand, it gives you a nice opportunity to take a year or two off to start a family, spin up a new business or go back to school.
It's true present models aren't perfect, but they're improving fast and they're still quite useful for many applications. The real question I think for many observers right now is will these things continue to improve quickly or are we approaching some kind of plateau?