3 ms·

I do. I care. And there are dozens of us. Lots of infected programs provide value. It has nothing to do with being or not being infected. If a project was vib

I do. I care. And there are dozens of us. Lots of infected programs provide value. It has nothing to do with being or not being infected. If a project was vibecoded in a weekend - there are less chances that it will still be maintained in a, say, year or two.

mvdwoord 6mo ago
But if it is open source you could maintain it? It could be "done" for a given state of affairs (protocol/API versions etc)?
- imcritic 6mo ago
  Such action has non-zero cost/effort. Do I really want to pay it? I am not sure.
- Leomuck 6mo ago
  Of course you could, but if it was indeed vibe-coded in a weekend, why wouldn't you want to start from scratch to make sure everything is up to your standards (especially security)? I'm definitely not going to jump in on a vibe-coded project. I'd much rather start from scratch if I found the use-case to be relevant. Not to say vibe-coded projects can't be alright. If the engineer behind it knows their stuff, it's fine to me. But we don't know that. So to get a general idea, I think it's fair to ask how this was done.
synotna 6mo ago
Don't give programs unnecessary access - problem solved
- imcritic 6mo ago
  That's a good advice in general to treat any software as untrusted black box as much as possible. But it raises (slightly, but still does) the cost/effort for the user: the user now has to make extra steps and take extra caution. These concerns were great valid even before vibecoding becoming a thing, but now the estimated probabilities of malicious code's presence have changed, simply because nowadays the cost/effort of writing software plummeted.
- d0liver 6mo ago
  Unnecessary access isn't a solveable problem. In order to restrict permissions to exactly what a program needs, in general, you'd have to define exactly what a program does. In other words, you'd need to rewrite the program with self-enforcing access restrictions. So, permissions are always going to be more general than what a program actually needs and, therefore, exploitable. Producing incorrect information is an insidious example of this. We can't simply restrict the program's permissions so that it only yields correct outputs -- we'd need to understand the outputs themselves to make that work. But, then, we're in a situation where we're basing our choices on potentially incorrect and unverified outputs from the program.

mvdwoord 6mo ago

But if it is open source you could maintain it? It could be "done" for a given state of affairs (protocol/API versions etc)?

imcritic 6mo ago
Such action has non-zero cost/effort. Do I really want to pay it? I am not sure.
Leomuck 6mo ago
Of course you could, but if it was indeed vibe-coded in a weekend, why wouldn't you want to start from scratch to make sure everything is up to your standards (especially security)? I'm definitely not going to jump in on a vibe-coded project. I'd much rather start from scratch if I found the use-case to be relevant. Not to say vibe-coded projects can't be alright. If the engineer behind it knows their stuff, it's fine to me. But we don't know that. So to get a general idea, I think it's fair to ask how this was done.

synotna 6mo ago

Don't give programs unnecessary access - problem solved

imcritic 6mo ago
That's a good advice in general to treat any software as untrusted black box as much as possible. But it raises (slightly, but still does) the cost/effort for the user: the user now has to make extra steps and take extra caution. These concerns were great valid even before vibecoding becoming a thing, but now the estimated probabilities of malicious code's presence have changed, simply because nowadays the cost/effort of writing software plummeted.
d0liver 6mo ago
Unnecessary access isn't a solveable problem. In order to restrict permissions to exactly what a program needs, in general, you'd have to define exactly what a program does. In other words, you'd need to rewrite the program with self-enforcing access restrictions. So, permissions are always going to be more general than what a program actually needs and, therefore, exploitable. Producing incorrect information is an insidious example of this. We can't simply restrict the program's permissions so that it only yields correct outputs -- we'd need to understand the outputs themselves to make that work. But, then, we're in a situation where we're basing our choices on potentially incorrect and unverified outputs from the program.