Simple, elegant. Love it.
I wonder if there would be some way to redirect kinda even if you weren't on your home network... You mention using a VPN? Which one?
Intercepting t.co links using DNS rewrites
21–30 of 60 posts
Re: Intercepting t.co links using DNS rewrites
#22What is this trying to protect from? You see the actual URL in the tweet. Are you worried about redirects, if so why?
Your clicks being logged by Twitter.
It’s not like the original URL is somehow encoded in the short URL, so this bot still has to request from t.co (and everywhere in between) to get the target.
Re: Intercepting t.co links using DNS rewrites
#23That 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
#24That 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.
awesome-url-shortener: https://github.com/738/awesome-url-shortener
/? shorturl api OpenAPI https://www.google.com/search?q=shorturl+api+openapi
- TinyURL OpenAPI: https://tinyurl.com/app/dev
- GH topic: url-shortener: https://github.com/topics/url-shortener
A https://schema.org/Thing may have zero or more https://schema.org/url and/or https://schema.org/identifier ; and then first the ?s subject URI that's specified with the `@id` property in JSONLD RDF.
You can add string, schema:Thing, or URI tags/labels with the https://schema.org/about property.
Re: Intercepting t.co links using DNS rewrites
#25Will this show up in Certificate Transparency logs?
Re: Intercepting t.co links using DNS rewrites
#26Earlier 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).
If I configure my computer that I own to use my CA and proxy certain traffic, I don't see how that's any website's business. They have as much right to audit how I've set up my computers as I do theirs.
Re: Intercepting t.co links using DNS rewrites
#27Earlier quoted context omitted.
> 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).
If I configure my computer that I own to use my CA and proxy certain traffic, I don't see how that's any website's business. They have as much right to audit how I've set up my computers as I do theirs.
There are different models here: for every person like you who's trying to reasonably proxy their local traffic, there's a nation state, overbearing educational software provider, &c. who's trying to get access to sensitive and potentially life-affecting communications. When it comes to things like finances, private chats, &c.
I think there's a reasonable argument to be made that it's in the website's (and my!) interests to be able to detect and prevent these kinds of man-in-the-middling.
Re: Intercepting t.co links using DNS rewrites
#28If you want to hear of one of the worst URL forwarding "services," Facebook is it. They got so bothered by people stripping all the tracking data from links they were sharing that they actually embedded all their tracking within the primary portion of the URL. If you want the truly original URL the only way to get it is to abuse one of their APIs.
Re: Intercepting t.co links using DNS rewrites
#29Earlier quoted context omitted.
If I configure my computer that I own to use my CA and proxy certain traffic, I don't see how that's any website's business. They have as much right to audit how I've set up my computers as I do theirs.
There are different models here: for every person like you who's trying to reasonably proxy their local traffic, there's a nation state, overbearing educational software provider, &c. who's trying to get access to sensitive and potentially life-affecting communications. When it comes to things like finances, private chats, &c. I think there's a reasonable argument to be made that it's in the website's (and my!) inter…
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.
Re: Intercepting t.co links using DNS rewrites
#30> I only really noticed this properly when my DNS sinkholing server (Adguard home) started blocking t.co links and I was getting an error when say, clicking a linked news article
Mission accomplished!