berkes

Indeed. And this is also why I've never once believed the "no-code" would replace developers. And why I see a clear role for software (prompt-, context- ?) engineers at least for a while.

I've worked for CEOs and managers that would insist on ridiculous ideas. Like that time a CEO (let's call him Cedric) came in with a printed powerpoint slide that had a screenshot of the website with a "login form" drawn on top of it.

Cedric: "I need you guys to put this onto that scrunt board thing and make this before friday".

Me (tech lead at that time): "But what features would users need login for? Where or whom needs the profile data? We'd need to work this out in detail and plan it. Certainly not even this month".

Cedric: "I don't know, it's for you to figure out". and then "It can't be hard, it's just two squares one for a username one for a password" (he forgot about the submit-button, the third "square", he didn't even fathom the idea that something has to lie "behind" the "squares").

I recall this anecdote whenever I feel anxious about whether soon "stakeholders" can just chat to an AI agent and have it build features, rather than hire me to do so. Sure, a lot of them will be able to. But there's always Cedrics. Those who not only fail to communicate their ideas in a way that even an AI agent would understand, they lack any understanding of what tradeoffs of their requested features are.

The Cedric's would be happy with an AI agent that complies and starts churning away. An agent that blindly accepts any request and builds feature upon feature. Making their product worse in every sense: unusable, unmaintainable, debt-ridden, security-nightmares.

Their agent will build features that are plain illegal. Or features that users hate, or confuse them. It will oblige requests that drive users away, or changes parts that users/integrations rely on. Their AI agent will gladly add a "form" to extract all PII from their database, but on request, will remove the authorization from it. Because "you are absolutely right. If we don't link to the page from the menu, no-one can reach it".

I'm not making the last one up. Another "Cedric" alike recently hired me to look at his vibe-coded app because his go-to developer gave up and dropped the project. It had loads of such extractors, dashboards and overviews. Online. Unauthenticated. His claude, however, did add the pages to the sitemap, so a customer found their private data on google and contacted "Cedric", after which he asked me.

No, AI is getting smarter, but as long as the "Cedrics" remain as stupid as ever, I don't fear for my job.

These idiots can't.

Because all the exchanges they'd use are regulated in some form and at least adhere to anti-moneylaundering-directives and boycotts, or they can't operate in the US and/or EU.

Sure, they could move to p2p exchanges or exchanges in unregulated jurisdictions, but that requires quite some effort and thought. Which, by definition, would exclude them from being "idiots".

There's signs that a few state actors are using cryptocurrencies to bypass sanctions and/or move wealth otherwise frozen. North Korea, Russia, Iran, etc.

And since sanctions make it hard(er) for them to buy crypto with fiat in the large amounts they need, it makes sense for them to steal it, or buy stolen assets.

If you want to exchange, that is buy or sell, you'll need such a "centralized" exchange. Same for trading.

So even those that keep their assets offline on an airgapped machine in a nuclear bunker, will occasionally move crypto assets on- and off these exchanges. And especially when you hold the crypto truly offline, it's a hassle to get it on- and off exchanges. So you'll probably keep several months worth of sales or buys before moving it.

Point being: even those that still believe in the "decentralized" currencies will have some of their assets on "centralized wallets", even if only for a short time.

And yes, I am aware that one can "decentralized" buy and sell for and to fiat. And yes, I am even aware that sometimes in some situations, one can even avoid exchanging to/from fiat to pay rent or gas. But that's far from practical and probably never attainable.

They indeed would not have had it, it would've been all stolen by now.

But I guess what you are trying to say, is that with current valuations, Mt Gox would've upped their game and would've moved to much more secure architecture and infra.

If so: I doubt it. At the time of the heist, they were still running largely from a PHP monstrosity, that was originally built to trade cards amongst hobbyists. The only thing one could say for the Mt Gox people (Mark Karpelès etc) is that at that time, things moved extremely fast. Tech and infra may be good to trade tens of thousands of $/year one day. But if weeks later you are now trading millions $/year, there's no catching up. In hindsight they should've realized their organization and tech wasn't up to it and should've closed down. Because keeping up was clearly impossible.

*disclaimer: I lost significant amounts at the heist, eventhough I never held more than strictly needed on an exchange.

I've been using it since February this year almost exclusively. Occasionally ran the same prompt through openrouter to check if it's "my context" or "the model" when I get a poor result.

Mistrals models aren't the best. They certainly are measurably worse when I run them "blank slate". That is: without skills, AGENTS.md, MCPs and so on. But who does that anyway?

Aside from these harnesses, I run many one-off agent threads. They run at most half an hour and fill the context window not even 20% before I stop and "handover". And I tend to be annoyingly demanding and nitpicky in my skills, AGENT.md, prompts and issues (that an agent uses as prompt).

In my workflow, the context is what makes or breaks how well the task is performed almost all of the times. Mistrals models aren't "the best" - some Chinese models are cheaper (with similar outcome), and anthropics' models outperform the output consistently but for 20x or more of the price of Mistral (that is: when using the API/token pricing). But Mistrals models are certainly "good enough". Good enough is good, too.

That's unnecessary political stereotyping.

But what does matter in Cuba, is Savings.

The country is in shambles, beyond bankruptcy, in cases literally starving. Because of it"international" sanctions. Severe shortages of petrol, water and energy.

So it wouldn't be surprising if, by moving the clock every year in just one direction, petrol, water and electricity is saved. And it wouldn't even be suprising if that actually happens.

On the only machine where I can still see this, I see a significant increase in bot-scanners - the stupid brute forcers just attempting /wp-admin and such. These are "fail2banned" - an ever growing list of urls and endpoints from software that I know I don't run: anything php, java, etc -, and what I see a (totally not structurally collected, unfortunately) significant increase in these bans.

I've seen this increasing since before the patches were released and PoCs became available and more usable.

My theory is that botnets are cranking up their scanning to have an up-to-date and large list of potential targets once they can reliably use the exploit to take over those targets.

Makes sense indeed, but then the quality nor the volume is the underlying problem, but the review process.

Apparently Wikipedia has good reasons to not change this process fundamentally, other than add extra filters at the start to try and detect low quality posts, based on attributes that show a correlation with low quality.

Sounds like a pragmatic, but far from ideal solution to me. Correlation is not causation.

If we leave out environmental (energy, datacenters, coolant) and political arguments (copyright stealing, private data harvesting etc.) even if we agree that those are "bad".

What then, is the problem of AI-Generated Content in Wikipedia?

> Fake or misleading citations have become a major worry.

Why is this not a standalone problem? Humans can fake and mislead in citations too, in fact, this is a major problem and has been so, for literally centuries in science.

> Being a place that was, in theory, free from AI slop has become part of Wikipedia’s identity.

Isn't this a separate issue in itself too? One of "quality". If AI generates poor quality content, than I would think the poor quality is the problem, not the producer of it.

The article mentions several times how hard it is to detect AI content. If it is that hard, then obviously AI is doing a good job and producing content that matches that of humans. Why then insist on one type of producer?

The crucial piece of my statement and my question is that such an exploit doesn't have to be on GitHub to exist.

Again: such exploits are typically not distributed, hosted or published on platforms like GitHub. But on forums, boards and shops on the dark or deep web.

In this case the decoding was done on the screenshots. So it deliberately avoids encoding information in the SVG itself.

Obviously. It may even be a key to a no longer active account.

Naturally "a stolen key" here means that the key has access to something worth stealing. And my point was that there's far more worth stealing than your users' private data which many companies don't value that much.

> Why are you speculating?

Because the PHP devs and the researchers all explicitly stated that they have PoCs that can exploit it. Are they lying? Exaggerating? Spreading FUD?

I am speculating as to why the ones who have the most information tell us something very different than a "random blogger who tried repos on github".

How do you know there is none? Because both the PHP devs themselves and the companies involved in the patches said they had working PoCs.

Do note that commonly a blackhat, or state operative will not chuck their code on github, but either try to sell it, or try to use it to quietly get footholds on strategic places.

It needs only one working exploit to invalidate this post entirely.

Even if there aren't any that work OOTB today, there may be tomorrow. Or in a week. They may improve over time. They may combine other vectors. They will probably not exist on Github but somewhere on the dark web as a .zip you pay for in Monero.

They will combine shodan with fingerprinting and other ways to find "older PHP versions". There will be brute force versions, that just try every home router for insecure NextCloud. And so on.

This is real. This is dangerous. This will be exploited. Because I am sure even after all the noise, (hundreds) of thousands of PHP servers won't be updated for weeks. Many running on a forgotten corner of the web, on homeservers, on a VPS that no-one has access to anymore, in a CI, in a company on the old desktop underneath Jim's desk, on a raspberry-pi everyone totally forgot about.

I am not familiar with this flag, but will it force, or at least alert these " consuming teams" that the enum they expected has changed?

A stolen key isn't just a key to your customers' private data.

It's a key to your creditcard. Your revenue will be wiped out if you get the AWS bill after hackers booted hundreds of GPU instances under your account, moved terabytes in your data-transfer budgetm, burned tens of thousands of CPU-minutes in github actions under your creditcard, or used thousands of $s worth of tokens with your AI provider.

PHP foundation also doesn't "Run" the apt or rpm packages, yet they certainly coordinated with debian, and other big distros to push the updates out timely.

Now I don't know what happened here. Maybe PHP foundation reached out to docker but got no help, maybe they simply forgot about docker as distributor of their software.

There's over 3 million downloads per month for the official PHP image. That may certainly not be "most PHP users". But still is a a lot of users.

I'm quite certain that your exact sentiment is why the images weren't updated immediately: I'm afraid PHP foundation doesn't see docker images as a particularly important distribution system.

There should be more interpreters or runtimes. Regardless of the language they are written in. Indeed a rustPHP, maybe a JPHP, cPHP, etc etc. There is zend, but AFAIK that's still using the "official" PHP under the hood. And there is or was hiphop. Not sure how that is going, though.

Because now a vulnerability in PHP affects practically 100% of the users. But with more diversity, it would affect only a part. And if one runtime proves insecure more often than another one, organizations have a choice to move to an interpreter that better fits their security needs.

Several tech stacks have this built in or available.

For my rust applications, I use "cargo audit" which checks all dependencies against the CVEs. For my typescript and javascript applications, deno audit and/or yarn npm audit.

For the rest of the stack `debsecan` does exactly what you want on Ubuntu: report CVEs for installed software.

> Are there structurally much safer ecosystems out there?

Several attributes make a safer ecosystem. An important one is diversity - technical diversity.

For an interpreted language, the runtime is important. Python has several runtimes, as does Ruby. Javascript also has several, from the few browsers, to node, deno and bun. PHP has for all practical purposes, only one. So if there's a security incident in PHP, it affects almost all users. But when e.g. JRuby has a vulnerability, it will affect only a fraction of the installed ruby applications.

For compiled languages, the tooling, libraries and runtimes is where diversity is important. With e.g. rust, the vast majority of CVEs come from libraries (crates). But since there often are several crates for a single concept, diversity helps mitigate here too.

Depends on how it is set up.

Many modern hosts run php in fcgi mode, where your app is a process that listens on some http port. And where the webserver is "just" a proxy and ssl termination. Shutting down the process is enough.

But traditionally, php was a module loaded into apache. Where apache not only handled ssl, http etc, but also compiled and ran php for you. With that setup, adding an html file, will keep the php runtime and app online.

I honestly don't. It was a real question.

The only times I had to use third party packages for basic stuff, was when developing embedded software on limited hardware.

Do you mean that for async we need third party runtimes like tokyo? Or that types and utilities that many other languages ship by default in stdlib, like http aren't in rusts?

I'm sorry for the tone of my post. It was meant as honest surprise, but I clearly see now how it sounds baity and provoking.

Same here. And for the dynamic content, I host dedicated, small services, or client side code.

Not only 10 years of no more security updates. But hosting static content is cheap, performant and sustainable. Bot literally (you can move the content anywhere, using any kind of server) and in energy sense.

While I understand it is not for everyone to write markdown files and run build commands, I strongly urge anyone with a WordPress or drupal site to give the various jamstacks, or static site builders and guis a test run.

No real stdlib? What are you talking about?

The risk is real and large.

And the work to clean up if you get compromised is massive.

What kind of company or organization is Reflection?

I think it is ever more important to realize who is releasing models rather than what the models do and how they compare.

Because models iterate at breakneck speed, looking at today's benchmarks is only useful for someone using the models today. Whereas if one builds a product on top of it, or commits to one for a project or team, the company or organization behind it, is far more important. Will they exist in a few months? Do they need a business-model? Are they subsidizing usage with venture capital and how long can they keep this up?

Is reflection a company? University lab? NGO?

Exactly my thought.

If you get access to a VM, it's not a "security vulnerability" if you then have access to that VM. This was the whole point, the product.

It's almost like returning a car after you bought it with the reason "When I open the door with my key, the door is open and anyone can get in".