Hacker News: cxr

New comment by cxr in "Datasette Apps: Host custom HTML applications inside Datasette"

cxr — Sun, 21 Jun 2026 19:55:20 +0000

> Would moving the untrusted content to be served from a separate domain entirely close the hole?

Yes.

New comment by cxr in "Datasette Apps: Host custom HTML applications inside Datasette"

cxr — Sun, 21 Jun 2026 09:14:34 +0000

> That's why I'm careful not to include allow-same-origin in the sandbox attribute

It doesn't matter. I just said there is no combination of CSP or the iframe sandbox attribute that can be relied upon here.

New comment by cxr in "Datasette Apps: Host custom HTML applications inside Datasette"

cxr — Sat, 20 Jun 2026 14:15:02 +0000

> - which really is designed to be used as a sandbox

Not for untrusted content living on the same origin to prevent it from exercising any of the powers that it would ordinarily have to be able to access sensitive data. It's a misleading name and shouldn't have been chosen. There is no combination of CSP or the iframe sandbox attribute that can be relied upon for that purpose. This is a fundamental limitation of the way the specs were written.

(There needs to be a big warning about this on MDN, but moving from the old wiki to a wiki with GitHub for login to the GitHub-based pull request process really didn't help the there's-a-problem-on-this-page-but-limited-resources-to-make-things-better problem.)

New comment by cxr in "Datasette Apps: Host custom HTML applications inside Datasette"

cxr — Fri, 19 Jun 2026 17:29:37 +0000

CSP is optional and designed to be one part of a defense-in-depth strategy (to extent that it was thoughtfully designed at all—it's an awful standard that should not have made it past proposal stage). It's not a solution for sandboxing untrusted content and should not be relied upon that way. Treating it like one is a great demonstration of how some uses of CSP make people more vulnerable.

New comment by cxr in "NetNewsWire Status"

cxr — Fri, 19 Jun 2026 12:51:10 +0000

A lot of people don't get podcasts. They think it's a genre (and that it applies to the show(s) they watch on YouTube).

For a large segment, telling them that a feed reader is for podcasts but for reading will just elicit a "what?"

New comment by cxr in "The Birth and Death of JavaScript (2014)"

cxr — Sun, 14 Jun 2026 14:45:11 +0000

It's no use being pedantic if you're not going to be correct.

> This is a pedantic point, but that's not really what the definition of compiler is as much as a common understanding of it. By definition, it just translates one language into another

The history and etymology doesn't support that definition, either; that's just another "common [mis]understanding" of the term. It's in the name. A compiler produces a compilation—an aggregate of multiple subroutines, including user-supplied ones and some by the system/programming environment, transformed into a single program for a given target.

(You're describing the process of "autocoding", a job that every compiler does, and a term that predates "transpiler" but that no one uses because they favor stretching the more frequently encountered term "compiler" for their use case.)

New comment by cxr in "Chibil: A C compiler targeting .NET IL"

cxr — Sun, 31 May 2026 17:28:06 +0000

The creator of lcc also published a paper "lcc.NET: targeting the .NET Common Intermediate Language from Standard C" (2004).

<https://drh.github.io/documents/msil-spe.pdf>

One problem with lcc has always been that it's distributed as source available with restrictions and has never been available under a FOSS license.

New comment by cxr in "Build Adafruit projects right from Firefox"

cxr — Sat, 30 May 2026 20:20:56 +0000

> You seem very angry and I clearly don't understand what you are talking about.

Luckily you managed to frame it so that the failure comes across like something that I got wrong and messed up and am responsible for, and that's the most important thing.

New comment by cxr in "Build Adafruit projects right from Firefox"

cxr — Mon, 25 May 2026 03:57:23 +0000

> Unfortunately Firefox doesn't support the FileSystem API so to do this you need to resort to uploading the entire source code directory each time you change a source file.

Right, it's so much less onerous to have people download and set up an entirely separate fickle toolchain—and needing to trust that the install triggers in the package.json of some transitive dependency won't exfiltrate your personal data or install some nefarious ineradicable background service onto your system, versus the two extra clicks you'd have to subject yourself to if you wanted to re-run the build.*

Wait, no.

> people [are] forced to ship "Chrome-based only" features

No they're not. By your own admission they could make their build scripts work with the standardized HTML5 APIs that are well-supported in all major browsers. They choose not to.

And you're not really responding to the substance, anyway—which is that JS programmers (frequently writing for browser runtimes, even) require that you install NodeJS, Bun, or Deno (because they hardcode the build scripts internals against one of those runtime's APIs). If programmers really were writing build scripts that you could run in Chrome but unfortunately not Firefox, then even that would be an improvement over the status quo. But that's not what we're talking about, because that's not happening.

* most of which are destined to be one-shot executions, anyway

New comment by cxr in "Build Adafruit projects right from Firefox"

cxr — Sun, 24 May 2026 18:04:09 +0000

That's a start at improving something. But it won't rid itself of the Playskool/Fisher-Price gimmick factor or have any lasting effect until we can convince JS developers to write their own tools in a standards-compliant dialect and use standardized APIs so that contributors can use the runtime they already have installed instead of being cajoled and browbeaten into installing NodeJS or Bun or Deno or whatever to do what the browser runtime is perfectly capable of: opening a project directory, executing the code comprising the build script, and outputting the build artifacts when it's done.

New comment by cxr in "Moving away from Tailwind, and learning to structure my CSS"

cxr — Sun, 17 May 2026 17:51:39 +0000

What?

New comment by cxr in "The Third Hard Problem"

cxr — Sun, 17 May 2026 14:12:55 +0000

This is an independent riff on an argument Ted Nelson wrote down 50 years ago (and the reason why he coined the term "hypertext").

<https://en.wikipedia.org/wiki/Computer_Lib/Dream_Machines>

<http://link.springer.com/10.1007/978-3-319-16925-5>

New comment by cxr in "Moving away from Tailwind, and learning to structure my CSS"

cxr — Sun, 17 May 2026 13:50:10 +0000

> the class="" property is in the HTML and that is the styling info

The class attribute (not "property") is in the HTML because it's part of HTML. It's markup. Element classes weren't created either by or for the CSS people when CSS came along. The class attribute predates CSS by years and has no more relation to "styling info" than the id attribute does.

New comment by cxr in "Show HN: Epiq – Distributed Git based issue tracker TUI"

cxr — Sat, 16 May 2026 20:53:27 +0000

> How can the browser execute git commands from opening a local html file?

It can't. The CONTRIBUTING.html shell would spit out a file and tell the user what Git commands need to be run—just like project READMEs (or landing pages like jekyllrb.com) show which commands will install the tool.

New comment by cxr in "Show HN: Epiq – Distributed Git based issue tracker TUI"

cxr — Sat, 16 May 2026 13:12:09 +0000

I am one of ~3 people primarily responsible for the JS Reference as it appeared/appears on developer.mozilla.org since before NodeJS (or V8) ever existed. I "know what JavaScript is".

New comment by cxr in "Project Gutenberg – keeps getting better"

cxr — Sat, 16 May 2026 12:49:57 +0000

Like the Project Gutenberg collection on archive.org, the ZIMs are only current up to 2018.

New comment by cxr in "Show HN: Epiq – Distributed Git based issue tracker TUI"

cxr — Sat, 16 May 2026 11:46:31 +0000

There is no argument or insight in your comment. It's physically possible to type in code that makes direct use of non-standard APIs that work in NodeJS but not the browser. Pointing out that this is so and that there are people who do it is not the same as engaging with the subject of whether they ought not to—which was the point of the remarks you responded to. Previously:

> You're offering a retort to someone who is communicating their position that you ought not do something, where the retort consists of nothing more than explaining that people are doing it. Yes, clearly. But what the person you're responding to is arguing is that you ought not do it.¶ Consider[…]:

> Person A: Here's little advice: don't take up smoking. Smoking is bad for you.

> Person B: Yet people smoke

<https://news.ycombinator.com/item?id=38712699>

New comment by cxr in "Show HN: Epiq – Distributed Git based issue tracker TUI"

cxr — Sat, 16 May 2026 04:57:09 +0000

You don't need to put it on the Web to be able to leverage the World Wide Wruntime.

Epiq looks to be written in TypeScript and distributed as JS via NPM. You know what excels at executing JS? The browser.

If you want to actually address the usability problems—then create a CONTRIBUTING.html—linked from the README, that users are instructed to double-click to open (i.e. launch in the browser on any sanely configured system). From there, they can/should be able to load the project either by pointing to it with a filepicker-based workflow that's the same as VSCode's "Open Folder…" workflow, or by dragging and dropping the source tree into the browser window. If you do it right, then this should immediately present them with a browser-based UI for poring over and interacting with all the Epiq data in the repo—down to the Git commands to execute to integrate changes into the Epiq "database".

It's beyond baffling that so many programmers who are nominally JS developers thumb their noses at writing standards-compliant code and instead insist on coding directly against Node's proprietary APIs.

New comment by cxr in "GitHub is sinking"

cxr — Sun, 10 May 2026 19:45:48 +0000

> DigitalOcean App platform[…] only connect to GitHub

They also support deployments from GitLab (so long as you're using the gitlab.com-hosted instance and not a self-hosted GitLab instance). If you've deployed your own self-hosted forge, then you can connect DigitalOcean App Platform to it by using gitlab.com as a bridge—register an account on gitlab.com once and instruct your self-hosted forge to replicate copies to gitlab.com. You don't really need to actually use GitLab.

Having said that, considering that DigitalOcean is in the business of selling IaaS/PaaS, it's loony that they don't let you connect to, say, your own self-hosted Forgejo running on their infrastructure…

(Indeed, considering how many people would like to self-host their own forge but how few people want to actually set up and do admin for it, it's loony that DigitalOcean doesn't pick up, say, Forgejo and/or an alternative and offer a sharply discounted (e.g. $20/year) quasi-managed one-click deployment option with first-class support for connecting to their App Platform.)

New comment by cxr in "The agent principal-agent problem"

cxr — Sun, 10 May 2026 12:31:28 +0000

This post highlights but never explicitly addresses the current language trend that involves the corruption of the word "agent" to imply ChatGPT- and Anthropic-era AI.

It also speculates on the practices at Microsoft in its opaqueness but doesn't recognize the development methodology used for Linux despite its transparency or acknowledge how it differs from the pilloried code review that the audience is most familiar with—even though the kernel development project is the cradle for the VCS that everyone decided to use (but also to never use correctly).

Overall, there aren't really any insights here. The solution described just highlights that high-trust teams are composed of members that (are|can be) trusted by one another. But being on that kind of team is a luxury. The introduction of coding agents doesn't change anything. Take out the LLM-powered patch iteration, and it works for all the reasons it already worked before the advent of coding agents. It's a little like the obliviousness-to-privilege of folks who try to address the problems of people who experience poverty with advice that reduces down to the question, "Have you tried ?"