I am not a security researcher, but this combination does not align with "safe" to me.
More practically, if you are using a coding agent, you explicitly want it to be able to write new code and execute that code (how else can it iterate?). So even if you block Bash, you still need to give it access to a language runtime, and that language runtime can do ~everything Bash can do. Piping data to and from the LLM, without a runtime, is a totally different, and much limited, way of using LLMs to write code.
> write new code and execute that code (how else can it iterate?)
Yeah, this is the point where I'd want to keep a human in the loop. Because you'd do that if you were pair programming with a human on the same computer, right?
When I have paired, normally the other person can e.g. run the app without getting my review & signoff. Because the other person also is a programmer, (typically) working on their computer.
The overall result will be the product of two minds, but I have never seen a pairing session where the driver waits for permission to run code.
I am not sure it is reasonably possible to determine which Bash commands are malicious. This is especially so given the multitude of exploits latent in the systems & software to which Bash will have access in order to do its job.
It's tough to even define "malicious" in a general-purpose way here, given the risk tolerances and types of systems where agents run (e.g. dedicated, container, naked, etc.). A Bash command could be malicious if run naked on my laptop and totally fine if run on a dedicated machine.
It does not scale forever, and as you grow in throughput and job table size you will probably need to do some tuning to keep things running smoothly. But after the amount of time I've spent in my career tracking down those numerous distributed systems issues arising from a non-transactional queue, I've come to believe this model is the right starting point for the vast majority of applications. That's especially true given how high the performance ceiling is on newer / more modern job queues and hardware relative to where things were 10+ years ago.
If you are lucky enough to grow into the range of many thousands of jobs per second then you can start thinking about putting in all that extra work to build a robust multi-datastore queueing system, or even just move specific high-volume jobs into a dedicated system. Most apps will never hit this point, but if you do you'll have deferred a ton of complexity and pain until it's truly justified.
I guess I was really looking for concrete examples and examples prior to the invention of or not related to the use of electronic technology.
For your non-technological items in your list, I don't see how public school, rock and roll, and desegregation are or were remotely related to experiments being ran on children by society.
Public school -- new concept that caused massive changes to social behaviors and patterns of association. Nobody knew ahead of time what the results of this would be, so it was as much an experiment as letting kids access Instagram.
Rock & roll -- millions of people thought that letting children listen to this African American music would corrupt their children and prove ruinous to children. Some parents demanded controls on access to this music, much as some parents are doing with Instagram today.
Desegregation -- it's well worth an hour of reading if you haven't spent the time so far. Here I will just say that it was obviously a profound change in social patterns, changes to the US's legal caste system, and had to be enforced at gunpoint. Nobody knew how it would play out, like nobody really knows how using Instagram at age 15 will impact people in midlife. This led to (white) parental outcry over the prospective changes, as many (white) parents did not want to participate in this social experiment.
Big changes, no real control groups, unpredictable outcomes. Experiments in a very real sense.
I think it's a stretch to call those experiments of the same kind as those being ran by modern corporations with access to enormous amounts of data and direct connections to people and the ability to later influence based upon the experiments.
Who ran the rock and roll experiment? That example makes no sense.
Public schools and desegregation were constructed to better society, not as some nefarious way for some corporation to improve their profit lines.
I think you've really highlighted the extent to which irrational prejudice plays a role here, as two and a half of those examples involve racism. The US is one of a small number of societies which were ever racially segregated like that. It was in its own way a (failed) experiment.
(the UK has no shortage of racism, but it was never legally enforced!)
That's an unhelpful way of analyzing stuff because you can cynically retort "You've identified the group that would be incentivized to lobby for this" regardless of what happens. No age verification whatsoever? I bet social media companies would like that! Age verification by the government? I bet it's because the government wants to know what porn sites you visit! Maybe verification by the OS instead? Must be the Google/Android OS duopoly! So complicated PKI or zero knowledge proofs solution? There's probably some consultancy that would benefit, not to mention there's still going to be companies that would handle the outsourcing. There's a whole industry for handling user account management/SSO, for instance, and that's entirely open source.
I didn't look at it that way, but there is unfortunately a bit of truth in that analysis. Such is life in a captured state.
Honestly, I wasn't being quite that cynical. Just pointing out that there are actors who have business interests in applying a worse architecture.
But IIRC this was made manifest in Alabama, where a tech company lobbied for their age law and then captured the sole source contract for doing the verification.
This is the pool of mobile devs. If Microsoft is unwilling to eat the lead time (measured in weeks) for an existing native mobile dev to become productive on their stack, that's a sign of much bigger organizational problems.
Yup, coming from iOS and Android, I learned most of WinUI in two weeks, even before LLMs. GUI frameworks are largely similar, so there’s no real justification for reimplementing single-platform applications with HTML.
Kudos to them afaik they were trying to pay their people well. I think they were paying more than 100k/year. I remember they had open position for double that.
Sure, but even 200k/year is an order of magnitude less than 1.2mil/year (which is what the great-grandparent comment claimed, given their 100k/mo estimate).
Sincerely hope the Tailwind team can navigate this rough patch.
Frontend output from LLMs is (in my experience) subpar when compared to human-built components. However, I am not primarily a frontend dev. I would definitely pay for something that let me easily build frontends using vetted components, in ways they were designed to work together.
This seems like something that would sit solidly in the bailiwick of framework designers like Tailwind Labs. But it seems they primarily target frontend developers, so their focus is elsewhere.
> Nor do I understand the negative reactions to new restrictions on SNAP - candy and sugary drinks are no longer eligible
My understanding is that it adds a complex layer of regulation where one did not previously exist. Large retailers and grocers have the systems that can accurately track this. (Essentially: does your POS have the ability to sync with the Federally Approved Foods For Poors list or not.)
Smaller convenience stores (more common in places where poor people live) are less likely to have the resources be able to comply. Rather than get sanctioned for accidentally selling a Gatorade on SNAP, they will simply pull out of SNAP altogether. This means that even the non-sugary foods they have will no longer be available to people on SNAP.
The net effect is expected to be to remove SNAP purchasing ability from entire geographies. I understand the effect is expected to be most pronounced in rural and dense urban areas.
> file writes
> construct a `curl`
I am not a security researcher, but this combination does not align with "safe" to me.
More practically, if you are using a coding agent, you explicitly want it to be able to write new code and execute that code (how else can it iterate?). So even if you block Bash, you still need to give it access to a language runtime, and that language runtime can do ~everything Bash can do. Piping data to and from the LLM, without a runtime, is a totally different, and much limited, way of using LLMs to write code.
reply