URL短縮化サービスは正しいURLを返すWebAPIを備えればどうか（でも書いているうちに問題に気付いた）

古い記事だけど。

将来Twitterをつかったフィッシング「twishing」も？--専門家がセキュリティを懸念

Twitterはまた、長いURLアドレスを、リダイレクトサービスや短縮サービスを使用して短くするようになっている。これは、同サービスで投稿できるメッセージの長さが140文字までに限定されているためである。Porter氏は、このURLの短縮機能が原因で、ユーザーがリダイレクト先のページやどこにリンクされているのかをアドレスを見るだけでは把握することができなくなっていると述べる。そのため、悪意あるユーザーがこの機能を悪用し、悪質なウェブサイトやJavaScriptを埋め込む可能性があると警告する。将来的にはTwitterを利用したフィッシング詐欺（同氏はこれを「twishing」と呼んでいる）が登場すると予想している。

この記事が書かれてから4ヶ月近く経つのにいまだにTwitterはTinyURLを使っているようなので、やっぱり短いURLにするという需要、短いURLが求められる必然性というのはあるんじゃないかと思う。
かといって指摘される悪質なWebサイトへの誘導の危険性は排除しなければならんので、どうしたらいいかなと考えていたのだけれど、

URL短縮化サービスは、すべからく正しいURLを返すWebAPIを持たなくてはならない、というふうにするのはどうか。
そのAPIのインタフェースも統一化して、短縮化したURLのキーをAPIに投げると、正しいURLを返す、というもの。

こういうインタフェースが各URL短縮化サービスに配備された上で、各種ブラウザやTwitのような各種Webクライアントが、短縮化URLを処理する際はまずWebAPIを叩き、正しい実際のURLを確認した上でユーザにそれをアラートする、という機能を備えれば、短縮URLでもアクセス先情報を得ることができてよいのではないか。
もちろん、そうするとその共通仕様を悪用して、ウソの接続先を教える短縮サービスなんかも出てきそうだけど、その辺はサービスをホワイト/ブラックリスト的に処理するとか。

とか書いてて、これはいいアイデア！とか自分で思ってたりしたんだけど、よく考えるとそもそも最初の、「そのURLが短縮URLであるということをどうやって知るか」というところで詰まってしまった。
「実際のURLを確認するI/F」とは別に、「短縮URLサービスであるかどうかを確認するI/F」があればいいかもだけど、URLがある毎にそのドメイン全てにまず「短縮URLサービスであるかどうかを確認するクエリ」を投げるというのも、かなりウザイ。
Webクライアント側でキャッシュを持ってもらって、新しいドメインにアクセスする毎にとりあえず一回だけ「短縮URLサービスであるかどうかを確認するクエリ」を投げてもらい、レスポンスがあれば短縮URLサービス、なければ通常のURLとしてキャッシュしてもらうという手もあると思うけど、それにしたってキャッシュがどでかくなりそうだし、最初WebAPIに対応してなくて途中から対応した短縮URLサービスはどうするの？とかが問題。
というかそこまでいくと、たかだか短縮URLサービスのためだけにそこまで重い仕様決めるか？みたいな感じだし。

なんかいい手ないかな。