Intercepting t.co links using DNS rewrites
41–50 of 60 posts
Re: Intercepting t.co links using DNS rewrites
#42If (hypothetically at least) the "go service" is running on the device, then if one controls DNS on the device, one can set the A record for the t.co domainname to the address of the go service. In that case, does one still need a "reverse proxy".
Re: Intercepting t.co links using DNS rewrites
#43Earlier quoted context omitted.
Is your argument that it shouldn't be possible for a user to intercept t.co in this way? Seems like a perfectly valid use case (sidecar process to unwrap 9 layers of redirects from an anonymous browsing context). If the sidecar is validating the original t.co certs and you trust it then what's the problem?
> Is your argument that it shouldn't be possible for a user to intercept t.co in this way? Not necessarily; the argument is that it's indistinguishable from a malicious MiTM. I think this is a great and legitimate use, but it's also probably something that website providers should be able to make themselves resilient against (or, at the least, be able to audit when it happens).
Re: Intercepting t.co links using DNS rewrites
#44What is this trying to protect from? You see the actual URL in the tweet. Are you worried about redirects, if so why?
Additionally if I want to share a URL with friends it's usually polluted with all sorts of nonsense query parameters, this tool strips them and gives you a nice clean one.
As for the tracking element yeah, the link shortening services will still see my IP connecting to the service, doing a head request, just with a different user agent (whatever the one go's stdlib sets). One extra layer could be to move the go service out of the network, but tbh I didn't start this project with these considerations in mind
Re: Intercepting t.co links using DNS rewrites
#45I wish there was an easier way to uniformly rewrite links across applications, one which annoys me is Reddit - they seem incapable of consistently linking to content on their own site, some could be fixed with a greasemonkey script but that doesn't work on mobile or across apps. But this is part of a wider pattern of the internet becoming deep fried, instead of a link we get a short code to a facebook page with a bot…
Good phrase. I've frequently heard the term "Kentucky Fried Education" applied to the decay of schools and universities under the influence of big-tech mediocrity. My Digital Vegan response would be that "heavily processed" content harms your intellectual health because it's not fresh and has no vitamins :)
Ted Nelson anticipated this "death by indirection". Some of his early writings on hypertext still seem like they're from a future we might one day get to. The idea that links should be bi-directional, and how different the Internet would be, is still mind-blowing.
Most of the problems you describe stem from the mediating platforms being fundamentally controlling and dishonest. Everything is a work-around to around a work-around... all the way down.
> will never happen
I get the shrugging cynicism. But to me it's a good thing they're too broken to change. Let these festering sewers of low-quality content digest themselves and make room for new growth.
Re: Intercepting t.co links using DNS rewrites
#46Will this show up in Certificate Transparency logs?
Browsers could in theory contribute data but the infrastructure to support that would likely to be orders of magnitude bigger. I'm scared even thinking about going down that rabbit hole due to the expectation of what would be found (MITM evidence). :_(
Re: Intercepting t.co links using DNS rewrites
#47Maybe I’m missing something, but it seems like this doesn’t need to be a DNS rewrite at all. Couldn’t you just set a proxy server for outgoing requests that passes through for ones that aren’t a redirect? Or is the trade off there performance (since you’re proxying every request instead of just certain DNS names)?
Re: Intercepting t.co links using DNS rewrites
#48That 9-hop shortening example is disgusting, I wonder if that could be alleviated by introducing some protocol: 1. Make all shortening services append a `This-is-a-shortening-service: true` header to all the responses they send. 2. When a link is added to a shortening service, check if the response from the link has the header above and resolve the destination, recursively.
Re: Intercepting t.co links using DNS rewrites
#49I wish there was an easier way to uniformly rewrite links across applications, one which annoys me is Reddit - they seem incapable of consistently linking to content on their own site, some could be fixed with a greasemonkey script but that doesn't work on mobile or across apps. But this is part of a wider pattern of the internet becoming deep fried, instead of a link we get a short code to a facebook page with a bot…
> the internet becoming deep fried Good phrase. I've frequently heard the term "Kentucky Fried Education" applied to the decay of schools and universities under the influence of big-tech mediocrity. My Digital Vegan response would be that "heavily processed" content harms your intellectual health because it's not fresh and has no vitamins :) Ted Nelson anticipated this "death by indirection". Some of his early writin…