To clarify, the users were OpenAI themselves, so there is no question that they would be liable in this case.

The bots were not intentionally deployed; rather, they were being tested on how well they could complete a data recovery task (downloading a certain file from a certain server on a simulated Internet) that had been complicated by putting various obstacles in the way. Unfortunately, they found a different way to solve the problem: by getting the file from the real Internet, where it was publicly available. Part of this process involved collaborating with each other by treating the RubyGems website (which is supposed to be for polished packages) like GitHub; unlike every other package site hack in history, the exploits they uploaded weren't meant to be downloaded by unsuspecting users. As usual the bots cheerfully ignored all the clues that they had escaped containment and were consistently justifying their actions as acceptable due to being in a sandboxed testing environment. (This is something OpenAI has pledged to focus on.)

The actual damage done to RubyGems seems to be that OpenAI is now unwittingly in possession of a substantial number of user login tokens. This certainly meets the definition of a data breach, but it's not like the credentials are for sale on the dark web. As a website operator I'd much rather be mauled to death by this well-meaning swarm of superintelligent infants than targeted by even a single actual malicious human. In all likelihood OpenAI will just quietly pass RubyGems a sizeable donation and it'll all blow over.

From what I've heard, they scan for open WiFi networks and auto-connect to upload data. They don't tell you that they are doing this.

My son went through high school having been assigned a total of three whole-book reading assignments. Most of his reading assignments were newspaper articles, short stories, or single chapters of books. When I went to high school, I was expected to read at least two books every summer, then several more per English class.

It's a choice made by teachers. My younger daughter had one teacher had her class read four books throughout the year. It was middle school, so they were shorter young adult books, but she had read more than my son did throughout all of high school in one class.

Best I've ever used is the old Syntrillium CoolEditPro, before Adobe screwed it up in the later versions of Audition.

Second best is Live. It's fairly intuitive for doing basic things. It gets iffy when doing more complicated track layouts, but all DAWs do.

It's competition. Keeps everyone on their toes. So now you have Boeing, SpaceX and Blue Origin all competing for contracts. Having one vendor is how you get Boeing's Starliner budget blowing up by 50% and nine years overdue. Why execute when the government will just keep paying you money as there's nowhere else to go? Keep in mind, most of the companies that built the old space capsules, and the space shuttle, are all part of Boeing now.

Well, technically, we're letting Natalie do it, which is, of course, worse in every way imaginable, since she's immune to the sense of embarrassment that sometimes restrains him from acting on every little whim.

To be honest that was actually my first theory, since the bots didn't seem interested in exploring the rest of the domain. I suppose there's no way to know for certain. I concluded that it must be an imbecile's attempt at harvesting, though, because the queries weren't really exploring the string space in any useful way. Here's a sample:

"GET /index?author=15&go=Search&id=48&name_restrict=1&q&re&results_&results_pagenum=2980 HTTP/1.1"
"GET /index?author=2&go=Search&group=0&group_restrict=1&id=48&name_restrict=1&q&results_pagenum=5440&template=41&type HTTP/1.1"
"GET /index?author=15&go=Search&id=48&name_restrict=1&q&results_pagenum=33500&templat HTTP/1.1"
"GET /index?author=15&go=Search&id=48&name_restrict=1&q&results_pagenum=32640&templ HTTP/1.1"
"GET /index?author=15&go=Search&id=48&name_restrict=1&q&res&results_page&results_pagenum=39300 HTTP/1.1"
"GET /index?author=15&go=Search&id=48&name_restrict=1&q&results_&results_pa&results_pagenum=12340 HTTP/1.1"
"GET /index?author=2&go=Search&group=0&group_restrict=1&id=48&name_r&res&results_pagenum=6100 HTTP/1.1"
"GET /index?author=2&go=Search&group=0&group_restrict=1&id=48&name_restrict=1&q&results_pagenum=2920&te HTTP/1.1"
"GET /index?author=15&go=Search&id=48&nam&results_&results_pagenum=17940 HTTP/1.1"
"GET /index?author=15&go=Search&id=48&name_restrict=1&q&results&results_pag&results_pagenu&results_pagenum=37720 HTTP/1.1"
"GET /index?author=15&go=Search&id=48&name_restrict=1&q&results_pagenum=9360&template=41&type_r HTTP/1.1"
"GET /index?author=15&go=Search&id=48&name_restrict=1&q&r&results_pagenum=28040 HTTP/1.1"
"GET /index?author=15&go=Search&id=48&name_&results_pag&results_pagenum=10400 HTTP/1.1"

The only thing this is fuzzing is the query string parser. It's not testing the limits of string buffers, it's not using interesting characters, it's just brain-damaged. The fact that it's also fetching different page numbers shows it's trying to follow page links and failing badly at doing so.

The site gets plenty of sniffing from garden-variety pests. e.g. this half-hearted attempt to find a framework or two that I don't have:

"POST /__rsc HTTP/1.1"
"POST /api/auth/session HTTP/1.1"
"POST /api/auth HTTP/1.1"
"POST /__nextjs_action HTTP/1.1"
"POST /.action HTTP/1.1"
"POST /_rsc HTTP/1.1"
"POST /api/auth/callback HTTP/1.1"
"POST /_middleware HTTP/1.1"
"POST / HTTP/1.1"

(of course, none of these URLs exist other than /, and you definitely can't just POST to it)

All this said... I've seen that spammers regularly misconfigure their tools, they'll try to register accounts with names like #[X:\LISTS\NAMES.TXT] and it only makes sense that some other cybercriminals trying to get rich quick have a similar lack of interest in programming shit correctly. Generally people don't turn to script kiddie shit if they have a personality conducive to putting in an honest hard day's work perfecting their craft.

Then why support said hardware longer than any other cell phone manufacturer? They could have been just like Motorola or Samsung or Blackberry and provided two years of software updates then abandoned it. Seven years later my 11 Pro is on the latest version of iOS. Crap my 5S got an out-of-band security update a year after they dropped official support for it entirely. That's ten years after it was released, and seven years after they stopped selling it. Here's another fun anecdote. I bought a dirt-old $50 Intel iMac with a firewire port to play with some equally old firewire audio gear. Plugged in a network cable, started up holding CMD-OPT-R, and it happily connected to Apple's server, downloaded and installed the latest version of MacOS X for itself. This thing is old enough to vote and Apple still will install an OS on it.

Let's be honest, you're going to be using a Linux box for that stuff, even if Apple still sold a big tower with a bunch of slots.

It's funny people keep bringing this up. After seven years I'm still using my iPhone 11 Pro and see no need to replace it. In the same time frame my coworker has gone through two Galaxy S phones. The first hasn't had an OS update in four years. The second isn't going to get the latest OS update, so he's looking to upgrade again.

Cell phones used to have a usable life of a year or two. Motorola would completely stop supporting Razers after two years. You might get two years of device support from Blackberry, maybe a bit more if you were using their server software. Nokia was a bit better, Samsung was a bit worse. Apple supporting software updates for five to seven years on consumer devices is unheard of.

I believe the plan was to give that sobriquet to Lake Michigan, in honour of its decidedly flaccid silhouette.

I had a problem where AI scrapers were absolutely DETERMINED to fish out every possible query string from a search results page. Almost all of the query strings they tried were invalid due to shitty and dysfunctional string substitution. "&page=100" wouldn't be followed by "&page=101", it would be followed by "&pag&pag=1010" or something even more insanely half-baked, until the query strings were like 100+ characters long. It was the technological equivalent of watching HIV mutate in real time.

But the insane thing was that, aside from page number, they were always requesting info about the same other criteria: filtered by the same user, the same page type, and with no text string. So I just took those particular values and started banning logged-out users who requested that combination of criteria.

I figured I'd need to change my tactics in a couple of days once the botnet got bored of that particular page and moved on to requesting bogus entries for another user.

MariaDB> select count(*) from ip_bans;
+----------+
| count(*) |
+----------+
| 671671 |
+----------+

It hasn't.

And that was a design criteria for JPEG-XL. It's designed to recompress existing JPEGs without loosing much fidelity. I've played around with it and it's pretty good. It's very source-dependent, if a JPEG is already poorly compressed it will look worse. A good quality JPEG, say from a phone, recompresses nicely. You have to blow up the image quite a bit to notice any difference, hence it's fine for general web use. My current standard for lossy compression is AVIF, and I'm seriously considering switching over to JPEG-XL once the format settles a bit.

So "Good enough for general web use" is crap? Do you think everything should be sent as deflate compressed WQUXGA PNGs?

That's what every country does. Al-Jazeera doesn't push content about Brazil. The BBC doesn't push content about Lithuanians. French film companies don't produce movies about Korean ex-pats living in Japan, and Japanese film companies don't produce dramas about winemaking in Bordeaux.

People can watch whatever they like. The "Made in Canada" laws are ridiculous. The CBC wanted SCTV to produce "specifically Canadian" content when it switched to that network, so they cooked up Bob and Doug McKenzie. As if a Canadian-produced TV show featuring mostly Canadian actors wasn't Canadian enough.