I’m struggling with the utility of this logic. The argument seems to be "because malware can intercept /proc output, any tool relying on it is inherently unreliable."
While that’s theoretically true in a security context, it feels like a 'perfect is the enemy of the good' situation. Unless the author is discussing high-stakes incident response on a compromised system, discarding /proc-based tools for debugging and troubleshooting seems like throwing the baby out with the bathwater. If your environment is so compromised that /proc is lying to you, you've likely moved past standard tooling anyway.
I just installed it and it seems really promising. Glad you shared it here.
I’ve spent more time than I care to admit searching for a good keyboard app in the App Store, and I’ve tried a lot of them. This one never surfaced for me in any of my usual searches, which is a shame (likely more on Apple’s search than on you).
I really like the T9-style approach, and I appreciate the clean App Privacy section and straightforward privacy policy.
"Your Affinity V2 license (via Serif) remains valid and Serif will continue to keep activation servers online. But please note that these apps won’t receive future updates."
Instead, NextDNS is very likely abusing the EDNS Client Subnet feature to provide website operators with a spoofed client location. Much more simple and less nefarious.
> A certificate has to be signed by a trusted CA (one your browser already trusts).
Yes.
> A DNS provider could mint a self-signed cert for pornhub.com, but your browser would reject it immediately.
I never said anything about the DNS provider minting any certificates, and explicitly said that the certificate would be provided by PornHub's servers and merely relayed -- verbatim -- through the DNS provider. As well as the rest of the TLS negotiation.
> Instead, NextDNS is very likely abusing the EDNS Client Subnet feature to provide website operators with a spoofed client location.
That's what they are doing now, yes. What I propose is how they can continue to make it work once the website operators catch on and start looking at the ASN information of the source IP address of the HTTP connection.
I am well aware of how CAs and the Web PKI model and TLS work.
Ah, ok... a transparent proxy just to hide the origin IP. Thanks for clarifying. A lot of people are assuming full proxying, but I understand you were describing a hypothetical.
Right. What I proposed is scarcely different from doing HTTPS over a SOCKS5 proxy. It's just that the proxy would infer your destination from the ClientHello rather than being instructed by the client in advance (Edit: and it would have to assume port 443 -- a safe assumption in the context of a service whose feature is bypassing website content blocking).
No, I don't think they are proxying traffic. They are giving the website operators a spoofed EDNS Client Subnet which tricks them into thinking the traffic is coming from a different geolocation.
ECS is popular with third party DNS providers with open resolvers, like Google, but not all software that sends DNS queries sends large DNS packets with EDNS extensions and some www users avoid open resolvers
One of the things that I noticed about NextDNS when they announced their service on HN is that like the other public caches, they too sent ECS, but they claimed they could "anonymise" it
Late reply. I don’t have any iCloud+ subscription and thus don’t have iCloud Private Relay. The NextDNS iOS app is broken and abandoned (no updates since 2020).
I’m also puzzled by the Instant On divestiture. In the original filing and press release the DOJ does call out SMB, even though most of the discussion is about enterprise markets:
My guess is that by forcing HPE to spin off Instant On, the DOJ hopes to score a modest PR win by claiming it protected small businesses, by preserving one of the few turnkey, cloud-native wireless solutions for SMBs. Since Instant On represents only a tiny portion of the deal, though, it seems odd that it was singled out.
HPE consistently struggles to retain talent and foster growth post-acquisition. Integration is hampered by decades of IT cruft, leading to a sluggish tech stack and a deeply bureaucratic culture. Like many public companies, they also suffer from a lack of long-term focus.
While that’s theoretically true in a security context, it feels like a 'perfect is the enemy of the good' situation. Unless the author is discussing high-stakes incident response on a compromised system, discarding /proc-based tools for debugging and troubleshooting seems like throwing the baby out with the bathwater. If your environment is so compromised that /proc is lying to you, you've likely moved past standard tooling anyway.