LinkedIn Intro に学ぶ、Hackの有効性とその限界について

LinkedIn自体がそんなに盛り上がってないのが幸いしてか、LinkedIn Introの件は、日本ではあまり燃え上がらずじまいでした。

おさらい

先日、LinkedInが LinkedIn Intro というサービスを発表しました。
これは、iOSのメールアプリに、メールを送ってきた相手のLinkedInのプロファイルを表示できる、というサービスです。

サービス発表を受けた英語圏のメディア＆ユーザたちの反応。中にはクールだという反応もありますが、（あとで触れる理由により）おおむねブーイングです。

で、結局いろいろ釈明することになりました。
The Facts about LinkedIn Intro | Official LinkedIn Blog

このへんの経緯は、日本語ではこちらの記事がくわしいですね。
http://wazanova.jp/post/64993376597/linkedin-intro

何をしているか

増井さんが日本語で仕組みを解説されています。
iOSの標準Mailアプリにツールバーを追加しているLinkedIn Introはどうやって実現しているのか – @masuidrive blog

読んでわかるように、内容としては大変シンプルです。IMAPプロキシを作り、メールの本文にツールバーのHTMLを差し込むようにしています。
iOSのメーラーアプリには拡張するAPIなどはないので、このような強引な方法を取った（Doing Impossible）ということのようです。

問題とされているものについて

個人的には、懸念点はいくつかあるものの、上記のいくつかのサイトで言われているように、LinkedIn Introの仕組み自体がevilである、とまでは行かないんじゃないかという考えでいます。

多くのユーザが「これはMITM(Man In the Middle) だ」と発言していますが、そこは同種の攻撃とは明確に区別したほうが良いかと思います。通信の間に他者が入ること自体は特に悪いわけではなく、通信者の「意図してない」第3者が入るのが問題であるはずです。すべてのコンテンツ変換を伴うプロキシをMITMとラベル付けるのはいささか強引です。LinkedIn Introはメールのプロキシを行いコンテンツを変換してユーザに届けるサービスであることを明言しており、その利用についてはユーザの完全なオプトインです。

「LinkedInがメールの中身を見ることができる」「クラッカーから攻撃される可能性がある」という意見についてですが、これはそのサービスプロバイダを信頼するか否か、の問題に帰着されると思います。もちろん、LinkedInの以前のパスワードの流出事故はセキュリティに対する運用能力に疑問を投げかけますし、日頃のプライバシーに対する施策に不満がある人が多数いるのは事実でしょうが、「LinkedInは信頼できないから使うな」は、自分にとっては真であっても、他の人にとって真であるとは限りません。信頼できない理由について述べるのは別に構わないですが、そこで「MITMまがいのことをやって内部でメールを盗みようとしているから信頼できない」というのであればそれは論理が破綻しています。多くのユーザが、メールを預けるに値するまでの信頼をLinkedInに持っていないのならば、ただ単にこのサービスは使われないだけであり、それは悪かどうかとは別です。

問題点をあげるならば、LinkedIn Introのサイトにおいて、利用開始への誘導がかなりスムーズで洗練されており、そのせいもあってユーザが実際に「LinkedInに対してメールをプロキシしてよい許可を与えた」という認識を持っているかどうかが怪しいことです。これはもちろんLinkedIn Introの仕組みの問題というより実装運用の問題ですし、最初からブログで仕組みを詳らかにしていることを考えると、隠蔽しようという意図は別になかったものと思われます。しかし、MITMと叫ぶ人にとってはおそらく認識がやはり違っていたのでしょうし、そのギャップが発生したことについては真摯に受け止めるべきです。

あと、細かいやり方として、iOSの構成プロファイルをユーザにインストールさせるのを、あたかもアプリインストールと同じくらいの気持ちでやらせてしまうのは、今後おなじようなことをするサービスが多数出てきてしまうとカオスになるのが目に見えるので、あまりよろしくないかと思っています。特に、構成プロファイルには証明書やプロキシ設定なども含められるので、それこそMITMの仕掛けを潜り込ませるのは簡単です。グロースハック的には離脱者数を抑えるためにもぜひやりたい手段なのでしょうが、たとえ構成プロファイルの内容を公にしようが、やめておいたほうが賢明かと思います。

Hackのスケーラビリティ

さて、以下から本題です（が、同時に駄文です）。

今回の事例において、自分が感じたのは、ひとことで言うと「Hackというのはなかなかスケールさせるのは難しいな」ということです。

今回のLinkedIn Introのアプローチは、いわゆる「Hack」として分類されますが、特に技術的に高度、というわけではありません。それをやっちゃうか、という点はさておき、大体のエンジニアにおいて何をやっているか理解できないほどのものではないでしょう。Hackの用法として、技術的に高度なものであることとは別に、このような「標準的な方法からはずれているが有効な問題解決手段」というものがあります。

僕自身も感じることですが、あるひとつの技術的なHackによって世界が陥っていた閉塞な均衡が破られるというのは、技術というものの持つパワーのもっとも劇的な表出であるとも言え、麻薬的に惹かれるものがあるのは否めません。しかしながら、それを全世界に適用するというのはなかなか難しいものです。

私見ですが、Hackがスケールできない理由として、以下のもののいずれかが満たせないためではないかと考えています。

  1. そのHackによってどれくらいのユーザが利益を被ることができるか。自分ひとり、あるいは一部のユーザのみではないのか。（大局性）
  2. そのHackを適用した時、既存の問題をどの程度まで解決できるのか。解決できないケースがある、あるいは新たな問題を生み出すことはないか（完全性）
  3. そのHackは他の問題にも適用可能か。特定の問題のみに閉じたものか（汎用性）

今回のLinkedIn Introの件も、既存の問題（iOSメールアプリの非拡張性）に対するHackとして生まれ、大々的にデビューしましたが、いきなりインターネットグローバルに対象ユーザを拡げたというところでその壁にぶち当たってしまったのかと思います。現在はそのHackを適用した場合に生じる新たな問題点（プロキシサーバを介すことのセキュリティ・プライバシーに対する懸念）について提起されている状況です。

たとえば、LinkedIn IntroのIMAPプロキシのサーバコードをOSSとしてリリースし、同プロキシサーバを企業用途に販売したりホスティングサービスと提携する、といったことは可能だったとは思います。企業に対して自社運用するなり信頼するホスティングサービスでの運用を許すことにより、IMAPプロキシの運用に対しての信頼の問題はこれでだいたい回避されます。これはHackを無理矢理にスケールさせずに、HackはHackとして局所にとどめたことにより、一つの安定を得た形といえるでしょう。

Hackを卒業する

先に上げたHackがスケールするための要件ですが、逆にいえば、これらが満たされた段階でもうHackはHackであることを卒業することになります。

Hackであったはずのものが、いつの間にかメインストリームになってしまったものの例としては、ウェブ技術の世界での有名なHackの例では「JSONP」と呼ばれるものが思い浮かびます。これはそもそもブラウザのSame Origin Policyを越えた通信を実現するための苦肉の策でしたが、WebサービスAPI提供ベンダーや著名なJavaScriptライブラリにより事実上のプロトコル化されることで汎用性を得ることができました。また、そこで提起されたセキュリティなどの問題点は、後のXHR level 2やCORSなどのWeb標準仕様の策定への原動力となったとも言えます。

では、Hackをいつまでたっても卒業できないようなHackは学ぶ価値がないのかというと、一概にそうともいえないとは思います。特に、プロプライエタリな環境においては、Hackを一子相伝的に社内エンジニアに運用手順付きで残しているような組織も多くあり、やはり局所的にはHackは有効であるケースが多いとは感じています。HackはHackとしてその価値を尊重し、いつの日か卒業できる日を夢見て、あるいは先祖代々伝わるUglyなHackの息の根を止めてあげたり、最後を看取ってあげるのもエンジニアのお仕事かもしれません。