Comments URL: https://news.ycombinator.com/item?id=47725942

Points: 25

# Comments: 7

The attacker can impersonate the victim, get a valid x509 certificate issued to it, and create a perfect replica of their website/api/whatever.

The attacker can perform a man-in-the-middle attack on the victim - record traffic, inject traffic, manipulate traffic, etc.

The attacker can just deny access to the victim - just drop packets meant for the victim.

RPKI only secures the ownership information of a given prefix, not the path to that prefix. Under RPKI, an attacker can still claim to be on the path to a victim AS, and get the victim's traffic sent to it.

The solution to this was supposed to be BGPSec, but it's widely seen as un-deployable.

Now it's "Microsoft Copilot" which is different from "Microsoft 365 Copilot", which is different from "Copilot Chat" and from "GitHub Copilot", and the many other flavors.

It's a mess.

Still, their developer-focused offering seems to be "GitHub Copilot", which among other things includes "GitHub Copilot CLI" [1], their terminal-based agent. It's not bad.

[0]: https://en.wikipedia.org/wiki/Microsoft_.NET_strategy

[1]: https://github.com/features/copilot/cli/

I think that people often compare apples to oranges by comparing the “copilot” they have in Windows/Office/Teams etc to Claude Code which is ridiculous.

A better product to compare Claude Code to would be “Github Copilot CLI”, but I haven’t seen the two seriously compared anywhere.

Comments URL: https://news.ycombinator.com/item?id=47531268

Points: 2

# Comments: 0

Comments URL: https://news.ycombinator.com/item?id=47354436

Points: 4

# Comments: 0

Everyone cares. In fact, there's an entire industry of tools being developed to solve this very problem. The current governance gaps are obvious to anyone who's ever used an agent.

We are still in the very early stages of all of this. The capabilities of current models are ahead of our engineering practices, and other organizational practices for that matter. Everyone is new to this.

Currently, engineers work with loose specifications, which they translate into code. With the proposed approach, they would need to first convert those specifications into a formally verifiable form before using LLMs to generate the implementation.

But to be production-ready, that spec would have to cover all possible use-cases, edge cases, error handling, performance targets, security and privacy controls, etc. That sounds awfully close to being an actual implementation, only in a different language.

For non-SaaS products it doesn’t matter. Your customer’s security teams have their own scanners. If you ship them vulnerable binaries, they’ll complain even if the vulnerable code is never used or isn’t exploitable in your product.

We went from data mining to data fracking.

[0]: https://blog.pragmaticengineer.com/stack-overflow-is-almost-...

[1]: https://www.niemanlab.org/2026/01/news-publishers-limit-inte...

[2]: https://www.theregister.com/2024/05/16/wiley_journals_ai/

[3]: https://www.heise.de/en/news/OpenStreetMap-is-concerned-thou...

How am I confusing the two? My whole point was the same as yours - that the existence of lawful intercept is a separate issue and that the focus should be on securing telecoms.

A hacker in control of a telco can do as they please regardless of any backdoors or lawful intercept systems. They can just use regular network functions to route calls wherever they want.

The problem is that telecoms are very large, very complex environments, often with poor security controls. Investing in better controls is hard, time-consuming and expensive, and many telecoms are reluctant to do it. That's not great great since telcos are prime targets for nation state hackers as Salt Typhoon shows.

Hacking the lawful intercept systems is very brazen, but even if the hackers didn't don't go as far, and "only" gained control of normal telco stuff like call routing, numbering, billing, etc. it still would have been incredibly dangerous.

And since you mentioned scanning the IPv4 address space for DNS servers - I did that as well at a some point for a product I've built (and even have a patent on). The list of servers you're going to get with a naive scanning approach is not what you want. It won't include the servers you probably want (such as the customer-facing DNS servers of ISPs) and will include an insane amount of junk like home routers or weird IoT devices that expose their port 53. Hit me up via the email in my profile if you want to chat.

[0]: https://stat.ripe.net/

[1]: https://www.submarinecablemap.com/

[2]: https://resolve.rs/

Comments URL: https://news.ycombinator.com/item?id=46893430

Points: 1

# Comments: 0