berkes

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.