Hacker News: mvkg

New comment by mvkg in "I still prefer MCP over skills"

mvkg — Fri, 10 Apr 2026 17:24:44 +0000

If the tool fails for some reason, couldn't an overly eager agent attempt to fix what's blocking it by digging into the tool (e.g. attaching a debugger or reading memory)? I think the distinction here is that skill+tool will have a weaker security posture since it will inherently run in the same namespaces as the agent where MCP could impose additional security boundaries.

New comment by mvkg in "The Wi-Fi Revolution (2003)"

mvkg — Sat, 18 Oct 2025 02:30:43 +0000

5GHz certainly helps, but congestion/co-channel interference can still be an issue in high density environments, especially in a multi-user environment like an apartment complex where nothing is coordinated. The addition of 6GHz will help alleviate this problem too, but a lot of consumer gear seems to default to the widest channels possible.

Also, your glass door probably has Low-E glass which has a metallic coating.

> The future is probably just having multiple wifi APs wired up and then just running extremely fast but low range wifi.

This is somewhat the case, but it is limited. For example, in 5GHz there are 21x 20MHz channels available. In a highly dense environment, this can support roughly 30x devices per channel well and 50x devices per channel with some degradation.

Limiting the TX power on an AP can help, but it's not a panacea since clients always transmit their control frames at their default power (usually ~15dBm). There have been some improvements to this in .11ax, but depending on the spatial organization of the devices, it can only do so much.

New comment by mvkg in "Universal optimality of Dijkstra via beyond-worst-case heaps"

mvkg — Fri, 25 Oct 2024 21:50:32 +0000

The paper's claim for Dijkstra's is it's "a single algorithm performs as well as possible for every single graph topology". A* is an augmented version of Dijkstra's only applicable when there is a priori knowledge of a good heuristic for the topology (e.g. manhattan distance in a cartesian plane). Since there is almost certainly no heuristic that is universally optimal for all topologies, A* shouldn't be more universally optimal than Dijkstra's (and can probably perform worse given a bad heuristic).

New comment by mvkg in "Multimillion-dollar L.A. heist was seamless, sophisticated, stealthy"

mvkg — Wed, 10 Apr 2024 12:41:24 +0000

802.1x allows for the client to validate the authentication server by way of X.509 certificates, although this normally does require manual configuration since there is no global namespace to tie an ESSID to like there is for domain names in normal TLS. Mutual asymmetric key auth is available through EAP-TLS as well, but I could see that being a rare feature on cameras.

New comment by mvkg in "Multimillion-dollar L.A. heist was seamless, sophisticated, stealthy"

mvkg — Wed, 10 Apr 2024 12:29:56 +0000

802.11w

New comment by mvkg in "Pornhub Blocked in Texas"

mvkg — Thu, 14 Mar 2024 21:12:57 +0000

As of TLS 1.3, the ClientHello (which includes the Server Name Identification (SNI) extension) is still sent in plaintext. There is a current draft for encrypted client hellos[0], but I don't think its adoption is widespread. QUIC appears to encrypt the ClientHello; however, it does not protect from an attacker which can observe the initial connection packets[1].

[0]: https://datatracker.ietf.org/doc/draft-ietf-tls-esni/

[1]: https://www.rfc-editor.org/rfc/rfc9001.html#name-security-of...

New comment by mvkg in "Quicssh: SSH over QUIC"

mvkg — Thu, 27 Apr 2023 19:50:07 +0000

I believe section 7 of RFC 9000 would allow for the creation of a handshake protocol which could conform to SSH without the need for including x509.

New comment by mvkg in "Quicssh: SSH over QUIC"

mvkg — Thu, 27 Apr 2023 17:15:42 +0000

It is every bit as bad. QUIC streams could map nicely to the SSH model of discrete channels. Sure, you can run it over tcp/443 and have it look like a normal TLS connection to anything that isn't monitoring the traffic patterns, but it's effectively just adding a TLS pipe which only achieves the use of QUIC's congestion control algorithm and handshake but nothing else. I would love to see an SSH implementation which uses QUIC correctly; this isn't it.

edit: it also has a hardcoded parameter to not validate certs which defeats the whole purpose of it using TLS in the first place... (https://github.com/moul/quicssh/blob/5f5a17c3431a39a8287467d...)

New comment by mvkg in "ZLibrary domains have been seized by the United States Postal Inspection Service"

mvkg — Fri, 04 Nov 2022 06:33:51 +0000

You mirror Z-Library but don't support TLS on any of your sites. This seems like an odd choice. What is your threat model?

New comment by mvkg in "Whatever happened to SHA-256 support in Git?"

mvkg — Thu, 23 Jun 2022 22:33:14 +0000

Regarding the collision attack replacement check, do you know if that is carried over into other git implementations (e.g. libgit2)?

New comment by mvkg in "Mozilla patches two use-after-free vulnerabilities (ab)used in the wild"

mvkg — Sat, 05 Mar 2022 20:09:49 +0000

I have found brave to be a decent chromium-based browser for android if the only addon needed is for ad blocking. It has a bottom toolbar provides a similar experience to the firefox bottom address bar.

New comment by mvkg in "Please rename aux.py"

mvkg — Tue, 14 Dec 2021 15:14:03 +0000

What were the PRN and AUX files used for?

New comment by mvkg in "Ask HN: What are the best and worst command-line interfaces you have used?"

mvkg — Wed, 24 Nov 2021 21:27:42 +0000

In recent versions of (maybe only GNU?) `tar` you can leave off the `z` flag and it will still decompress based on the filename.

New comment by mvkg in "Show HN: Grep with colours written in Go"

mvkg — Wed, 06 Jun 2018 01:06:40 +0000

A quick look at the source shows that it appears to be linear and just uses `strings.Contains` or `r.MatchString` on each line, so I don't think it has any of the optimizations that are built into `ag`.

New comment by mvkg in "Server-Side I/O Performance: Node vs. PHP vs. Java vs. Go"

mvkg — Wed, 13 Dec 2017 18:07:56 +0000

https://peabody.io/post/server-env-benchmarks/

New comment by mvkg in "The fifth hyperfactorial: 5⁵ × 4⁴ × 3³ × 2² × 1¹ milliseconds is exactly 1 day"

mvkg — Sun, 10 Dec 2017 05:43:48 +0000

The two 'true' statements show that 12345678910111211 == 12345678910111212 transitively, which is obviously not possible.

New comment by mvkg in "Ask HN: What software/service helps you be an effective remote developer?"

mvkg — Sun, 10 Dec 2017 05:28:59 +0000

For what purpose exactly? Surely you don't have multiple developers writing code with one cursor.

New comment by mvkg in "Microsoft leaks TLS private key for cloud ERP product"

mvkg — Fri, 08 Dec 2017 17:27:24 +0000

With TLS, the symmetric encryption keys are always newly generated regardless of the cipher suite chosen; the difference with the ephemeral cipher suites is how the keys are communicated.

Without forward secrecy, the client chooses the premaster secret, encrypts it with the server's public key, and sends it in the ClientKeyExchange message. With forward secrecy, the client receives signed ServerDHParams in the ServerKeyExchange and responds with ClientDiffeHellmanPublic in the ClientKeyExchange.

New comment by mvkg in "Incremental Backups Using GNU Tar and S3"

mvkg — Sat, 02 Dec 2017 21:11:35 +0000

The threat for http to https transactions is that man in the middle can rewrite, drop, or add data before the user reaches the https site. See sslstrip[0] for an example of this attack.

[0] https://moxie.org/software/sslstrip/

New comment by mvkg in "A brief history of IPv4 address space exhaustion"

mvkg — Fri, 26 May 2017 13:03:42 +0000

I was a bit surprised to see that it wasn't published on April 1 and got renewed multiple times.

Some parts of it are laughable such as

       IPv10 support on "all" Internet connected hosts can be deployed
       in a very short time by technology companies developing OSs
       (for hosts and networking devices, and there will be no
       dependence on enterprise users and it is just a software
       development process in the NIC cards of all hosts to allow
       encapsulating both IPv4 and IPv6 in the same IP packet header.

But it does have an interesting take on stateless IPv4 <-> IPv6 communication, specifically IPv4 -> IPv6. Obviously it wouldn't work as described without a full deployment, but it seems like something could be done there.

For instance, if an IPv4-only host wanted to communicate to an IPv6-only host, it could send packets to a well-known NAT46 anycast address with an IP option of the destination host. The NAT46 host could then create the IPv6 packet with the correct destination and IPv4-mapped source.

He suggested using the IPv4 routing table for IPv4-mapped IPv6 addresses, which wouldn't be loop-free unless every router was dual stack and did the same thing. However, with what I described, it seems like any dual-stack host (or router) could perform the translation in a loop-free manner.