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

These look very nice indeed, but almost none of their models seem to have built-in WiFi.

Even if they cost half as much, they'd be a non-starter for 99% of home users because of this.


none of their models seem to have built-in WiFi.

They have modules for Wifi and LTE so people can pick and choose during customization.

Even if they cost half as much, they'd be a non-starter for 99% of home users because of this.

Inflation is indeed sucking money out of everyone's wallet.


What even constitutes a "US-made" router?

Does it have to be assembled in the US? Does it have to have its stock firmware developed in the US? Does the SoC have to be designed by a US company? Made in a US fab?

I very much doubt that there are any consumer-level WiFi routers which would clear any of these bars, other than maybe "firmware developed in the USA."


As far as i know the hardware production, owners of the company and software development must happen in the US

A biomedical researcher in Canada had her application for permanent residency rejected due to conflicting descriptions of her current job duties and her work experience. Those "current job duties" turn out to have been hallucinated by an AI system used by IRCC (Canada’s immigration agency).

That's my own summary after reading the article. No AI involved.

I myself moved from the US to Canada and gained permanent residency a few years ago. I'm grateful that my NAFTA visa and PR applications were reviewed by real live humans, in some cases while they were sitting right in front of me.

Paywall-bypassing archive link: http://archive.today/2026.03.25-211049/https://www.thestar.c...


What is "military-grade" about its encryption?


[dead]


Uh huh. It also shows me weird gambling ads.


Use Ad Blocker.


Do you not understand why this site may not fill visitors with confidence?

Apparently you've been spamming HN with links to this thing for the past week. Eesh.


SSH is an incredibly versatile and useful tool, but many things about the protocol are poorly designed, including its essentially made-up-as-you-go-along wire formats for authentication negotiation, key exchange, etc.

In 2024-2025, I did a survey of millions of public keys on the Internet, gathered from SSH servers and users in addition to TLS hosts, and discovered—among other problems—that it's incredibly easy to misuse SSH keys in large part because they're stored "bare" rather than encapsulated into a certificate format that can provide some guidance as to how they should be used and for what purposes they should be trusted:

https://cryptographycaffe.sandboxaq.com/posts/survey-public-....


That's the point, though. An SSH key gives authentication, not authorization. Generally a certificate is a key signed by some other mutually trusted authority, which SSH explicitly tried to avoid.

SSH does support certificate based auth, and it’s a great upgrade to grant yourself if you are responsible for a multi human single user system. It grants revocation, short lifetime, and identity metadata for auditing, all with vanilla tooling that doesn’t impose things on the target system.

> multi human single user system

A rather niche use-case to promote certificate auth... I'd add the killer-app feature is not having to manage authorized_keys.


They are remarkably common in long lived enterprise Linux servers. Think eg database servers or web servers where they are of the (much longer lived) pet era not cattle era.

Not sure why you need to belittle one example just to add another


Agreed, this makes sense in principle.

But what I found, empirically, is that a substantial number of observable SSH public keys are (re)used in way that allows a likely-unintended and unwanted determination of the owner's identities.

This consequence was likely not foreseen when SSH pubkey authentication was first developed 20-30 years ago. Certainly, the use and observability of a massive number of SSH keys on just a single servers (ssh git@github.com) wasn't foreseen.


You can also sign ssh host keys with an ssh ca.

See ssh_config and ssh-keygen man-pages...


What good does certificate format do? Certainly won't make people not reuse it the same way.

> where the affected users might be surprised or alarmed to learn that it is possible to link these real-world identities.

I feel like it's obvious that ssh public keys publically identifies me, and if I don't want that, I can make different keys for different sites.


> > where the affected users might be surprised or alarmed to learn that it is possible to link these real-world identities.

> I feel like it's obvious that ssh public keys publically identifies me, and if I don't want that, I can make different keys for different sites.

You're probably not the only one for whom it's obvious, but it appears to be not at all obvious to large numbers of users.


ssh by default sends all your public keys to a server. Yes you can limit some keys to specific hosts but it's very easy to dox yourself.

Doesn’t it try one key at a time rather than send all?

True but a server that wants to "deanonymize" you can just reject each key till he has all the default keys and the ones you added to your ssh agent.

You can try it yourself [0] returns all the keys you send and even shows you your github username if one of the keys is used there.

[0] ssh whoami.filippo.io


Nice, tried it out. This wording is incorrect though:

"Did you know that ssh sends all your public keys to any server it tries to authenticate to?"

It should be may send, because in the majority of cases it does not in fact send all your public keys.


It does, and there's typically a maximum number of attempts (MaxAuthTries defaults to 6 IIRC) before the server just rejects the connection attempt.

Yep, but this is server-side setting. Were I a sniffer, I would set this to 10000 and now I can correlate keys.

Modern sshd limits the number of retries. I have 5 or 6 keys and end up DoSing myself sometimes.

This thread made me realize why fail2ban keeps banning me after one failed password entry :lightbulb:

so it's good practice to store key in non-default location and use ~/.ssh/config to point the path for each host?

What a great case of "you're holding it wrong!" I need to add individual configuration to every host I ever want to connect to before connecting to avoid exposing all public keys on my device? What if I mistype and contact a server not my own by accident?

This is just an awfully designed feature, is all.


> add individual configuration to every host I ever want to connect

Are you AI?

You can wildcard match hosts in ssh config. You generally have less than a dozen of keys and it's not that difficult to manage.


I have over a dozen ssh keys (one for each service and duplicates for each yubikey) and other than the 1 time I setup .ssh/config it just works.

I have the setting to only send that specific host’s identity configured or else I DoS myself with this many keys trying to sign into a computer sitting next to me on my desk through ssh.

Like I can’t imagine complaining about adding 5 lines to a config file whenever you set up a new service to ssh onto. And you can effectively copy and paste 90% of those 5 short lines, just needing to edit the hostname and key file locations.


I would say it's best practice to use a key agent backed by a password manager.

Specifically to use a different key for each host.

I had never thought about that. Seems like an easy problem to fix by sending salted hashes instead.

The server matches your purposed public key with one in the authorized keys file. If you don't want to expose your raw public key to the server, you'll need to generate and send the hashed key format into the authorized keys file, which at that point is the same as just generating a new purpose built key, no? Am I missing something?

SSH does have a certificate format that can place restrictions on what the user can do when connecting with that key. I'm not so sure about the hostkey side of things though.

For example: https://smallstep.com/blog/ssh-vs-x509-certificates/#certifi... you can see here that X11 forwarding is permitted for this certificate, among other things.


> get mad, think you can do it better yourself, feel the need to prove you can do better, git init, design feature with a scope exactly commensurate to your anger, forgo loved ones and human interaction, finish feature, git commit, see 5, deploy, see 5, run it 40 times just to watch it work, injecting dopamine directly into your veins, rest

This is completely 100% what motivates my most successful coding projects as well :)


You forgot the modifier "think you can do it better yourself with a shell script", as in "I will replace you with a very small shell script".

> Real or Slop?

Yeah, this is not rocket science.

I got 9 out of 10 correct, spending an average of 27 seconds looking at each one.

Let me add that I don't have a degree in computer science, barely read any of the text of any of the papers, and that I never use LLMs for anything, so I really only have a second- or third-hand idea of what their typical output looks like at all. https://snowpatch.org/posts/i-can-completely-control-your-sm...


I'm extremely skeptical about this.

24/7 trading will definitely burn a lot of extra energy in datacenters, make some speculators a little richer, and make a LOT of retail investors nervous…

But what actual real-world problem will it solve?

I for one am skeptical that more liquidity is always good. I think that having achieved $0.01 spreads, we're well-past the point of diminishing returns with high-frequency trading.


Right? Why do we even need all-day trading?

I have seen a once-daily auction proposed, which seems like a sensible approach to me.


That wouldn't be enough liquidity, and also wouldn't solve the problem if the auction happened at a specific time. Day traders would all put in their bid at the last possible moment.

What solves the day trading problem is doing chunked actions at random small intervals (like between 2-7 seconds). Then you can't put your bid in at the last moment because you won't know when it is. So your best bet is to put in your bid when you've chosen a price, knowing that it will resolve within seven seconds or less.


I do see your point regarding timing, but I don't see why daily isn't enough liquidity when, for decades, funds from trades have taken multiple days to clear.

The very existence of holiday weekends shows that it's actually totally fine if you go 72 hours without any trades resolving.


There are whole books on this, but the short summary is that there are infinite times when information can change that would affect the value of a company. Anything less than infinite trading is a compromise where the price is no longer reflective of the value. The bigger the gap in the time, the bigger the gap between price and value.

For example, if you could only trade once a day, let's say a company announces midday that some huge customer has just left their platform. Their price should drop, but without trading it can't. So now everyone knows that their value is lower, but can't do anything about it. So people who own that stock will hold their money and not make other trades, because they know they are going to lose a bunch when trading happens again.

> The very existence of holiday weekends shows that it's actually totally fine if you go 72 hours without any trades resolving.

Trading never stops. There is an entire secondary market that has after hours/weekend trading, and a tertiary private market when that one isn't open. It's just you (and all the other retail traders) who can't trade.

Which if anything proves the opposite of your point. Liquidity is so important that wealthy people set up an entire system to keep trading just so they can still have it.


> But what actual real-world problem will it solve?

I know most Americans don't travel, but are you aware that timezones exist and there's an entire world outside the US that also invests in US companies?

Why do you think global companies want to list in US capital markets instead of their own? Being the world's most desirable capital markets is a massive boon for the US economy and 24/7 trading will only accelerate this trend.


> I know most Americans don't travel, but are you aware that timezones exist and there's an entire world outside the US that also invests in US companies?

Not only am I dimly aware of the existence of these not-the-US places, but I actually live in not-the-US.

I believe I'm dimly aware of the concept of a timezone too, yeah. https://bugs.python.org/issue35829#msg385309

> Being the world's most desirable capital markets is a massive boon for the US economy and 24/7 trading will only accelerate this trend.

So, no downsides or diminishing returns to offering 24/7 trading?


>But what actual real-world problem will it solve?

Having US markets open during the rest of the world's business day.


Okay, what problem does that solve?

Yes, it seems likely.

I assume the author would have noted in his blog post if the Hebrew used in making the threats came across as non-native or non-fluent.

Machine translation is really good these days, but I still think there are some "tells" for a truly vernacular and local command of a language.


When someone makes an "offer" to a journalist to rewrite something in a way that the journalist believes to be untrue in exchange for dropping death threats against the journalist… that isn't a "nuance."

Certainly not an exculpatory one.

Do you get that point?


That is my point and that it should be in the headline.

You're confusing yourself.


To me, how the death threat is phrased is not very important. What would you drop from the title to include that?

See suggestions above by me and others.

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

Search: