Thanks for chiming in and linking that, that was an interesting read. As much as I understand CEF's reasoning for making this shift, it's baffling that they don't provide a universal way to implement what you now had to implement yourself.

My vibe coded apps tend to over sanitize inputs. Not sure what was the point of blaming LLMs.

LLMs weren’t blamed, vibe coders were blamed.

If you don’t know what you are doing any tool can be dangerous

>>> vibe-coded

>> My vibe coded apps tend to over sanitize inputs. Not sure what was the point of blaming LLMs.

> LLMs weren’t blamed … If you don’t know what you are doing any tool can be dangerous

If we're not talking about LLMs but instead about humans (who might be coding by hand, or from stackoverflow, or who might be using an LLM regardless of whether it frequently sanitizes by default), then shouldn't the original comment have more accurately referred to humans, as vibe-coding specifically refers to LLM use, right?

Does this even remotely matter? What’s the issue here?

Did you mean to reply to my comment? Was your issue with the original claim that lack of sanitization *"required"* "vibe-coded" functionality, or with someone disagreeing with that and pointing out how lack of sanitization can and does happen even for code that is 0% related to vibe-coding or LLMs (let alone "requiring" vibe-coding for it to occur)?

Read where "required" was in the comment you're flipping out about: it didn't say that the software had to be vibe coded, just that it was.

The RCE was caused specifically by a custom Claude generated overlay, so finding the RCE did require using this vibe coded software.

I did and I think you’re just coming across as very eager to defend LLM’s. Totally possible I am misreading your intention though

> the original claim that lack of sanitization "required"* "vibe-coded" functionality*

That claim was ever made. The comment was about actual pieces of software that exist in the real world, not about all possible software that could exist in theory.

In real-world usage, for a user to be exposed, a necessary ingredient was to use a particular piece of software that actually exists and that happens to be vibe coded.

That does not preclude the possibility that a non-vibe-coded piece of software could have been vulnerable. It's just that such a piece of software did not happen to exist.

So why even mention vibe coding? Presumably it's relevant for some other reason. Perhaps the implication is this vibe-coded software is not an established piece of software with lots of users. (Since vibe-coded software is easier to create, maintainers may be less invested in it or committed to maintaining it. Vibe coding changes the economics and opens up the possibility of creating throwaway software.) Or perhaps the implication is that users should be more careful about using vibe-coded software.

> tend to

Whew, thanks for putting my fears at rest. You're only pwned some of the time, not always.

As the FFmpeg devs like to say: if you don’t like how OSS volunteers do things, send patches or money, or just fork (off).

I will "tend to" send patches or money. We'll see how the belt-and-suspenders vibe goes.

Unfortunately, most streamers don't have the best IT security knowledge, and with AI tools now allowing them more and more than what was previously possible, it also opens the door for more vibe coded apps that could have serious security holes.

Should the streamers' apps be more secure? Absolutely, but the underlying tool should also strive to be secure enough for all use cases.

Anyway, thanks for the two links, they were interesting reads.

Thanks for sharing the reasoning!