JimDabell

Apple created <canvas>, but it wasn’t for the iPhone, it was for Mac OS X dashboard widgets. This was a few years before the iPhone existed.

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.

Click here to join di channel

— https://www.bbc.com/pidgin

OK, accents are a whole can of worms. Regional English is varied. I'm not sure if there are any BCP-style tags for intra-country accents.

This comment is written in en-GB-Brummie.

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.

AI optimism surges in Asia, unlike in the U.S.

— https://restofworld.org/2026/ai-optimism-asia/

U.S. Workers Are More Wary of AI Than Their Global Peers.

— https://www.salesforce.com/news/stories/what-leaders-should-...

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.

— https://www.ipsos.com/en-us/comparing-us-and-global-attitude...

That infrasound video is nonsense:

https://blog.andymasley.com/p/contra-benn-jordan-data-center...

That infrasound video is nonsense:

https://blog.andymasley.com/p/contra-benn-jordan-data-center...

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.

You’re misunderstanding the process.

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.

That’s not correct at all. Are you confusing it with SameSite or something like that?

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.

I think perhaps it’s generational.

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!

https://help.openai.com/en/articles/10910291-api-organizatio...

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.

Little guys are often the bad actors.

I recommend taking a look into the different standards for website accessibility, GDPR, etc. On paper it sounds great, who doesn't want an accessible websites or privacy? But in practice it's a total drain of resources, real legal risk even if you genuinely try and be compliant, and often you just pay a lot of $$$ for legal, compliance advisors etc. so you could tick off a box and have some sort of insurance in case you're being sued.

This is a really good analogy, except you made one mistake: it’s not difficult at all to design something to be accessible and respectful of privacy as long as you do it from the start. If you try to build something inaccessible and privacy-invading then get caught and have to retrofit accessibility and privacy at the last minute to avoid fines and lawsuits, that’s when it becomes difficult.

And you see this exact mistake crop up in the Stop Killing Games criticism as well. People say that it’s difficult because they are thinking about taking the status quo and retrofitting longevity. For instance, trying to retroactively obtain licenses to distribute components that they didn’t originally have. When in practice, the effect of a law like this is that it would push game developers to make the right choices up front like picking appropriately licensed components, so there’s no barrier to keeping the game alive when the time comes to cease support.

It might also have escaped your attention that the EU was perfectly willing to create accessibility and privacy regulations, so if you are likening Stop Killing Games to these things then it stands to reason that this is not a reason for the EU to avoid Stop Killing Games legislation.

Alexandre Colucci has published a series of articles analysing the use of Swift in iOS and macOS by Apple here:

https://blog.timac.org/categories/reverse-engineering/

And frequently discussed on Hacker News:

https://hn.algolia.com/?dateRange=all&page=0&prefix=false&qu...

Forget AI exists for a moment. You’ve got a team of humans working on a project. You’ve got a backend developer, a frontend developer, a DBA, a platform engineer, a graphic designer, a UX person, a product manager, and a QA person.

Whose responsibility is it to select the colours? You think this is the responsibility of one of the developers‽ You don’t think “having taste in colours” is solidly owned by the designer‽ You think this is a developer task not a design task‽

Aside from that, the specific example you chose is an area where we have deterministic algorithms for judging contrast – we don’t even need AI for that, regular old procedural code can do it.

You think “taste in colours” is a development task not a design task‽

That doesn’t work because it relies upon the receiver adding all the possible variations of the sending email address to their address book ahead of time.

Is there more documentation than this?

as-console-user command [args …]

Run a Homebrew command as the active macOS console user.

This is intended for MDM, Munki and Jamf workflows where brew is invoked as root but Homebrew operations should run as the logged-in console user. The nested command is always dispatched through HOMEBREW_BREW_FILE.

— https://docs.brew.sh/Manpage#as-console-user-command-args-

This isn’t very informative. Is there more documentation somewhere else that I’m missing? Google search doesn’t really find much.

I currently have a dedicated `homebrew` user that I access with `alias brew='sudo --set-home --user=homebrew --chdir /Users/homebrew -- brew' but it’s got a number of shortcomings. What will as-console-user do differently to this?

Having a trustworthy inbox that contains only legitimate email and a separate friend request queue where you can decide “do I know this person / organisation?” is far better than having a single inbox that’s a vast ocean of emails of unknown provenance you have to make a trust decision for for every single email.

To have secure email I think html /css should be dropped from email support

I don’t think that helps at all. We already know how to consume that securely, we do it billions of times a day in web browsers.

the inbox should work on an invite only basis. Basically you should pre-authorize the senders just like you add someone as friend on a social network.

Yes. A fundamental problem with email is that the only thing required to send email to somebody is knowledge of their email address, which as a recipient you cannot control. This is what enables spam and phishing. This needs to be changed so that in order to send email to somebody, you also need their consent. A “friend request” mechanism is one way of achieving this.

I think this is a problem that can be feasibly solved in a fairly reasonable way, and I sketched out a protocol for doing so a while back, which I described in more detail in this comment:

https://news.ycombinator.com/item?id=44969726

I think you’re conflating development and design there. I’m saying that development is at risk, I’m not commenting on design. Taste in colours and things like that are design.