HN user
Software engineer & blogger - https://ashishb.net/about
The archaic model where every tool gets full access to your home directory was never designed for the scenario where a single npm install will install and execute 100s of packages written by various authors.
One should sandbox all npm command executions.
This is true for all CLI tools on Mac and Linux (and other operating systems from that era).
Historically, everything you ran was trustworthy.
Android and iOS were invented in an era that does not allow this because the risks became evident by then.
The repo you’re working on, sure. But all files?
Yes, any tool, including any coding agent, has access to all files $USER has access to.
Sandbox it explicitly to give access to only the current directory - https://github.com/ashishb/amazing-sandbox
That every other vowel letter also can is English's low level of phoneticism
The level of phoneticism between English language and its latin script is not evenly spread.
For example, the letter "c" might mean /s/ or /k/ sound. However, the letter "k" almost certainly means /k/ sound.
In some ways, the schwa sound in English the worst as there is no symbol which is committed even partially towards it.
it is Rāma, and 'a' represents the schwa.
Sure, but if my name is Rāma, I have to choose either "Ram" or "Rama" or "Raama" for my passport name. Or legal name in most places, non-alphabetic symbols do not work with all modern systems.
Many other languages using the Latin script (German, Italian, Finnish) don't have this problem, what you see is what get.
English imports spellings from other cultures and adds its own layer of pronunciations. Other languages probably don't do it as often.
It's Ram, not Rama, it's yog, not yoga'... And they have no idea what schwa deletion is.
It is neither.
The fundamental issue is that there is no way to represent the schwa sound in English[1]. All of a,e,i,o,u have been used to communicate the schwa (or schwa-like) sound in English.
- The `a` in about
- The `e` in taken
- The `i` in cousin
- The `o` in button
- The `u` in upon
Many of my friends are surprised that I purchase mp3s and store them in Google Drive instead of listening on Spotify or YouTube.
Heck, I even wrote a player for this [1] The problem is that licensed media like this are always going to become inaccessible over decades.
It happened with Apple[2] and Microsoft (PlaysForSure[3]) as well.
1 - https://musicsync.ashishb.net/ 2 - https://www.nytimes.com/wirecutter/blog/you-dont-own-your-di... 2 - https://www.cnet.com/culture/playsforsure-officially-dead/
Are you actually claiming English isn't a mother tongue to anyone?
I gave a specific example where neither the coffee wholesaler nor the buyer probably operates day to day in English. But they would still use English for the official agreement.
That does not take away from other benefits of English like being spoken by millions as a primary language and probably billions as a second language
Sanskrit was widely spoken and understood just like Latin or Avestan, in its heyday. Otherwise it wouldn’t be part of the liturgical traditions of Buddhism, Jainism and Nastika traditions.
I think, and it is just my speculation, that for most of Indian History, Sanskrit was the link language.
Just like "Latin" in the USA and Europe of the early 17th and 18th centuries, when all academic instructions were carried out in Latin!
So, nobody used Sanskrit as the primary language, but everyone could or knew someone who could convert Sanskrit to the local dialect.
It is almost like how Chinese and Colombian traders might sign a contract for coffee purchase in English. Neither might use English in most of their daily operations.
What about Prakrit and Punjabi?
There is no official "Prakrit", by definition of the term itself. "Prakrit" just means "natural" and the way I understand it, was the term for all colloquial dialects/languages across India.
"Sanskrit", on the other hand, meant "cultured" and its grammar, at least for the last 2500 years, is strictly defined by Panini (https://en.wikipedia.org/wiki/A%E1%B9%A3%E1%B9%AD%C4%81dhy%C...)
Fun fact: the famous "Sentosa" island in Singapore is a spelling variation of the same word.
I think most organizations don't want to increase their Java usage.
And the reason is not technical. Technically, it is a great language.
Legally, it feels risky to most.
Languages do matter.
And I think the only sensible backend languages when starting a new for-profit project is Python, Go, and Rust for 99% use-cases.
In other cases, third-party packages, tooling, integrations, and telemetry starts to suffer.
Because I'm confident nothing will happen if it does
Well, best of luck.
1. Amazon has shipped backdoored packages - https://aws.amazon.com/security/security-bulletins/AWS-2025-... 2. Scanners like Trivy have been compromised - https://socket.dev/blog/trivy-under-attack-again-github-acti... 3. Redhat is shipping backdoored FOSS packages - https://access.redhat.com/security/vulnerabilities/RHSB-2026... 4. Even fake and malicious ESLint packages have been published - https://gbhackers.com/eslint-package-attack/
But in this particular case isn't the problem that it's sending everything in the sandbox?
If a CLI is touching certain files, they are likely to be leaked one way or the other.
Why not reduce the attack surface?
When does someone visit your house? Do they get unfettered access to your bedroom & safe as well?
And I run most of them inside sandbox now.
Why would you let a markdown linter access your ssh keys?
There is a reason I run all such CLIs inside a sandbox [1] giving limited directory access.
Imagine if the CLI pulled your SSH keys or other sensitive information by mistake?
Programmers do make such mistakes all the time. I don't want to count on whether "uploading all files it can access" is intentional or a mistake.
Listen to any on the Elon Musk interviews, he knows more technical intricacies of his 1000+ employee companies than your average startup founder with 10 employees.
1. Docker (or any Linux container runtime, for that matter) is not intended for, designed for, or effective as a security boundary.
This has been discussed in detail earlier - https://news.ycombinator.com/item?id=47612726
Further, on Mac OS, you can use `--mode=native` for Mac's native sandboxing (seatbelt).
2. Root containers run as root on the host. The "sandboxed" processes have full capabilities, as far as the kernel is concerned with them.
That's not always the case. You can run rootless containers or you can use containerization like Podman which does not run as root.
I wonder what percentage of pull requests are cascading updates caused by dependabot and multiple code review bots reviewing those PRs.
My belief is it is likely 1% or more. And likely coming in as an avalanche.
Right now, not. Eventually, they will.
You can pass your favorite rootless Docker image using `--custom-docker-image` CLI parameter.
I should be able to install this module in such a way where file operations and process operations are not available to it.
That's the definition of a sandbox, isn't it?
The ability for npm to run scripts on any level should be removed.
Even Python has that ability now. Also, `npm run dev` is running the script with full disk access.
Heck, Vscode/Cursor will auto-execute code if you open a project. And this has been actively used in the wild https://ashishb.net/security/contagious-interview/
That's exactly what I started with. It gets unwieldy quickly enough as you need to mount a lot of directories that these you uses as cache.
So, amazing-sandbox at its core is nothing but a glorified docker command generator (in default mode).
I have some ideas around it. And indeed that's one likely direction of this project in the future.
This has been responded to in the past by another HN poster: https://news.ycombinator.com/item?id=47612726
Furthermore, you can use native sandboxing on macOS if you prefer.
If neither looks serious to you, then please educate me on a better sandboxing approach.
Nobody should do 'npm install' or 'pip install' on their machine.
Using a proper sandboxing(https://github.com/ashishb/amazing-sandbox) regularly will drastically limit the blast radius of these attacks.
I have been targeted with this attack in the wild where '.vscode/tasks.json' had the auto-run code.
I smelled something fishy and never ran it though.
For dependabot it's as simple as cooldown.default-days: 1
Most people stick to default of 0. In fact, I am realizing over time that it is best to make it 7-14 days.
Hypothesis: a big accelerant of these rapid repository compromise (from Red hat to GitHub to Amazon to small startups) might be GitHub+dependabot automatic dependency updates.
So, just like COVID-19 used air travel, modern malware attacks are relying on GitHub+dependabot to speed up the spread.
Even for single page website built using Vue, I would get about 5 updates a week.
And why didn't they chose self-hosted for git then?