You might be interested to know that the BBC has a Pidgin version.
> BBC News Pidgin now dey on Whatsapp
> No dull yoursef, be di first to get latest tori, analysis, exclusive interviews and ogbonge coverage of Nigerian and International news from BBC News Pidgin, straight to your Whatsapp.
During the time of Internet Explorer 9, it was surprisingly common for people to still be using Internet Explorer 6. This was often out of their control, for instance if they had intranet sites that required Internet Explorer 6, or if they were stuck on an old version of Windows because they had outdated hardware.
Later versions of Internet Explorer had compatibility mode, but it often wasn’t enough to get things working, especially if there was ActiveX involved or the security policies were restrictive.
Schools were especially prone to this due to their limited budgets among other reasons, and IT teachers weren’t normally the decision makers who could do anything about it. You shouldn’t assume that a random IT teacher had the authority to spontaneously upgrade a school computer that needs to be used for things besides that one student’s assignment.
It sounds like an overly earnest TEDx talker leaning over you talking about something inconsequential as if it’s the most mic-droppingly insightful thing in the world.
> In 2008 you saved a file called index.html, dragged it onto an FTP client, and watched a little progress bar crawl to the right.
When I was first learning web development in the 90s, after a couple of sites, I switched to a hosting provider that offered a bit more control over the hosting environment. I discovered that they supported SCP and SFTP but not FTP. When I asked them why, they told me it was because FTP was old and insecure. I dig a bit of digging to learn about the situation, and sure enough, FTP was 25+ years old already and literally a decade older than the Internet (FTP: 1971; TCP/IP: 1981) and was obsolete and much less secure than the modern alternatives available in the late 90s.
This was a full decade before “the olden times” of 2008 that the article talks about, so using FTP even back then was a massively outdated way of working.
And the average American is a poor representation of everyone. The title reads “Why does everyone hate AI?” but repeatedly references surveys of Americans, not “everyone”.
Americans are outliers; the rest of the world has a much more favourable view of AI.
> Majorities of Americans have pessimistic views toward the impact of AI on internet disinformation and the job market, outpacing most of the 32 countries surveyed in the Ipsos AI Monitor 2026. Americans were also the most likely to feel AI will make their country’s economy worse. Not every country is pessimistic about AI. Americans clearly are.
You could not make cross-domain Ajax requests at all until CORS came along. There were lots of workarounds people had to invent (e.g. JSONP, Flash shims, proxying, etc.) precisely because this security barrier has been in place since the mid-90s, a couple of decades before CORS came along.
The whole point of CORS was to enable cross-domain requests.
It goes something like this (it varies by country / citizenship): first you upload a picture of your ID, then you use your phone to take a video of your face, then the two are matched. A failure is when the uploaded ID doesn’t match your face.
You can’t get to the part where they don’t match without uploading a picture of their ID. If you don’t have their ID, then you can’t fail to match. If you fake the ID, then when they come to upload their own ID, their ID won’t match your fake ID and they won’t be blocked.
XMLHTTPRequest was originally an ActiveX object (something like ActiveXObject("Microsoft.XMLHTTP")), that’s probably what you are thinking of. You couldn’t make cross-domain requests with it though. Other browsers then implemented XMLHTTPRequest based on the ActiveX object, and then Internet Explorer supported XMLHTTPRequest and dropped ActiveX.
Before that, people who wanted to make cross origin requests sometimes used Flash but I think that always needed a crossdomain.xml file to work. JSONP was also used, which is where you source a <script> from the remote that calls a function in your own context to pass information in. You needed to be a little more careful with that, but only because you were deliberately passing information in; the browser couldn’t read it by itself.
I’m pretty sure the SOP has been effective in all non-Netscape browsers from as soon as they started supporting JavaScript.
If you were a web developer before CORS existed, then you understand that cross-domain requests were forbidden all along and CORS was created to bypass this security. Therefore to do the thing you want to do, you need to enable CORS. No problem, that’s pretty easy.
If you only picked up web development after CORS existed, then you try to make a cross-origin request; the browser understands that it isn’t allowed; the browser tries to do a CORS preflight request; the preflight request fails; and the browser reports a CORS error in the console.
So if you don’t understand what’s going on, don’t RTFM, and just guess, you’re going to guess that CORS is the thing that is blocking the request and that you need to disable CORS. And that leads you directly into a confusing mess because you are trying to do the exact opposite of what you need to do. CORS is the solution to your problem, not the cause of it.
It doesn’t help matters that a whole bunch of people with the same misunderstanding will confidently repeat that misunderstanding in tutorials and online discussions.
> Initially, you could literally hit any website with any sort of request, so your website.com could make requests to bank.com, and the browser happily obliged. Of course, this opens up a whole host of issues, so browsers started limiting websites to just being allowed to make requests to the same Origin.
I think that’s overstating it a bit. JavaScript was introduced in Netscape 2.0 and the SOP was introduced pretty much straight away – Netscape 2.0.2 I believe. Almost 20 years passed and then CORS was created. So while it’s technically true, the timeframe in which JavaScript could make any cross-origin requests was basically the blink of an eye, and for all intents and purposes, the SOP has been around since the beginning and definitely many, many years before Ajax came around.
HTTP requests are not RPC calls. The end state of a DELETE request is that the resource does not exist. If you make the request once, the end result is that the resource does not exist. If you make the request twice, the end result is that the resource does not exist. The spec. allows for the actual response to differ; the important thing is that the state is the same regardless.
> If I told them who I was and then failed to verify that, they don't know who I am because they think I'm lying about who I am.
They know who you claim to be. It’s not like they just delete all information about you when you fail verification. They are perfectly capable of seeing that two separate accounts are both claiming to be the same person.
> Otherwise what stops me DoSing Sam Altman's account by saying I'm him and then failing to verify?
For Sam Altman in particular? The fact that he’s the CEO. For people in general? Do you have their passport / driving license, and other details needed to attempt the verification process?
The whole point of an identity check is that they know exactly who you are. If you tell them who you are and you fail the identity check, you can’t simply create a new account because when you go through the identity check for a second time you’ll still need to tell them exactly who you are, at which point they can match the new account to the original failure.
OpenAI also has this kind of check. What is especially bad is that if you fail the verification process, they won’t let you retry – you are permanently locked out from the top models. They aren’t clear about this upfront during the process, so make sure the lighting is good when you scan your ID!
> GET requests will be sent, but they are supposed to be idempotent so if your server is implemented in a sensible way, it cannot cause any adverse effect, and reading the response is all that matters for GET requests.
This is not correct. Safety and idempotency are two different concepts. Safety is when a request does not result in a state change. Idempotency is when the outcome is the same whether you make the request once or several times.
GET is defined to be both safe and idempotent. Clients can make GET requests without explicit human intent driving them because they are safe, not because they are idempotent.
DELETE is not defined to be safe but it is defined to be idempotent. This means you need human intent to drive it, but clients can retry as much as they like because whether you ask to delete a resource one time or a hundred times, the result is still the same – the resource is deleted. Obviously making DELETE requests can result in adverse effects even though it is idempotent.
POST is neither safe nor idempotent, however it’s subject to some unintuitive rules when it comes to things like cross-origin requests for historical reasons.
> Thinking of it in advance does make it easier but it can definitely still break a business
If privacy regulations can break your business, then I think there’s a very high chance what you are doing is exactly the sort of thing the regulations are explicitly designed to discourage.
> now there's a whole CMP TCF2 protocol you have to implement.
That’s exactly what I’m talking about. There’s no regulation saying you have to implement that. That’s a consequence of you making the choice to trade user data. Somebody who does not choose to do that has much less work to do. This is an example of the regulations working as intended. You’re supposed to see the friction and make better choices up front to avoid it, not make the same choices then complain about the friction.
> eventually they screw the little guys more than they screw the bad actors.
You can reach me by emailing my first name at my last name, on the .email TLD.