短縮URLについて再び

短縮URLのリスクと対策 で書いたように、短縮URLの気持ち悪さを常に感じている。それは書いたようにセキュリティ上のリスクを感じているからでもあるのだが、正直、フィッシングサイトやマルウェアを踏んでしまう可能性というのは、ブラウザやOS側できちんと対策されていて、リンクを紹介しているフォローワーやその内容などからきちんと判断さえしていれば、それほど高くはないと思っている。

それよりも、短縮URLはインターネットのトラフィック制御において余計な一レイヤを追加する。

ネットワークでのトラフィックは実際のパケットの流通以外にも、相手先の特定および中継装置による転送の適切な経路選択というのが必要になる。前者はいくつかのレイヤによる名前解決であり、後者がルーティングだ。前者を解決するために、FQDNからIPアドレスへの変換をDNSが行い、さらにはIPアドレスからイーサネットアドレスへと変換される。この変換のためにも、それ専用のパケットが飛び交うことがあるため、キャッシュしたり、プリフェッチしたりと様々な工夫が行われている。先週発表されたGoogleのパブリックDNSサービスもその一環だし、ChromeFirefoxに導入されているDNSプリフェッチやWindowsに入っているキャッシュ可能なDNSリゾルバもそのためのものだ。

短縮URLを使うと、このDNSでの名前解決のオペレーションが1つ増えることになる。

たとえば、GoogleマップのあるURLを短縮するために、短縮URLを使ったとしよう。例として、bit.lyを使ったとすると、ブラウザからはbit.lyへの名前解決を行いアクセスした後に、今度はgoogle.com(もしくは、google.co.jp)の名前解決を行うことになる。短縮URLを使わなかった場合は、google.comの名前解決だけで済むにも関わらず。しかも、bit.lyにアクセスしてからでないと、本来の最終的な到達先のFQDNがわからないので、プリフェッチも不可能だ。いくらウェブの高速化を図っていても、ここがボトルネックと成り得る。

さらに、ウェブアクセス解析を行う場合も、この余計な一レイヤが邪魔になる。ウェブアクセス解析の際、リファラを参照しユーザーの導線を分析することは良く行われるが、短縮URLを利用された場合、すべてのリファラが不定*1となり、本来の参照元がわからなくなる。bit.lyなどの短縮URLサービスでは、その短縮URLについての情報を参照できるページを用意している。たとえば、このブログのURLをbit.lyで短縮したもののbit.ly上の情報ページはhttp://bit.ly/gROal+ である。ここのReferrersタブをクリックすると、リファラーが参照できるし、これはAPIを使えばJSONで取得もできるので、おそらく短縮URLサービスとウェブアクセス解析を統合することは出来るが、数多い短縮URLサービスに適宜対応していくのもウェブアクセス解析サービス/ソフトウェア側も大変だろう。

ここでいろいろと課題を書いたが、短縮URL自身は、長くなってしまったURLの短縮に確実に効果はあるし、有用なものである。140文字という制限を持つTwitterの普及によって一躍利用が増えたが、それ以前にもウェブアプリケーションが吐き出すURLなどは長くなる傾向があり、メールなどでも途中で改行されてしまったり、コピー&ペーストでミスが発生したりといろいろな課題があった。とすると、この有用なサービスを、ここで述べた余計なレイヤを持つことなく、さらには前に説明したセキュリティ的な問題を解決しつつ利用する方法はないだろうか。

実は、ここまで書いたことは、Joshua Schachterの受け売りである。

on url shorteners - joshua schachter's blog

ここで彼は、1つの解決策として、短縮URLの生成はウェブサービス提供側が行えば良いと提案している。たとえば、新聞社のサイトが自社のサービスとしてTwitterでつぶやく人ユーザー向けにそのURLを短縮して提供するのだ。確かに、これならば、余計なDNSの名前解決も発生しないし、セキュリティ上の問題もない。ウェブアクセス解析でも自社で短縮URLを生成しているのだから、問題はない。どこまで実現可能かわからないが、1つの解決策ではあるかもしれない。

1つ問題があるとしたら、ドメイン名自身が長いサイトだ。こればかりは、そのようなドメイン名を取得してしまったことを後悔してもらうしかないのか。

*1:bit.lyの場合はリファラを削除しているようだ