If a security bug is exploited in the wild, it's an n-day if it's been first exploited n days after the publication of the bug, and a zero-day if it's been exploited before or on the day of the publication.
When a bug is not yet exploited in the wild, it's just a discovery of a bug, not a zero-day.
Let's see... first of all, 14 years ago was the discovery of the base mechanism, not of specific treatments. So specific treatments need to be developed, delivery systems need to be developed, side effects reduced. Then you need safety tests and efficacy tests.
> mRNA vaccines are also quite different. Do they modify the DNA? Of course not. So that's already very different.
And yet it took more than 30 years after the first mRNA experiments to develop a successful vaccine. Why it should be so much faster for CRISPR & Co?
CRISPR is foremost a research tool. Calling it "extremely overhyped" without restricting it medical treatment seems disingenuous.
The CRISPR-Cas9 gene-editing tool was developed in 2012, so I don't find it surprising that merely 14 years later, there's only one approved treatment. From discovery to approval, drug development often takes 10-15 years, and often much longer for novel techniques. So I'd say it too early to call it overhyped for treatments.
Finally, I think we'll see a lot of treatments that don't use CRISPR-Cas9, but related gene editing techniques, but it'll take another 10 to 20 years.
Take a look at https://en.wikipedia.org/wiki/MRNA_vaccine#History for how long another novel technique has been in development before it became really widespread with the mrna-based covid-19 vaccines.
You can target an individual by injecting that very individual with something lethal.
If that's not what you want, you'd need something like a virus to spread it. But then you have to ask yourself: what if that virus mutates? The specialization to certain gene markers is an evolutionary disadvantage, so evolution will tend to make it lose that restriction. Ooops.
> Much like other CRISPR therapies, delivery is a critical challenge, i.e., getting the large genome-cutting enzyme to all the targeted cells efficiently.
makes me think this is in vitro so far. So, years to decades away from being available for actual treatment in humans. Still good news.
Apple tries to market its product as privacy-focused, yet the privacy of their new AI features is so bad they don't meet EU standards? Is that the message here?
"Castor" was the name of a storage system used for transporting nuclear waste in Germany. There were quite a few protests against shipping nuclear waste through the country.
Wouldn't have been my choice for a software project :-)
As a side note, I wonder when we'll hear the first reports about employees reselling (parts of) their token budget.
Probably not worth it risking your job for a 200$/month good, but at 5K, I'm sure some folks will be tempted. Especially if companies do stupid things like token usage leaderboards.
Is it, though? Most Ferraris aren't driven much at all. In fact, most Ferraris are bought by collectors. If somebody has 10-20 Ferraris, do you think they drive them much? In Parallel?
* Chances are that fewer people (maybe even none) will look at the code when it's LLM-generated
* Amount of code being written isn't all that critical anymore
* Keeping patches small isn't that big of a deal anymore (because it's now the LLM's job to maintain it, not the human's)
All of this implies: boilerplate isn't a good reason to avoid a language anymore. (I hate this conclusion, because I hate boilerplate).
Then the question is: what kind of language can you use that buys safety with boilerplate? Probably a statically typed one, possibly with lots of asserts... Eiffel? I don't know if there's enough Eiffel code around the Internet to train LLMs, so maybe a more popular one would be better.
Maybe Java or C#? Haskell? OCaml?
The article suggests golang, and I think there are use cases where golang would be a good candidate.
It would be quite interesting to run an experiment: give separate instances of the same LLM coding agent the task to implement a specific application, and use different languages. Then compare quality, code size, runtime performance and token cost. Ideal would be a multi-stage development that better simulates a real development workflow (bug reports and new feature requests come in over time).
> Software developers should shorten their patch cycles and make security fixes available as quickly as possible. [...]
> Network defenders should shorten their patch testing and deployment timelines.
Shortening patch cycles will only help so much. It's funny that whenever an NPM supply chain attack is published, people recommend a cooldown before installing new versions, and then when a vulnerability is discovered, everybody jumps to patch. Clearly these two strategies collide at some point.
> The critical controls laid out by organizations like the National Institute of Standards and Technology and the UK’s National Cyber Security Centre are now all the more important, since they improve security without depending on any single patch landing in time. These include steps like hardening networks’ default configurations, enforcing multi-factor authentication, and keeping comprehensive logs for detection and response.
Most of these proposed controls are not new at all, but they are often costly to implemented and harm velocity in other ways, which is why they aren't widely in place.
For example, a super effective control is filtering outgoing network traffic. Many exploits rely on loading second and maybe third stages from the Internet, and if you block outgoing requests by default, it won't work.
But, blocking outgoing requests by default is super hard, and you risk blocking security updates etc. It can kinda work for a deployed application, but for an employee workstation? Basically impossible.
I wonder if we're approaching an era where we have to go back to saying "you cannot do this, because security" much more often than we'd like.
It matters in so far as the production rate for e.g. air defense interceptors is much lower than the rate at which they've been used in the Iran war. Which is probably one of the reasons the US was ready for a ceasefire.
They might have enough stockpiles to continue this war for a while, but it thins out the capabilities in other theaters, making the US generally more vulnerable.
You don't need to sink a carrier to make it more of a liability than an asset.
If you hit its radar systems and/or damage the surface enough that landing becomes impossible, it becomes a sitting duck.
> That said, I wonder why you don't see Ukraine and Russia doing this more -- "saving up" for massive clouds of long range strike drones every couple weeks
To some degree, this happens. Journalists reporting from Ukraine already talk about some nights being silent, and then there are strikes with 600 drones or so. On the other side, Ukraine was really effective at using naval drone swarms to attack Russian naval ships.
Why not send even bigger swarm? I guess there are limits to how many drones you can effectively control at once. Data links saturate, and you risk losing a big swarm to jamming.
When Russia really wants to destroy a target in Ukraine, they use ballistic missiles, their interception rate is pretty low. Ukraine seems also pretty effective at destroying things in Russia, so air defense doesn't seem to be such a huge obstacle.
Finally, it feels like the Russia-Ukraine war is turning more and more into an economic battle. Ukraine is now at the point where money is more limited than weapons / ammunition, at least for some types of weaponry. Would saving up drones for a huge wave be a big economic advantage?
Are there any pre-built Linux binaries for this? I tried to install it with cargo, but got "feature `edition2024` is required" (which is the newest cargo available from my current Ubuntu distro).
Also, can I configure zerostack to always require a sandbox? I don't want to accidentally forget to call it with --sandbox.
If a security bug is exploited in the wild, it's an n-day if it's been first exploited n days after the publication of the bug, and a zero-day if it's been exploited before or on the day of the publication.
When a bug is not yet exploited in the wild, it's just a discovery of a bug, not a zero-day.