But if you are already suspicious enough that you want to do that, you were never going to click on the original URL anyway, so it's no worse than not using bit.ly.

Not true. I know bitly and googl have those info pages, so I'll check them out when I am curious but am not sure whether I want to alert whereever it leads. I know I'll get more info at best, and don't lose anything at worst. For random URLs, I guess I could try whois lookups, but I'd be much more likely to just check it out than with a short URL which is easily checked out.

I think you missed my point.

If seeing that the bit.ly URL redirects to a known-urlcanary domain would put you off visiting the URL, then seeing the raw known-urlcanary domain (not behind bit.ly) would also be enough to put you off visiting it.

Ah, yes, if that is the alternative, then of course. I thought it was between some shortened link and an unknown domain.

So, doesn't this mean you need to have a bunch of domains, none of which look like urlcanary domains? If you hide behind something like namecheap's whoisguard (customer, not affiliated with them), that would do the trick, right?

It's easy to integrate in a scraping script though, which I thought was what this was supposed to combat.

I usually curl shortened urls, the response is either a 301/302 or an html page with a redirect (usually the latter)

If you preview a link, wouldn't it then require the bit.ly to fetch it? Or does bit.ly serve a cached copy?