snippets from shinichitomita’s journal RSSフィード Twitter

2013-12-23

2013-11-01

Amazon DynamoDBがFine-Grained Access Controlに対応し、もはやMBaaSの体制は十分整った

表題の通り、AmazonがDynamoDBをFGAC(Fine-Grained Access Control=行・列レベルのアクセス制御)に対応しました。

これにより、既報のソーシャルログイン対応とあわせて、モバイルユーザが直接DynamoDBを利用することが可能になり、MBaaSの重要なピースである構造化データストアが提供されることになりました。非構造化データ(=ファイル)を格納するAmazon S3、プッシュ通知を実現するAmazon SNSと合わせて、もはやAWSはMBaaSであると言ってもまったく遜色はありません。

なお、以前自分は「 AWSがソーシャルログイン可能に。つまりAWSが事実上のMBaaSになった - snippets from shinichitomita’s journal」という若干の飛ばし気味の記事を書いたのですが、ちゃんとAmazonさんがフォローしてくれましたのでホラ吹きにならずにすみました。

あとはDynamoDBをちゃんと使えるようになるとかなりパワフルになりそうですが、現在STS自体はDynamoDBへのアクセスもサポートしているものの、今のところレコードレベルでアクセス制御ができるわけではなさそうです。

AWSがソーシャルログイン可能に。つまりAWSが事実上のMBaaSになった - snippets from shinichitomita’s journal

ブラウザ内JavaScript SDK

今回はそれとあわせて、ブラウザ上のJavaScript(HTML5アプリ)から利用できるSDKについてもアナウンスされています。

実際は、既にブラウザからS3へのアクセス自体は可能になっていたので、トークン受け渡しやAPI呼び出しの部分をちゃんとライブラリとしてまとめた+S3以外のサービス(とくにDynamoDBとSNS)にも対応した、ってところが新しいという感じでしょうかね。

(余談:それにしてもわざわざ"JavaScript in Browser"と書くところ、やっぱNode.js人気なんだなあ)


MBaaSベンダーへの影響

もちろん、これで即座に「他のMBaaSサービス死亡のお知らせ」というわけではないとは思います。実際Amazonで他のMBaaSが提供しているデータストア相当のアクセス制御のポリシーを設定するのはかなり面倒です。それに、DynamoDBというNoSQLデータベースの特性を考えると、やはりアクセスパターンに応じた効率的なデータ設計から考えないといけないことが多く、それなりにサーバサイドに慣れた人が使うもの、という印象です。もし「サーバサイドの技術者はまったくいらない」を達成するところが究極のMBaaSなのだとすると、そこにはまだまだ至っていません。まあそれでも、これでEC2インスタンスの運用およびアプリケーション配布などを考えなくてよくなる、というのはすばらしいことなのですが。

とりあえず運用コスト面に絞って考えると、DynamoDBのトランザクション数が上がってきた時にかかる課金額と、現在のMBaaSが設定しているAPI課金額を比べてどれくらい釣り合いそうか、ってところが焦点だと思います。最近だとStackMobなどはAPIコール数による課金形態をとりやめていたりするので、まだまだ生き残りをかけて熾烈な争いが繰り広げられそうではあります。

2013-10-29

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

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

おさらい

先日、LinkedInが LinkedIn Intro というサービスを発表しました。

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

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

で、結局いろいろ釈明することになりました。

The Facts about LinkedIn Intro | Official LinkedIn Blog

このへんの経緯は、日本語ではこちらの記事がくわしいですね。

LinkedIn: Introは炎上しているがもっと詳しく知りたい - ワザノバ | wazanova

何をしているか

増井さんが日本語で仕組みを解説されています。

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の息の根を止めてあげたり、最後を看取ってあげるのもエンジニアのお仕事かもしれません。

LinkedIn Intro に学ぶ、Hackの有効性とその限界について(重複につき削除)

http://d.hatena.ne.jp/shinichitomita/20131029/1383044607

2013-05-29

[][][][] AWSがソーシャルログイン可能に。つまりAWSが事実上のMBaaSになった

Amazon Web Services ブログ: 【AWS発表】 AWS IAM が Amazon、Facebook、GoogleのID連携をサポート

ほんとは言いたいことは表題だけで終了なんですが、とりあえず3行程度でまとめ。

  • AWSサービス群のAPIへアクセスするためのトークンを発行するサービス(STS)が、外部のアイデンティティプロバイダとの連携を開始した(Facebook、Googleなど)
  • つまり、エンドユーザの認証のための中間サーバ(EC2も含め)を用意しなくても、AWSサービスを直接利用するモバイルアプリが作れるようになった(例:FacebookIDでログインし、S3上に割り当てられたユーザ専用のエリアに写真やファイルをアップして共有するアプリなど)。
  • これって、いわゆるMobile Backend as a Service (MBaaS) じゃないの?

S3の読み書きが直でできるというだけでMBaaSというにはちょっとまだまだかも知れないですが、とりあえずエンドユーザレベルでアクセス制御が可能なクラウドストレージが提供されるようになったということは、重要な一歩だと思います。あとはDynamoDBをちゃんと使えるようになるとかなりパワフルになりそうですが、現在STS自体はDynamoDBへのアクセスもサポートしているものの、今のところレコードレベルでアクセス制御ができるわけではなさそうです。

なお、今回は発表されたスペックだけ見て記事書いてます。コード書いて動かしてるわけじゃないです。なので実際やってみたらそんないい話じゃなかったよ、ということもあるかもしれません。暇になったらサンプルでも動かしてみようかなくらいですが、いずれ誰かがやってくれるならばまあそれでいいです。

しかしクライアント側のアプリで得たtokenをサーバサイドに渡して認証、ってのを推し進めてるのは、若干気になる所ではあります。OpenID Connectの場合はID Tokenの中にaud(audience:発行先)の情報が指定されているので幾分マシですが、そもそもクラウド上のサービス(AWS)とユーザの持つデバイス内のアプリが同一のaudienceとして処理されるのに違和感を感じることもありそうです。

一応AWS iOS SDKに含まれていたSecurity Token Serviceのヘッダファイルには、webIdentiyTokenとしてOpenID ConnectのID Tokenも指定できるようなコメントが書いてありました。前述のように、実際SDKを触ってみたわけじゃないのでこれが動くかどうかはわかりませんけど。

https://github.com/aws/aws-sdk-ios/blob/master/src/include/STS/SecurityTokenServiceAssumeRoleWithWebIdentityRequest.h?source=cc#L72-L96

2013-01-06

[][] SOQL Console

SOQLのオートコンプリーションができるSOQLコンソールアプリを作りました。

Ctrl+Space or Tabキーでコンプリーションを実行できます。

アプリケーション

https://soql-console.herokuapp.com/

機能

FROM句でオブジェクト名の補完

f:id:shinichitomita:20130106114743p:image

SELECT句での項目名の補完

f:id:shinichitomita:20130106114745p:image

親リレーション内の項目名の補完の例

f:id:shinichitomita:20130106114746p:image

子リレーション名の補完

f:id:shinichitomita:20130106114747p:image

子リレーションの内部クエリでの項目名の補完

f:id:shinichitomita:20130106114748p:image

WHERE句/GROUP BY句/ORDER BY句での項目名の補完

f:id:shinichitomita:20130106114749p:image

関数名、キーワードの補完

f:id:shinichitomita:20130106114750p:image

その他

自分の組織にあるカスタムオブジェクトを参照して補完もできます(要ログイン)

ソース

https://github.com/stomita/soql-console


Enjoy!