You have an automated pipeline, that includes decompilation. I highly doubt the courts will see the nuance that you apparently do.
The pipeline begins with decompilation. Maybe it doesn't save all that information, but it is part of the pipeline, and so, will be part of the consideration when discovery happens.
... A clean room, means that you aren't reverse engineering. You're producing the same result, with zero awareness of the process, or it isn't a clean room.
LLMs are created through mass ingestion of data, and so, by definition, cannot be a clean room. They are trained on the things that they're tasked with copying.
It isn't that it will have been trained on the source code. The "decompilation" craze has it in the name... it is being done by decompiling the game and then modifying it. I don't think it's even a question as to whether or not the game companies are going to come down hard on this and I would not recommend to anyone that they jump up and volunteer to be the legal test case for that.
A clean-room implementation is going to be much, much more effort than a "decompilation". Even a decompilation is, I think, more than the hype is claiming. You can't just point at a game, say "decompile it and make it work on Windows" and get a result in one shot. It will take playtesting, cycling around, QA, and time to polish it up. But that will still itself be much easier than an actual clean room implementation. Let alone getting sued by the owner anyhow and having to prove it was clean room in a typical chaotic individual dev environment.
It's not though. We get the machine code for programs we run on our PCs. All the logic is provided to the end user. The only protection these days, is not doing all the game logic on the end users PC.
what possible reading of "I made the call to get these out early when exploits hit in the wild" contorts into "these exploits hit in the wild after i made the call to get these out early" with flipped causality?
sure, i'm happy to recant my rather tepid defense of chainguard in the case that what was said upthread was a blatant fabrication. i'm even open to being convinced that it was.
as it stands though, what i replied to wasn't a useful addition to the discussion. it could easily become so by either being made contingent upon the possibility of that being a lie, or being bundled with an assertion like yours that chainguard is not to be taken at their word. doing neither and simply responding as if a causally opposite statement had been made is just a non sequitur.
I don't think we have to not-believe Chainguard. To me, the problem is more that "in the wild" is a somewhat airy statement that can only be taken to strictly mean that one found it somewhere on a computer that is connected to other computers. This is almost a non-statement, as airgaps are the exception rather than the rule.
Even then, it implies more than it says. It's often used to suggest the exploit came from a remote system one does not directly control and was deployed, successfully, against another system one does not directly control. But even that does not necessarily have to be true, as people can use it, without any bad faith and not trying to twist the phrase, in cases where only one of those conditions hold, e.g. against a system one does directly control where the exploit attempt was unsuccessful.
Not a non sequitur - No one should be taken at their word. Not them, not me, and not you. This is the security world. Nobody is trusted altogether.
Breaching an embargo, makes reverse engineering easier. We don't need to analyse motives or pontificate. Disrupting the supply chain... Disrupts the supply chain.
I can affirm that I'm seeing vibe-coded dashboards designed to ingest and run on top of Excel spreadsheets full of macros, VBA, and "Excel Scripts" interlinks.
I... Cannot call this a step up. They're expanding, not replacing.
Sure, but at least Claude is available to fix the slop instead of needing to depend on people who have gone away a long time ago. ultimately if it's valuable they can invest in someone to come in and build things the right way.
And neither the original example is "Rust compiles extremely slowly" (it does compile slowly), it's another example of "vibecoded software is of poor quality".
This is a tough sell. Yes, those languages (with some small nits about Ada) can accomplish the same safety guarantees, but they're nowhere performant enough in practice or memory efficient compared to Rust. A big part of the original mission of Rust was safety without performance compromises which for the most part its accomplished, though the price is paid during compilation. Further, their runtimes and limitations make it difficult to work directly with operating systems or low level system hardware. And I say this as someone who has written Haskell code in production.
That said, I would love for Idris to continue to develop. I'm a big believer in dependently typed languages and would actually improve correctness, assuming there are reasonable ways to avoid the other trappings of the language.
"but they're nowhere performant enough in practice or memory efficient compared to Rust."
I would not include Ada, if you're benchmarking against Rust. Mostly because Ada either outperforms it (because it can reduce sizes in the optimiser), or it is equal to it.
Espressif did finally added back an FPU to the ESP32-S3. (The original ESP32 also has one).
They tried, with the H- and P- lines to effectively make it a paid extra over the regular productions. At least they accepted when the market disagreed.
The pipeline begins with decompilation. Maybe it doesn't save all that information, but it is part of the pipeline, and so, will be part of the consideration when discovery happens.
reply