Intercepting t.co links using DNS rewrites

Re:Intercepting t.co links using DNS rewrites by ndriscoll on Sunday January 29, 2023 @09:09PM (#34575048)

The problem is that in practice, at least in the US, the most realistic threats are from websites you visit delivering drive-by malware (e.g. spyware and adware), which they actually do constantly. It's such a common practice that it's not even usually phrased that way, but just imagine if you exploited eBay's web servers to port scan their internal network, which is exactly what they did to customers. The responsible employees should be criminally charged for that.

It doesn't matter if it's in the websites interests. The client computer does not belong to them, and it's definitely not in the owner's interests to let others "audit" them just like it's not in web hosts interests to let us "audit" their nginx configs.

[ Parent | on HN ]

Re:Intercepting t.co links using DNS rewrites by supriyo-biswas on Sunday January 29, 2023 @10:10PM (#34575393)

IIRC comcast and friends used to intercept plaintext HTTP connections and add advertising to them, so I don’t see why you’d consider this scenario uncommon.

[ Parent | on HN ]

Re:Intercepting t.co links using DNS rewrites by woodruffw on Sunday January 29, 2023 @10:51PM (#34575586)

I think you're setting up a false dichotomy here: I believe strongly in client filtering and in empowering users to do whatever they need to do to flush out the junk that comes with the modern online experience. I do it on my own devices, though both browser extensions and a local DNS server. I'd even consider doing it with a root CA, if it came to that (but so far it hasn't).

When I say "audit," I mean in the sense that existing ecosystems like CT already provide automatic auditability of certificate issuance. We're not talking about a private company sleuthing through your computer; we're talking about a way to enforce the stated security model that most users expect when a connection is described as "encrypted."

[ Parent | on HN ]