Hacker Newsnew | past | comments | ask | show | jobs | submit | jerrythegerbil's commentslogin

As someone who uses NCD nearly every day, I have concerns about how it’s been used here.

But while we’re “guessing”: Xiaomi MiMO


Author here. Tell me more. How do you use NCD and what is your concern about its application here? Should I have use da larger reference sample? You can test it in action here: https://dejan.ai/tools/ai/ (e.g. drop a claude article or GLM article in and see what it says, it's not perfect but reasonably good).



Have also seen people guess it's a next version of Longcat, but I also think that's unlikely


The LLMs play a part, but it’s the tempo; the pace.

Fully autonomous w/LLM isn’t true. Leadership wants it true. The technological capabilities and acceptance of scapegoating a machine got rejected by society, so that leaves perfectly capable individuals as the gatekeepers of decision making, completely overloaded by the amount of information they need to deal with.

If you as a human can’t keep up, but the onslaught continues, and you’ll be held responsible for the outcome regardless… yeah. People will punch their ticket out. It’s not unique to LLMs, but LLMs have certainly automated the process of reaching the worst possible conclusion.

Don’t for a second try to hold the computers accountable or blame them for this outcome. This is a leadership issue and always will be. Believing otherwise is just allowing suicides to be scapegoated as a computer’s doing.


It doesn't matter if its fully autonomous or not. You taking something that was both esoteric and highly skilled to something that any rando with an LLM could do. And so yeah expectations for output are going to increase exponentially, but not entirely unreasonably so, all the while any appreciation or value of your own skillset is going to head right into the gutter.

I don't see how you can say this is a leadership issue because the tech itself is creating a scenario that's going to leave plenty of people in crisis. The same will happen in programming. People are clinging onto the hope that it won't matter that much because 80% of a programmer's job, at a large company, doesn't involve coding anyhow, but even there the reason for the high comp is that 20%, as that's where the barrier to entry is. As that barrier falls, skill relevance plummets, and expectations rise.


An ssh server would exploit a vulnerability in the ssh client when it connects.

For example, openssh has both a client and server. There’s been vulnerabilities in openssh, in the client. Those vulnerabilities aren’t reachable unless you’re connecting to a server attempting to exploit you, so the risk is quite low because you know and trust most servers you’re connecting to with ssh.

To sum it up: Connecting to this server is probably fine, but in doing so most people are doing something significantly riskier without realizing it.


There has never been a real-world OpenSSH exploit that allows a server to RCE a client that connected to it without a bunch of dubious qualifiers. Connecting to a random SSH server is much, much less dangerous than running a random binary or executing a random curl install script, both of which people do all the time, and is probably about on par with the likelihood of a random website escaping your browser's sandbox and RCEing you.


Agreed, bugs in the terminal emulator are probably more concerning. The attack surface of those is much larger (there are some pretty wild ANSI escape sequences, and terminal emulators are often granted pretty wide disk access permissions on systems that have them if they're also used for local development).


Malicious servers can send malicious terminal escape codes. For example https://www.sentinelone.com/vulnerability-database/cve-2026-...


Web browsers are generally built with security in mind. Terminal emulators surely much less so. The OpenSSH client probably sits somewhat in between, generally developed with security in mind, but not necessarily consistently expecting malicious servers.


At least for the more prominent terminal emulators i expect they probably devote a great deal of attention to security. They are developing the most commonly used interfaces for linking the most numerous, varied, and/or critical systems on the planet.


Went to the kitty website. No mentions of security.

Went to Alacritty. No mentions of security.

Went to Ghostty. No mentions of security, except for "secure keyboard entry".

None have a "security policy" on GitHub.

All written in memory unsafe languages (C, Zig).


I believe the recent cve-2026-55200 in libssh2 (client-side library) was allowing exactly this. https://nvd.nist.gov/vuln/detail/cve-2026-55200 ("Remote attackers can send crafted SSH packets with excessively large packet_length values to corrupt heap memory and achieve remote code execution.")

Of course the other abouts that you whatted (such as random curl install scripts, binaries, etc.) are still more dangerous.


Per Red Hat:

> The integer overflow provides uncontrolled access to the heap, which reliably crashes the client process but is unlikely to achieve remote code execution in practice. Weaponizing the overflow for code execution would require a separate information disclosure vulnerability to defeat ASLR, along with a specific heap layout to place exploitable structures adjacent to the undersized allocation.

---

> abouts that you whatted

"Whataboutism" is perhaps the most infuriating and wildly misused word in the English language. Pointing out that somebody is scaremongering about an action that is significantly less dangerous than other everyday actions people take on their computers is not a fallacy. It is directly relevant to evaluating risk. Yes, technically there could be some critical bug that allows the posited thing to happen, but in reality it just doesn't happen. If it did happen, nobody would blow their once-in-decades exploit on pranking some people on a forum.


OpenSSH doesn't use this library.


Good to know, but OpenSSH is not the scope here.


It seems to me you were replying to refute a claim about OpenSSH.


If you properly set up your ssh client (No agent forwarding or X11 forwarding)


Terminal, too; some escape sequences are able to perform attacks in old or buggy terminal emulators.


Even newer ones. Iterm2 had CVE-2026-41253 recently. Or things like Tmux.


Yes, I was thinking of iTerm2. "Older" means not the latest release and "buggy" includes well-intentioned vulnerabilities.


Sure. 3.6.9 (which was affected) was the most recent iTerm2 when that CVE came out.


Hence "or"


Isn't this exploit vector identical to the ones we'd expect on browser-based vulnerabilities? I believe that yes, there are possible risks involved, but no significant than our casual web-surfing through the net.


theoretically a browser could have the same vulnerability and has a vastly higher attack surface.

has there ever been an example of such a vulnerability in openssh?


> To sum it up: Connecting to this server is probably fine

And what are you basing this statement on?


This AI generated article about closed-weights model providers collaborating for additional scrutiny of open weights models, where the article itself has the tell-tale structure of being written by Claude Opus, which is aware it is a closed-weight model.

Thank goodness no one is taking any of this seriously, because it could never be anything more than a machine generated hatchet job.

A faster and better educated understanding of the subject matter could be achieved by standing in front of a wood chipper and dropping a brick in it to see what happens. “Yes, there were results! But why? Why to literally every variable involved?”


“However, large-scale, covert industrial distillation aimed at stealing proprietary U.S. technology and undermining American research is unacceptable.”

What’s actually happening behind the scenes is that certain inference providers will classify a prompt and it’s re-routed transparently to Anthropic and that’s used for distillation training, only distilling the complicated traces they need, originating from real user prompts and traces. These inference providers are explicitly blocked in the claude cli if you reverse engineer it.

The real picture is that these Chinese labs have figured out how to get exactly what they need, at a high quality, directly from distinct and unique real user prompts.

It’s only “covert” because Anthropic doesn’t like it, while simultaneously being perfectly fine to do.


> What’s actually happening behind the scenes is that certain inference providers will classify a prompt and it’s re-routed transparently to Anthropic and that’s used for distillation training

Uh, no. There are Chinese networks of tens thousands of fake identities specifically to get access to Anthropic models directly.

https://www.chinatalk.media/p/how-to-buy-cheap-claude-tokens...

Don't make up stuff and/or lie to suit a political agenda. It's extremely dishonest.


A datacenter was built a couple hundred feet from my apartment complex around 2013-2014. Absolutely none of your comment would have even remotely held true at the time, and my family moved away as a direct result.

Assuming positive intent, what’s different nowadays that makes it all different? It would actually make me pretty happy to hear about the incredible leaps and bounds that’ve been taken.


What did the nearby datacentre do that made you move?


“Pre-Authentication” and “Unauthenticated” are meaningfully different things, and for the purposes of marketing reach you always want to push for “Unauthenticated” if possible.

Typically Pre-Authenticated means knowing some additional contextual information such as the userID or something like that is required for exploitation, but actual authentication is not required. The impact is limited by how easy it is to know that pre-authentication information, which remains unknown.



So he managed to block the site globally for not forcibly violating the privacy of its users with mandatory age verification.

The US court system really needs to do something about this, and overturn Free Speech Coalition v. Paxton in favour of Reno v. American Civil Liberties Union.


FWIW, the site isn't blocked globally. They just moved to a new domain.

I do generally agree that local governments trying to forcefully exert their influence beyond their jurisdiction is deeply problematic. It wouldn't even be possible to host a website on the internet if this becomes normalized, due to being held to thousands of contradicting standards. At most Texas should have the authority to tell Texas ISPs to block traffic.


Allowing states to force ISPs to block websites might be an even bigger can of worms.


Motherless shouldn't have used a domain under Texan jurisdiction if they didn't want this to happen.


The US court system is completely hamstrung by the current administration.


MKULTRA was about using drugs to alter state and produce uninhibited truthfulness.

Social media has a direct impact on dopamine and uninhibited oversharing.

The mechanism isn’t even ambiguous, which is exactly why there’s a case, about the production of a deliberately addictive substance. The chemicals and effects differ, but it’s deliberate use and production as the same exact means to an end do not.

There’s zero ambiguity here of the alignment on an end goal.

Side note: is META hiring and can you refer me?


yeah, sorry, associated the two is an attempt to degrade the validity of the claims against meta.


> I fail 65% of the time. Same exact resume, different luck.

As someone who’s run hiring pipelines for technical roles in the past few years, that’s actually a fantastic number. I objectively hate saying that, but it’s true.

35% chance of elevating a technical individual to the next stage with no effort? I’ve seen as many as 100+ applicants an hour even when including a domain specific screener question. That’s 35 “screened” applicants in an hour. Were valid candidates screened out? Yes. Does you still have a candidate pool 35x larger than you need? Unfortunately, also yes.

The volume of applicants is SO HIGH such that your chances of getting moved to the next stage are actually markedly worse if AI isn’t involved. If you didn’t apply immediately (using an AI bot) there’s 50+ people ahead of you, and an exhausted technical leader if they ever make it to your resume.

Referral bonuses exist for a reason.


In that case, I have a pre-screening system to sell you. Through state of the art technology, it only lets through the best* 1% of applications.

*According to our proprietary, undisclosed, non-deterministic metric, which may or may not be Math.random



I worked at a startup that judged their hiring pipeline quality using rejection rate criteria.


Is it? Or is it a 65% chance of a resume getting ignored before a single human sees it, reducing your pipeline's likelihood of catching qualified candidates by the same?

Gates that reduce resume flow-through are only useful if their reduction is correlated with quality. Otherwise they're just dragging out your hiring process or unnecessarily causing you to ultimately lower your hiring bars.


> Gates that reduce resume flow-through are only useful if their reduction is correlated with quality.

The volume is infeasible to review everyone for quality, even at an hour scale. The conclusion and solution is inevitable, though I wish it were different. 35% is actually really good if you’re not coming in through a referral.

The current reality is <1% and the person reviewing you is exhausted.


You may as well just randomly pick 65 to discard, if your only goal is to reduce the number for review.


That’s exactly it for large scale hiring with finite resources.

It’s all probabilities in the end. And if an LLM gives you more a more relevant pool vs random distribution, that’s still a net benefit.


What a inhumane way of looking at this. Hiring is deeply flawed, you know it, and yet you keep job postings open for weeks/months in case "the one" magically appears on your doorstep instead of just interviewing 10-20 people and just pick one...

Corpo bullshittery at its finest.


What's the alternative? Everyones up in arms, but I see ZERO viable alternatives proposed.

If you have 1000 applications for every job, and you know that a bunch of these applications are "a bad fit", to put it mildly, you have to filter. And you cannot realistically give every resume a good, human look. By the time HR would be done, the market has already moved on five times.

So, what is the real difference between being overlooked because HR could only look at the first 100 resumes, or the AI filtered all 1000 resumes down to 100? In the end, a fuckton of potentially great people get their feelings hurt either way.


>instead of just interviewing 10-20 people and just pick one

Here's a realistic proposition. HR just wants to inflate numbers so that they seem busy looking for the right fit. Keep posting open for 1 week, manually filter for another week, invite people, employ one. Plenty of people with degrees looking for jobs right now, I don't see what's the issue with just trying one. Companies desperately look for the "magic" applicant that checks all boxes, while also trying to pay them almost minimum wage.


If your hiring pipeline is employing a filter that a) is not better than a random chance and b) is expensive to implement get rid of the filter.

Instead of spending all those resources on resume filtering, hire resume blind. Instead of using llms for a thing they are bad at (subjective decision making) use them to build a deterministic process that isn’t.

Use work sample hiring as the filter. Make the work sample automatic to sign up for and judge.


great question. The alternative is not accepting 1000 applicants. Nobody said you have to keep up your job posting for two weeks, or two hours for that matter. stop once you have enough. Enough is defined by whatever number you would have filtered to. In the rare case none of the first ten applicants were appropriate, just open it again until youve got another tranche.


You are assuming quality applicants are evenly distributed in terms of time of application - they aren’t. If you cut off at 100, you will only get a sample of people spewing fully automated application bots which mostly aren’t what you want.


If that's true, then it suggests an easy fix: leave your application up for four hours, then discard all applications you get for the first two.


That's just another type of randomness (who was online during the short time the posting was opened).


"Being online during the short time" heavily favors bots. In a way, AI screening tools saved us from the future of everybody buying resume-spamming-as-a-service because it became as important to use these as getting a college degree.


right. But if you go online and look for a job, then the ones you are available at that moment will actually read your application


At least this would not force applicants to fine tune their applications to the latest LLM bullshit bingo.


> If you have 1000 applications for every job, and you know that a bunch of these applications are "a bad fit", to put it mildly, you have to filter. And you cannot realistically give every resume a good, human look.

At 10 seconds per resume, it would take you 3 hours to go through all 1000 resumes. I don't know what you consider "good" and "human", but my human eyes could easily do good enough, fully manual pre-screening at a rate of 1 requisition per day.


> At 10 seconds per resume, it would take you 3 hours to go through all 1000 resumes.

At 10 seconds per resume, I would not assume that you're screening better than the LLM.


You could remove the least relevant resumes very quickly. Maybe not 10 seconds, but 30 seconds per resume for sure.

What I hear happens now: people apply for a "Senior Golang SWE" with 2 years of experience with C#. Or, relevant for hiring in the US, the job posting says the visa is required, but people apply without it anyway.


It’s weird because unemployment is still quite low, right?

Maybe a platform could be designed where candidates have one account for multiple companies, and the number of applications on the platform is limited to, say, ten per person per month or something. To get people to be selective. I don’t think this should be the only way to apply, but maybe the companies involved could look there first.


This reasoning isn't.


The goal for the interviewer is to have a much higher ratio of good/bad candidates after the first screening. This means the more costly time you spend on the second step has a better return.


So the question is: is the score given by this system correlated with candidate quality? I don't think this post gives enough data to know.


So the logical solution is for candidates to submit multiple applications with slight variations to their contact info, "John Schmidt", "John J. Schmidt", "John J. J. Schmidt", "John Jacob J. Schmidt", "J. J. Jingleheimer Schmidt", etc.


Hey, that's my name too!


    Whenever I send them out
    The filters always route: 
    "Spammer: John Jacob Jingleheimer Schmidt"
    [N/A] [N/A] [N/A] [N/A]


It's a good day to have 3 middle names.


If you have no requirements for accuracy, you can just advance 35% of applicants at random.

If the first 50 people who apply are all bots, why are you reading resumes in order of submission?


One of the first things you do when hiring is to set a period and randomize order of resume when reviewing because early application is not a strong signal.


Sounds like you're pretty bad at hiring pipelines.


I wonder if you could solve this for programming specifically as follows:

1. Give them some easy leetcode questions. Nothing that a competent programmer would have any problem with.

2. If they pass, ask for a deposit of like $20. Shouldn't be an issue for people who are actually serious.

3. Do more simple leetcode questions but this time on zoom so you can tell if they are using AI. If they pass that they get the deposit back.

(Yeah I know there are real-time interview cheat AI programs but based on what I've seen on demos of them it's super obvious when they're being used.)

Probably not practical but just a thought!


This selects for desperation.


I'm not going to do any of those 3 things for a would-be employer.


They don't seem like unreasonable things to me so I guess it also helps filter out unreasonable people!


I have a fair amount of code available via open source repositories. As in the kind that real people actually use, not just up on my personal GitHub.

If someone is going to ask me to do leetcode problems it means they haven't done their research on me. Why would I want to work for them if they won't spend the time to do this? Digging into my publicly available background should be enough to tell them I am or am not of the caliber they're looking for in terms of hands on keyboard development.


Number 2 is so unusual I would immediately flag the company as a scam. How is asking for money a reasonable approach? There are alternative ways, easier too depending on country, and all you'd be doing is selecting for desperation while also spreading bad rumors from all the people who nope out when they see such malpractice.


Yeah it's unusual. Nobody does this. It was an idea.

What are the alternatives if you are getting over 100 applicants an hour? If you have genuine ideas I'm curious.


there have got to be better ways to optimize pipelines. maybe set a limit on number of applications for a role based on the number you/your team can reliably go through them. if more are needed then open the role for another wave of applications.


Except the bit about ranking a decades long S3 engineer lower than an intern with GitHub repo.


Are you suggesting using AI/Agents to apply for roles?


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: