Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Modern Node.js Patterns

kashw1n.com

Post reply on HN
Print view View original

431–440 of 448 posts

Re: Modern Node.js Patterns

#431

Post by tankenmate »

bombela wrote: post #228
tankenmate wrote: post #221

Earlier quoted context omitted.

I wouldn't trust it to be done right. It's like a bank trusting that all their customers will do the right thing. If you want MAC (as opposed to DAC), do it in the kernel like it's supposed to be; use apparmor or selinux. And both of those methods will allow you to control way more than just which files you can read / write.

Yeah but you see, this requires to be deployed along side the application somehow with the help of the ops team. While changing the command line is under control of the application developer.

So security theatre is the best option? I'm not saying this to be cheeky, but it just seems to be an overly shallow option that is trivially easy to end run.

Re: Modern Node.js Patterns

#432

Post by crabbone »

simonw wrote: post #402
crabbone wrote: post #369

Earlier quoted context omitted.

Why would a desktop program need these sort of restrictions?

Because I don't trust the developer not to have security holes in their code.

But you are asking the developer to make these restrictions... Node.js is the user-space program, controlled by developers. Ops shouldn't (need to) deal with it.

Re: Modern Node.js Patterns

#433

Post by crabbone »

_heimdall wrote: post #411
crabbone wrote: post #370

Earlier quoted context omitted.

OK, I'll bite. Do you think Node.js implementation is aware of DNS search path? (My guess would be that it's unaware with 90% certainty). If you don't know what DNS search path is, here's my informal explanation: your application may request to connect to foo.bar.com or to bar.com, and if your /etc/resolv.conf contains "search foo", then these two requests are the same request. This is an important feature of corpora…

Oh I'd be very surprised if Node's implementation would handle such situations. I also wouldn't really expect it to though, that depends heavily on the environment the app is run in, and if the deployment environment intentionally includes resolv.conf or similar I'd expect the developer(s) to either use a more elegant solution or configure Node to expect those resolutions.

Then you are sort of saying: I expect Node.js implementation to be bad... why do you need a bad solution if a good one is within hand's reach?

In other words: Node.js doesn't do anything better, but, actually does some things worse. No advantages, only disadvantages... then why use it?

Re: Modern Node.js Patterns

#434

Post by crabbone »

epolanski wrote: post #380
crabbone wrote: post #372

Earlier quoted context omitted.

Nope, they don't add. They confuse. From administrator perspective, it sucks when the same conceptual configuration can be performed in many different places using different configuration languages, governed by different upgrade policies, owned by unintended users, logged into unintended places. Also, I'd bet my monthly salary on that Node.js implementation of this feature doesn't take into account multiple possible…

If you're confused over such things, you're a crap admin.

Oh, so we are launching attacks on personality now? Well. To start with: you aren't an admin at all, and you don't even understand the work admins do. Why are you getting into an argument that is clearly above your abilities?

And, a side note: you also don't understand English all that well. "Confusion" is present in any situation that needs analysis. What's different is the degree to which it's present. Increasing confusion makes analysis more costly in terms of resources and potential for error. The "solution" offered by Node.js offers to increase confusion, but offers nothing in return. I.e. it creates waste. Or, put differently, is useless, and, by extension, harmful, because you cannot take resources and do nothing and still be neutral: if you waste resources while produce nothing of value, you limit resources to other actors who could potentially make a better use of them.

Re: Modern Node.js Patterns

#435

Post by nedt »

DiddlyWinks wrote: post #391
nedt wrote: post #329

Earlier quoted context omitted.

I was really trying to use deno but it still is not there yet. Node might not be the cool kid, but it works and if you get stuck the whole internet is here to help (or at least stack overflow). We once reported an issue and it got fixed really quickly. But then we had troubles connecting via TLS (mysql on google cloud platform) and after a long time debugging found out the issue is actually not in deno, but in RustTL…

Interesting. Do you think Deno has made questionable choices in the components it uses?

Well I don't think there is much choice. They write the core in rust. Plus openssl is a bit old and bloated. So it's not wrong to pick RustTLS if you want to be hip.

Re: Modern Node.js Patterns

#436

Post by bombela »

tankenmate wrote: post #431
bombela wrote: post #228

Earlier quoted context omitted.

Yeah but you see, this requires to be deployed along side the application somehow with the help of the ops team. While changing the command line is under control of the application developer.

So security theatre is the best option? I'm not saying this to be cheeky, but it just seems to be an overly shallow option that is trivially easy to end run.

Agreed.

How can we offer a solution that is as low or lower friction and does the right thing instead of security theater.

At least we could consider this part of a defense in depth.

We; humans; always reach for instant gratification. The path of low resistance is the one that wins.

Re: Modern Node.js Patterns

#437

Post by DiddlyWinks »

nedt wrote: post #435
DiddlyWinks wrote: post #391

Earlier quoted context omitted.

Interesting. Do you think Deno has made questionable choices in the components it uses?

Well I don't think there is much choice. They write the core in rust. Plus openssl is a bit old and bloated. So it's not wrong to pick RustTLS if you want to be hip.

Ha, well, by all means I must be hip!

Re: Modern Node.js Patterns

#438

Post by booleandilemma »

goosejuice wrote: post #386
refulgentis wrote: post #118

Earlier quoted context omitted.

Same, but, I'm struggling with the idea that even if I learn things I haven't before, at the limit, it'd be annoying if we gave writing like this a free pass continuously - I'd argue filtered might not be the right word - I'd be fine with net reduction. Theres something bad about adding fluff (how many game changers were there?) An alternative framing I've been thinking about is, there's clearly something bad when yo…

You can critique the writing without calling into question how it was written. Speculation on the tools used to write it serves no purpose beyond making a, possibly unfounded, value judgement against the writer. https://hbr.org/2025/08/research-the-hidden-penalty-of-using...

No, I think if someone is passing off an LLM's writing as their own they deserve to be shamed mercilessly. Normally I don't comment on a thread after so long (> 24 hours) but your take is just so bad, I couldn't help myself.

Re: Modern Node.js Patterns

#439

Post by jjani »

refulgentis wrote: post #408
jjani wrote: post #170

Earlier quoted context omitted.

I too find it unreadable, I guess that's the downside of working on this stuff every day, you get to really hate seeing it. It does tell you that if even 95% of HN can't tell, then 99% of the public can't tell. Which is pretty incredible.

Cheers, it's gotta be the "I see this every day for hours" thing - I have a hard time mentioning it because there's a bunch of people who would like to think they have similar experience and yet don't see the same tells. But for real, I've been on these 8+ hours a day for 2 years now. And it sounds like you have the same surreal experience as me...it's so blindingly. obvious. that the only odd thing is people not men…

Can confirm it's "Not just the GPT's - it's all of the frontier models." who are addicted to that one.

IME the only reliable way around it when using an LLM to create blog-like content is to have actual hard lists of slop to rewrite/avoid. This works pretty well if done if correctly. There's actually not that many patterns (not hundreds, more like dozens) so they're pretty enumerable. On the other hand, you and me would still be able to tell if only rewriting those things.

Overall the number one thing is that the writing is "overly slick". I've seen this expressed in tons of ways but I find slickness to be the most apt description. As if it's a pitch, or a TED presentation script, that has been pored over and perfected until every single word is optimized. Very salesy. In a similar vein, in LLM-written text, everything is given similar importance. Everything is crucial, one of the most powerful X, particularly elegant, and so on.

I find Opus to have the lowest slop ratio, which this benchmark kind of confirms [1], but of course its pricing is a barrier.

[1] https://eqbench.com/creative_writing_longform.html

Re: Modern Node.js Patterns

#440

Post by vlovich123 »

crabbone wrote: post #367
vlovich123 wrote: post #345

Earlier quoted context omitted.

Except, the OS hasn’t actually solved it. Any program you can run can access arbitrary files of yours and it’s quite difficult to actually control that access even if you want to limit the blast radius of your own software. Seriously - what software works you use? Go write eBPF to act as a mini adhoc hypervisor to enforce difficult to write policies via seLinux? That only even works if you’re the admin of the machine…

This is what process' mount namespace is for. Various container implementations use it. With modern Linux you don't even need a third-party container manager, systemd-nspawn comes with the system and should be able to do that. The problem with the "solutions" s.a. the one in Node.js is that Node.js doesn't get to decide how eg. domain names are resolved. So, it's easy to fool it to allow or to deny access to somethin…

The part you're overlooking is how easy a vulnerability within the application can escape & do damage. Such vulnerabilities could either be someone hacking the application or a supply chain vulnerability. Namespacing & similar techniques limit the blast radius of a compromised process on the rest of the OS, but do nothing to limit the blast radius of a compromise on the assets accessible by the process. For example, if I have a document editor and want to open documents on my OS, namespacing doesn't help - the document editor traditionally needs the ability to open and list files.

Comprehensive capability protection is needed so that you actually need to have a token to do something privileged even within the process. What that looks like is the OS shows a file dialog and gives the process a descriptor (with a random ID) to that file. Similarly, network I/O would need a privileged descriptor the OS gives the application. Then even if you compromise the process you have to fully compromise the process to find the token to do privileged actions with.

Post reply on HN