This is a perfect illustration of what cracks me up about the hyperbolic reactions to Mythos. Yes, increased automation of cutting-edge vulnerability discovery will shake things up a bit. No, it's nowhere near the top of what should be keeping you awake at night if you're working in infosec.
We've built our existing tech stacks and corporate governance structures for a different era. If you want to credit one specific development for making things dramatically worse, it's cryptocurrencies, not AI. They've turned the cottage industry of malicious hacking into a multi-billion-dollar enterprise that's attractive even to rogue nations such as North Korea. And with this much at stake, they can afford to simply buy your software dependencies, or to offer one of your employees some retirement money in exchange for making a "mistake".
We know how to write software with very few bugs (although we often choose not to). We have no good plan for keeping big enterprises secure in this reality. Autonomous LLM agents will be used by ransomware gangs and similar operations, but they don't need FreeBSD exploit-writing capabilities for that.
> We know how to write software with very few bugs (although we often choose not to)
Do we, really? Because a week doesn’t go by when I don’t run into bugs of some sort.
Be it in PrimeVue (even now the components occasionally have bugs, seems like they’re putting out new major versions but none are truly stable and bug free) or Vue (their SFC did not play nicely with complex TS types), or the greater npm ecosystem, or Spring Boot or Java in general, or Oracle drivers, or whatever unlucky thread pooling solution has to manage those Oracle connections, or kswapd acting up in RHEL compatible distros and eating CPU to a degree to freeze the whole system instead of just doing OOM kills, or Ansible failing to make systed service definitions be reloaded, or llama.cpp speculative decoding not working for no good reason, or Nvidia driver updates bringing the whole VM down after a restart, or Django having issues with MariaDB or just general weirdness around Celery and task management and a million different things.
No matter where I look, up and down the stack, across different OSes and tech stacks, there are bugs. If there is truly bug free code (or as close to that as possible) then it must be in planes or spacecraft, cause when it comes to the kind of development that I do, bug free code might as well be a myth. I don't think everyone made a choice like that - most are straight up unable to write code without bugs, often due to factors outside of their control.
> Do we, really?
Yes, or pretty close to it. What we don't know how to do (AFAIK) is do it at a cost that would be acceptable for most software. So yes, it mostly gets done for (components of) planes, spacecraft, medical devices, etc.
Totally agreed that most software is a morass of bugs. But giving examples of buggy software doesn't provide any information about whether we know how to make non-buggy software. It only provides information about whether we know how to make buggy software—spoiler alert: we do :)
There is a huge wetware problem too. Like if I can send you an email or other message that tricks you and gets you to send me $10k, what do I care if the industry is 100% effective at blocking RCE?
The social hack executed in digital space. 100% agree.
That software also often has bugs. It's usually a bit more likely that they are documented, though, and unlikely to cause a significant failure on their own.
building around bugs that you know exists but dont know where is also a part of it. Reliability in the face of bugs. The mere existence of bugs isn't enough to call the software buggy, if the outcome is reliable (e.g., a triple module redundancy).
For a silly example, see how Python programs have plenty of bugs, but they still (usually) don't allow for the kind of memory exploits that C programs give you.
You could say that Python is designed around preventing these memory bugs.
Then we can't do it. Cost is a requirement
Cost is a parameter subject to engineering tradeoffs, just like performance, feature sets, and implementation time.
Security and reliability are also parameters that exist on a sliding scale, the industry has simply chosen to slide the "cost" parameter all the way to one end of the spectrum. As a result, the number of bugs and hacks observed are far enough from the desired value of zero that it's clear the true requirements for those parameters cannot be honestly said to be zero.
> the number of bugs and hacks observed are far enough from the desired value of zero
Zero is not the desired number, particularly not when discussing "hacks". This may not matter in current situation, but there's a lot of "security maximalism" in the industry conversations today, and people seem to not realize that dragging the "security" slider all the way to the right means not just the costs becoming practically infinite, but also the functionality and utility of the product falling down to 0.
I know a lot of security researchers will disagree with this notion, but I personally think that security (& privacy, I'm going to refer to both as "security" for brevity here) are an overhead. I think that's why it needs to exist *and be discussed* as a sliding scale. I do find a lot of people in this space chase some ideal without a consideration for practicality.
Mind, I'm not talking about financial overhead for the company/developer(s), but rather an UX overhead for the user. It often increases friction and might even need education/training to even make use the software it's attached to. It's much like how body armor increases the weight one has to carry and decreases mobility, security has (conceptually) very similar tradeoffs (cognitive instead of physical overhead, and time/interactions/hoops instead of mobility). Likewise, sometimes one might pick a lighter Kevlar suit, whereas othertimes a ceramic plate is appropriate.
Now, body armor is still a very good idea if you're expecting to be engaged in a fight, but I think we can all agree that not everyone on the street in, say, a random village in Austria, needs to wear ceramic plates all the time.
The analogy does have its limits, of course ... for example, one issue with security (which firmly slides it towards erring on the safe side) as compared to warfare is that you generally know if someone shot at you and body armor saved you; with security (and, again, privacy), you often won't even know you needed it even if it helped you. And both share the trait that if you needed it and didn't have it, it's often too late.
Nevertheless, whether worth it or not (and to be clear, I think it's very worth it), I think it's important that people don't forget that this is not free. There's no free lunch --- security & privacy are no exception.
Ultimately, you can have a super-secure system with an explicit trust system that will be too much for most people to use daily; or something simpler (e.g. Signal) that sacrifices a few guarantees to make it easier to use ... but the lower barrier to entry ensuring more people have at least a baseline of security&privacy in their chats.
Both have value and both should exist, but we shouldn't pretend the latter is worthless because there are more secure systems out there.
The question was not if it was possible within price boundary X, but if it was possible at all. There is a difference, please don't confound possibility with feasibility.
Is having problematic features that causes problems also a requirement?
The answer to the above question will reveal if someone an engineer or a electrician/plumber/code monkey.
In virtually every other engineering discipline engineers have a very prominent seat at the table, and the opposite is only true in very corrupt situations.
Unlimited budget and unlimited people won't solve unlimited problems with perfection.
Even basic theorems of science are incorrect.
Also people keep insisting on using unsafe languages like C.
It depends on exactly what you are doing but there are many languages which are efficient to develop in if less efficient to execute like Java and Javascript and Python which are better in many respects and other languages which are less efficient to develop in but more efficient to run like Rust. So at the very least it is a trilemma and not a dilemma.
The language plays a role, but I think the best example of software with very few bugs is something like qmail and that's written in C. qmail did have bugs, but impressively few.
Write code that carefully however is really not something you just do, it would require a massive improvement of skills overall. The majority of developers simply aren't skilled enough to write something anywhere near the quality of qmail.
Most software also doesn't need to be that good, but then we need to be more careful with deployments. The fact that someone just installs Wordpress (which itself is pretty good in terms of quality) and starts installing plugins from un-trusted developers indicates that many still doesn't have a security mindset. You really should review the code you deploy, but I understand why many don't.
> if less efficient to execute like Java and Javascript and Python
One of these is not like the others...
Java (JVM) is extremely fast.
JVM is fast for certain use cases but not for all use cases. It loads slowly, takes a while to warm up, generally needs a lot of memory and the runtime is large and idiosyncratic. You don't see lots of shared libraries, terminal applications or embedded programs written in Java, even though they are all technically possible to do.
The JVM has been extremely fast for a long long time now. Even Javascript is really fast, and if you really need performance there’s also others in the same performance class like C#, Rust, Go.
Hot take, but: Performance hasn’t been a major factor in choosing C or C++ for almost two decades now.
I think this discussion distracts a bit from the main point.
The main point is that there are super widespread software systems in use that we know aren't secure, and we certainly could do better if we (as the industry, as customers, as vendors) really wanted.
A prime example is VPN appliances ("VPN concentrators") to enable remote access to internal company networks. These are pretty much by definition Internet-facing, security-critical appliances. And yet, all such products from big vendors (be they Fortinet, Cisco, Juniper, you name it) had a flood of really embarrassing, high-severity CVEs in the last few years.
That's because most of these products are actually from the 80s or 90s, with some web GUIs slapped on, often dredged through multiple company acquisitions and renames. If you asked a competent software architect to come up with a structure and development process that are much less prone to security bugs, they'd suggest something very different, more expensive to build, but also much more secure.
It's really a matter of incentives. Just imagine a world where purchasing decisions were made to optimize for actual security. Imagine a world where software vendors were much more liable for damage incurred by security incidents. If both came together, we'd spend more money on up-front development / purchase, and less on incident remediation.
> No matter where I look, up and down the stack, across different OSes and tech stacks, there are bugs.
I’m not sure I’d go quite as far as GP, but they did caveat that we often choose not to write software with few bugs. And empirically, that’s pretty true.
The software I’ve written for myself or where I’ve taken the time to do things better or rewrite parts I wasn’t happy with have had remarkably few bugs. I have critical software still running—unmodified—at former employers which hasn’t been touched in nearly a decade. Perhaps not totally bug-free, but close enough that they haven’t been noticed or mattered enough to bother pushing a fix and cutting a release.
Personally I think it’s clear we have the tools and capabilities to write software with one or two orders of magnitude fewer bugs than we choose to. If anything, my hope for AI-coded software development is that it drops the marginal cost difference between writing crap and writing good software, rebalancing the economic calculus in favor of quality for once.
> I’m not sure I’d go quite as far as GP, but they did caveat that we often choose not to write software with few bugs. And empirically, that’s pretty true.
Blame PMs for this. Delivering by some arbitrary date on a calendar means that something is getting shipped regardless of quality. Make it functional for 80% of use, then we'll fix the remaining bits in releases. However, that doesn't happen as the team is assigned new task because new tasks/features is what brings in new users, not fixing existing problems.
I don’t disagree but is the alternative unbounded dev where you write code until it’s perfect? That doesn’t sound like a better business outcome. The trade off can’t be “take as long as you want”
“The alternative is that nothing will ever get released because devs will take forever making it perfect” is a really lame take.
We have literally countless examples of software that devs have released entirely of their own volition when they felt it was ready.
If anything, in my experience, software that’s written a little slower and to a higher standard of quality is faster-releasing in the long (and medium) run. You’d be shocked at how productive your developers are when they aren’t task-switching every thirty minutes to put out fires, or when feature work isn’t constantly burdened by having to upend unrelated parts of the code due to hopelessly interwoven design.
I'm happy to be reoriented with examples. Please provide some? You said countless but mentioned none.
I'd say SQLite is one good example:
https://sqlite.org/chronology.html
Regular releases for over a quarter of a century now, and it's renowned for its reliability.
tex was pretty bug free.
I think PMs fail to understand categories of change in terms of complexity because they focus on the user facing surface and deal in timelines. A change that brings in a big feature can be straightforward because it perfectly fits the existing landscape. A seemingly trivial change can have lot of complexities that are hard to predict in terms of timelines.
There is also the angle of asking for estimate without allocating time for estimation itself.
For lack of a better word, I think it should drive from "complexity". Hardness of estimate should be inversely proportional to the complexity. Adding field to a UI when it is also exposed via the API is generally low complexity so my estimate would likely hold. We can provide estimate for a major change but the estimate would be soft and subject to stretch and it is the role of the PM to communicate it accordingly to the stakeholders.
Some coding doesn't fit your schedule. If you've scheduled 2 weeks, but it takes 3, then it takes 3. Scheduling it to take 2 does nothing to actually make the coding faster.
3 sounds fine.
Then I ask: why not add a week to how long that thing will take, meaning it stretches two sprints (or whatever you call it).
Add upfront. Then if you get to hard convo where someone says “do it sooner” you say “not possible.”
The fundamental problem remains: it’s difficult to predict how long it will take to solve a series of puzzles. I worked in a dev group where we’d take the happy path estimate and double it… it didn’t help much. So often I’d think something would take me a week, so two walls was allotted, but I made a discovery in my first like hour/day whatever that reduced the dev time to like a couple days. Then, there were tasks that I thought I’d solve in a few days that took me weeks because I couldn’t foresee some series of problems to overcome. Taking a guess and adding time to it just shifts the endpoint of the guess. That didn’t help us much.
That's the point I am making, and the point of asking "what is the alternative"
Developers aren't alone in adhering to schedules. Many folks in many roles do it. All deal with missed deadlines, success, expectation management, etc. No one operates in magical no-timeline land unless they do not at all answer to anyone or any user. Not the predominant model, right?
So rather than just say "you can blame the PMs" I'd love to hear a realistic-to-business flow idea.
I am not saying I have the answers or a "take". I've both asked for and been asked for estimates and many times told people "I can't estimate that because I don't know what will happen along the way."
So, it's not just PMs. It's the whole system. Is there a real solution or are we pretending there might be? Honest inquiry.
Software release dates are so arbitrary though. We no longer make physical media that needs time to make and ship. Why does software need to be released on February 15th instead of March 7th?
> Why does software need to be released on February 15th instead of March 7th?
Because it has to be released at some point, and without picking a point in advance, you can never reach it.
You could ask the same question about the contents of the release. Why does software need to be released with features X, Y, and Z on March 7th when it could be released with features X and Y on February 15th?
It's inevitable that work will slip. That doesn't necessarily mean the release will slip. Sometimes you actually need the thing, but often the work is something you want to include in the release but don't absolutely have to. Then you can decide which tradeoff you prefer, delaying the release or reducing its scope.
You assume that PMs will just accept whatever estimate you give and not just say 2 weeks from the off and refuse to budge.
So, could you say "ok, but I still can't do that"
In this day and age of code-in-bulk enabled by AI, they will find someone who does in a blink of an eye.
> Do we, really?
Formal verification to EAL7[0] in theory, as long as your requirements are correct.
In practice I'm not aware of any bugs being discovered in any EAL7 software, but it's so expensive there isn't a lot of it.
> Do we, really?
Yes. There’s a ton of lessons learned, best practices, etc. We’ve known for decades.
It’s just expensive and difficult. Since end-users seem to have no issue, paying for crud, why bother?
>>> often due to factors outside of their control.
That’s the beauty of OSS - the level we could write code is way less than the level the culture / timescale / management allows. I recently saw OSS as akin to (good) journalism for enterprise - asking why is this hidden part of society not doing the minimum (jails, corruption etc).
Free software does sooo much better compared to much in-house it is like sunlight
> > We know how to write software with very few bugs
> Do we, really? Because a week doesn’t go by when I don’t run into bugs of some sort.
I mean, we do know how to do it, but we don't because business needs tend to throw quality under the bus in exchange for almost everything else: (especially) speed to develop, but also developer comfort, feature cram, visual refreshes, and so on always trump bugs, so every project ends up with bugs.
I have a few hobby projects which I would stick my neck out and say have no bugs. I know, I'm going to get roasted for this claim, but the projects are ultra simple enough in scope, and I'm under no pressure to ever release them publicly, so I was able to prioritize getting them right. No actual businesses are going to be doing this level of polish and care, and they all need to cut corners and actually ship, so they have bugs. And no ultra-complex project (even if it's done with love and care) is capable of this either, purely due to its size and number of moving parts.
So, it's not like we don't know how to do it, but that we choose not to for practical reasons.
The simplest recipe for writing "almost bug-free" software is:
If you do that, your program will asymptomatically approach zero bug.1. Freeze the set of features. 2. Continue to pay programmers to polish the software for several years while it is being actively used by many people. 3. Resist adding new features or updating the software to feel modern.Of course, your users will complain about missing features, how ugly and ancient your products look, and how they wished you were more like your buggy competitors.
And if your users are unhappy, then you probably lose the "used heavily by a lot of people" part that reveals the bugs.
There is no system without exploitable breaches, whether technical or social ones. The biggest point is, who have the incitives to exploit them, how much resources it costs to run a trial, how much resources do they control and are they ready to throw at attempts.
- [deleted]
We do.
The issue is almost always feature management.
Back in the days I was making Flash games, usually a 3-5 weeks job, with no real QA, and the project was live for 3-5 months. Every time I was ahead of schedule someone came with a brilliant idea to test few odd things and add couple new features that was not discussed prior. Sometimes literally hours before the launch.
Every time I was making the argument that adding one new feature will create two bugs. And almost always I was right about it.
Fast forward and I'm working for BigCo. Few gigs back I was working for a major bank which employed supper efficient and accountable workflow - every release has to be comprised of business specific commits, and commits that are not backed by explicit tickets are not permitted.
This resulted in team having to literally cheat and lie to smuggle refactors and optimizations.
Add to that that most enterprise projects start not because the requirements were gathered but because the budget was secured and you have a recipe for disaster.
> And with this much at stake, they can afford to simply buy your software dependencies, or to offer one of your employees some retirement money in exchange for making a "mistake".
LAPSUS$ was prolific by just bribing employees with admin access. This is far from theoretical. Just imagine the kind of money your average nation state has laying around to bribe someone with internal access.
I started to write a comment about how low they probably were able to bribe people for but found this article [0] which put the number higher than I expected:
> One of the core LAPSUS$ members who used the nicknames “Oklaqq” and “WhiteDoxbin” posted recruitment messages to Reddit last year, offering employees at AT&T, T-Mobile and Verizon up to $20,000 a week to perform “inside jobs.”
That said, this is but one instance and I'd imagine that on the whole they are able to bribe people at much lower numbers. See also: how little it takes to bribe some government officials.
[0] https://krebsonsecurity.com/2022/03/a-closer-look-at-the-lap...
The cost for access can be surprisingly low. Not all that many years ago it was pretty cheap to pay an editor at wiki or DMOZ or any of a few dozen other 'trusted sources' on the internet to get something added, or removed. I stopped traveling in those circles a long time ago, but I know that they are still very active and the cost is still surprisingly low.
While not code level access, these sorts of things are far more common than anyone wants to admit to.
If they were looking to access government back doors at these providers then it would not be your usual hack - and worth a lot more. I have no idea if this is how an entire domestic surveillance network got strung up, but it would make sense at those numbers (though those numbers still seem very low for such a betrayal and potential consequences)
I'm thinking those prices are just for large sets of phone number ports/clones to get past 2fa on valuable accounts.
And because it is surprisingly difficult to distinguish between 'oops' and 'malice' a lot of the actual perps get away with it too, as long as they limit their involvement. In-house threats are an under appreciated - and somewhat uncomfortable - topic for many companies, they don't have the funds to do things by the book but they do have outsized responsibilities and pray that they can trust their employees.
Also hard to track when the offending employee is a contractor or simply exits stage left to another company. Where he could also offer up his services to make another "blunder" that would grant access to these groups.
Another framing would be we will release your mother if you plant this backdoor. Could be a good plot for a short story? This attack vector has been available to Nation States since ages ago, stealing blueprints etc. Why are we acting surprised that this could be applied more effectively in digital age?
But on the other hand, adding LLM with strong guards (not yet here but doable for popular attack vectors) into the human loop can drastically eliminate insider factor, imho.
No, it just replaces one vector with another.
> they can afford to simply buy your software dependencies, or to offer one of your employees some retirement money in exchange for making a "mistake".
Orthogonal, but in similar spirits: the FAANG part of big tech paying less, doing massive layoffs, and putting enormous pressure on their remaining engineers might have this effect too in a less directly malicious way.
Big tech does layoffs, asks engineers to do "more". This creates a lot of mess, tech debt, difficult to maintain or SRE services. Difficult to migrate and undo, difficult to be nimble.
These same engineers can then leave for startups or more nimble pastures and eat the cake of the large enterprise struggling to KTLO or steer the ship of the given product area.
Keep in mind, the billionaires seem to think they can crash all this into the ground, and some how survive by buying their own miltaries.
The scale of how society works is lost on the greedy
"It resolved its C2 domain through an Ethereum smart contract, querying public blockchain RPC endpoints. Traditional domain takedowns would not work because the attacker could update the smart contract to point to a new domain at any time."
Does this mean firewalls now have to block all Ethereum endpoints?
> Does this mean firewalls now have to block all Ethereum endpoints?
Or, instead of attempting to enumerate the bad, if you run WordPress make sure it can't call out anywhere except a whitelist of hosts if some plugins have legitimate reasons to call out. Assuming the black-hat jiggery-pokery is server side of course.
If your Wordpress server had no reason to talk to Ethereum endpoints, then it should have never have been allowed to do so in the first place.
That is a never-ending game of whack-a-mole. There are infinite places to put command and control data.
The attack has to find the control nodes. Domains and IP addresses can be turned off. With this approach, there's no way to stop the finding process even after the attack has been reverse-engineered, short of firewalling or shutting down crypto nodes.
What happens when Ethereum gets a takedown order?
More generally, what happens as the malware ecosystem integrates with the cryptocurrency ecosystem?
Should something like a WordPress server not have a domain allowlist for outbound connections? Does WordPress need to connect to arbitrary domains?
> but they don't need FreeBSD exploit-writing capabilities for that.
That's a solid point. There was a piece the other day in the Register [1] that studying supply chains for cost-benefit-risk analysis is how some of them increasingly operate. And, well, why wouldn't they if they're rational (an assumption that is debatable, of course)?
[1] https://www.theregister.com/2026/04/11/trivy_axios_supply_ch...
>if they're rational (an assumption that is debatable, of course)
Feels like crime is an almost perfect simulation of the free market: almost/ all of the non-rational actors will be crowded out by evolutionary pressure to be better at finding the highest expected values, where EV would be something like [difficulty to break in] x [best-guess value of access].
This is a total tangent. However note that the creator of the ‘free market’ idea, Adam Smith, wasn’t an advocate for zero law/regulation regulation.
In fact Chapter 10 of his “Wealth of Nations,” specifically states, “When the regulation, therefore, is in favour of the work-men, it is always just and equitable.” He goes on to explain that regulation that benefits the masters can wind up being unjust.
Smith’s concept of ‘laissez-faire’ was novel back in the day. But by today’s standards, some of his economic opinions might even be considered “collectivist.”
I hate getting old because I can never remember this when it's relevant.
> They've turned the cottage industry of malicious hacking into a multi-billion-dollar enterprise
Thank you for this insight! Crypto truly is the financialization of crime.
These are vastly different scales though. “If North Korea wanted to, they could spend a lot of money and get into your system” is wildly different to “anyone with a few bucks who can ask ‘please find an exploit for Y’ can get in”
To be fair, the recent Axios supply chain attack was North Korea based, and probably cost them very little money. So it illustrates that you don’t have to “spend a lot of money” to get into our systems.
> it's cryptocurrencies
Its arguably the single worse thing to happen to infosec since the internet.
Yeah I tend to agree. For me Mythos' principal risk in my mind is saturation through being able to do bad things faster. Vulnerabilities are found and fixed - that's life. What is a problem is identifying and prioritising vulnerabilities. A miscategorisation or misidentification may lead to an extended attack window of a vulnerability. If a cloud provider, or multiple cloud providers are open to something there then everyone is in trouble. That's a pretty big nightmare scenario for me where I currently am.
Especially because you can potentially use a model like Mythos to figure out how to hide (from humans, at least) a deliberately created vulnerability.
>>> We know how to write software with very few bugs (although we often choose not to)
I see this as primarily a social issue - OSS projects are frequently free of the WTF bugs enterprise software can suffer from (things that one lone developer with access to their own OS would never do - call it “I can’t install X so no logging at all happens”) and frequently free of the bugs that a lone developer would slowly fix (call it “proof of concept got released because a rewrite would need approval” bugs). That alone removes entire classes of bugs before we it logic bugs and off by one errors.
The social cost of “is that honestly the best you can do” is enormous, and being part of a dysfunctional organisation allows human nature to stick on “in this place, in this culture - yes”
Chnaging that culture in a small team is possible - at scale it’s really costly
rogue nations such as North Korea
Is North Korea really a "rogue nation" anymore? What does that even mean when the US, which is currently led by a convicted felon, is literally and unapologetically stealing resources from places like Venezuela and Iran?
Maybe ask South Koreans what's their standing on the matter. Not everything is about USA.
Rogue nation = not under strict USA control.
If we wanted to treat words literally, the true rogue nation is USA. The only nation on earth to have actually dropped nukes on people. Have been prooved to spy on the entire world population. Plants coups around the globe. Invades any country they fancy in the name of democratization.
If that ain't a rogue nation I don't know what is
> This is a perfect illustration of what cracks me up about the hyperbolic reactions to Mythos. Yes, increased automation of cutting-edge vulnerability discovery will shake things up a bit. No, it's nowhere near the top of what should be keeping you awake at night if you're working in infosec.
Mythos will most likely not be the main thing that changes the infosec world, but AI in general will. Maybe in a few years or even decades, but I doubt it will just be another tool to have in our tool belt or another type of threat to consider.
> We've built our existing tech stacks and corporate governance structures for a different era. If you want to credit one specific development for making things dramatically worse, it's cryptocurrencies, not AI. [...]
One could argue it just accelerated everything. Without crypto it would still be possible to hack things and take the money out. It would require more manpower but it would be doable. Cash, wire transfers - nothing is perfectly secure. How are you going to prosecute someone in a foreign country like Russia or NK or even most Asian or African countries the West doesn't have strong relationships with? Even if you could, what's to stop the threat actors from bribing some poor person to take the fault if and when they're caught? If I'm a struggling farmer in Whateverstan, I'll happily take $50000 to give to my family in order to move millions to you.
And that acceleration of crime has positive aspects, too. Now a lot more people care about security. More care is given to making our infra and software in general more secure. Of course it's still insecure as shit, but I think it would be even more insecure if we didn't have cryptocurrency and the issues it brought with it.
Cryptocurrency has a few positives, too. Being able to drugs online (small, current positive) or to know that if shit hits the fan politically, we at least have the technological foundation to escape oppressive, corrupt and dysfunctional governments financially (big, potential positive), even for a while, until we get out shit together financially. It hasn't happened yet, but since even a lot of laypeople know about cryptocurrency, it's possible it could help some people somewhere in the future.
It's similar with privacy - if no one abused the data we gave them, we wouldn't have as many laws about data privacy and we wouldn't have as many people who care about their privacy. You can argue that we're at the point of no return because there are trackers and cameras everywhere, both public and private. That's similar, but a bit different since it's an already established infrastructure. It's harder to fight against something like that but if we do, we could still change it. Perhaps another acceleration in that direction is what we need - mass invasion of privacy so we can collectively wake up and dismantle the current status quo.
>we at least have the technological foundation to escape oppressive, corrupt and dysfunctional governments financially
Who is we? How many transactions of any cryptocurrency was either done to buy bread and butter?
IMO the thing that AI will change is the type of target. It's reasonable to assume that if you launch a website for a small business nowadays - sure, you'll get phishing attempts, port scans, attempts to submit SQL injections into your signup forms, etc.
But you won't get the equivalent of a sophisticated actor's spear-phishing efforts, highly customized supply chain attacks on likely vendor data, the individualized attention to not just blindly propagate when a developer downloads a hacked NPM package or otherwise gets a local virus... but to log into the company's SaaS systems overnight, pivot to senior colleagues, do crazy things like update PRs to simultaneously fix bugs while subtly adding injection surface areas, log into configuration systems whose changes aren't tracked in Git, identify how one might sign up as a vendor and trigger automatic payments to themselves with a Slack DM as cross-channel confirmation, etc.
The only thing holding this back from hitting every company is risk vs. reward. And when the likelihood of success, multiplied by the payout, exceeds the token cost - which might not happen with Mythos, but might happen with open source coding models distilled from it, running on crypto mining servers during times that minting is unprofitable, or by state actors for whom mere chaos is the goal - that threshold is rapidly approaching.
They're gonna shut the internet down by country
That there is a preexisting way for people to get hacked doesn't seem to be a reason to dismiss other, new ways for people to get hacked.
First, I'm not dismissing anything. I'm just saying it's not the most significant concern. Second, Mythos doesn't create "new ways". You already have plenty of vulns to go after, and you can write exploits for them (or pay someone). It just lowers the cost / commoditizes the toolkit. It's not the first time it has happened - the trend goes all the way back to Metasploit or before.
And again, I'm not saying it doesn't matter. All I said is that it's probably not the #1 thing to lose sleep over.
> This is a perfect illustration of what cracks me up about the hyperbolic reactions to Mythos.
The hyperbole was press released and consciously engineered. It consists entirely of the company who made Mythos, the usual captured media outlets who follow the leader, and the usual suspects from social media.
The reaction to it as if it is meaningful just fluffs it up more.
These are unprofitable companies trying to suck up maximum possible investment until they become something that the government can justify bailing out with tax money when they fail. Once you've crossed that line, you've won.
Some model that is super good at finding vulnerabilities will be run against software by the people trying to close those vulnerabilities far more often than by anyone trying to exploit them.
It reminds me a bit of the Segway hype "they'll build complete cities around these".
Sure, you can find problems faster, but it's not like they'll find 20 NEW classes of bugs.
What if gov shook up tech regulation a bit. Right now App Store is a bit of a weird gold standard for security, except that it is rife with scams.
What if regulators _required_ an independent app store where apps go through such stringent reviews that reviewers provide actual guarantees with underwriting (read: government backstop) that the thing is secure.
Any tool that is that good at vulnerability research is bound to have some killer capabilities in attack surface mapping and exploitation…
Which is not to disagree with the thrust of your point, I think: it’s even more about the fundamentals than it was yesterday. The bar for “secure enough” is what is being raised.
- [deleted]
Obligatory: https://xkcd.com/538/
Wealth odd distribution doesn't scale by definition. A malicious actor can possibly bribe some other actors, but they can't bribe them all. At large, the infosec nightmare should be society governed by corrupted plutocrats ruling pauperized populations through threat, lies and planned scarcity.
We know how to write software with very few bugs just as sure as we know how to structure societies with very few corrupted people. Although we just happen to often choose not to.
Rogue states can afford to bribe structurally weakened citizens, or to individually threaten them and their family to obtain the same kind of result with a probably cheaper and more scalable modus operandi.
They can also try to eliminate oligarchs of other nations, use all kinds of gouvernemental disruptions, threaten to or actually military attack other countries, or engage into straight genocides.
Evaluating what nations are not under a rogue state according to these criteria is left as an exercise.
Well, Cryptocurrencies are part of said new era. They aren't strictly a problem that made things worse: they're a technology that comes with tradeoffs. The cat is out of the bag and we have to design around technologies that are here to stay in whatever capacity. Distributed, cryptography-based currencies/tokens are one of those technologies.
Yes, on the one hand, they enable a lot of shady illegal business, but in the other hand, they also destroy the environment while doing it, so it's really a toss up whether cryptocurrency is good or bad overall!
bitcoin is forecast to uses about 150 TWh of electricity this year vs all other datacenter operations foretasted to use 1000 TWh. Bitcoin is esitimated to be about 52.4% sustainable energy (renewables plus nuclear) where datacenters are 42% sustainable energy.
And those other datacenters are mostly doing useful things, while bitcoin is somewhere between pure waste and the least efficient way of doing security ever conceptualized. (A few dozen centralized nodes, set up right, would likely be more secure than the current mining pools.)
Equating the concept of cryptographic currency with specific implementations such as proof-of-work just shows that you have no idea what you are talking about.
The importance of financial sovereignty can not be understated, whether you understand that or not.
Crypto has been an awful development in many ways, but I happily welcome it when it has made malware so much more benign to me. The last malware that affected me personally was a crypto miner worm, and the one before that was a crypto wallet stealer, neither of which affects me at all as I don't meddle with crypto.
I don't know the statistics, but it seems like it's way more profitable for the grifters to target other grifters instead of taking over my machines and extorting me. Or maybe I just got lucky.
> when it has has made malware so much more benign to me.
Eh?
Cryptocurrencies have enabled ransomware. Possibly the most nasty malware to hit the internet in terms of damage caused...
This damage has affected services you use (including hospitals, schools, research institutions and local government) even if it hasn't infected one of your boxen directly.
wow, I remember a time when hacker news had at least seemingly intelligent people and valid arguments.