名前を伏せたいそうなのでお相手はここでは書きませんが、今後ともよろしくお願いします。

何故かMoney形式でのエクスポートが廃止されていたらしい。代わりにCSVになっていたのだが、Moneyと相性が悪く色々と悪化してしまった。

まず、エクスポートの日付が前回からとできなくなったので、前回の取り込み日を調べて直接指定するしかなくなった。そして致命的なことに金額が3ケタ狂う。どうやらMoneyで区切りの,を.に誤認識(そういう国もあるから仕方ない)するので、正しい金額が入らない。仕方がないので手動で置き換え。CSVだとどの項目が何かわからないので、全部インポートの度に手動で設定する必要がある。

不便になったなあ。これは何か別の方策を考えないと続かないか…。

• [COMIC] 乙嫁語り 4巻 (森薫)
• [COMIC] あまあま (志摩時緒)

あまあまは、なんとなく紹介を見て気になったので購入。確かに破壊力抜群でした…壁はどこだー

STOWAWAYには、Android 2.2のPermissoon Mapがある^[1]。これは、どのAPIを呼び出せばどのパーミッションが必要かわかるマップだが、いかんせん情報量が多くてわかりにくい。また、基本は同じとはいえAPI levelにより多少変化もしている。

そこで、整理のために論文”Android Permissions Demystified”(PDF)を元にして、おおまかな区別を抜き出してメモとする。

まず最初に触れておきたいのは、結局統一したPermissionのポリシーなど無い、ということだ。以下に説明するようにあちこちで権限が持ちだされ、チェックされ、あるいは無視されている。中には無駄にチェックするAPIもあるらしい。よって、現状のAPI Levelでは食い違っている箇所がでることを前提とする。

最初に、Permissionは3種類の脅威レベルに分けられる。

1. Normal Permission: 壁紙の変更など、APIへのアクセスを制限するもの。
2. Dangerous Permission: SMS送信など、API呼び出しにより潜在的に危険をもたらすもの。
3. Signature/System Permission: 署名されたアプリケーションでだけ使えるもの。バックアップやアプリケーションのインストールなど、特に危険なもの。
4. (他、各アプリケーションが独自に定めるPermission)

Android API frameworkの構造は「APIライブラリ」「システムプロセス中のAPI実装」の二つのパートに分割できる。「APIライブラリ」は各アプリケーションの仮想マシンで動作するもの。当然、アプリケーションと同様の制限を受ける。それに対し「システムプロセス中のAPI実装」に制限はない。ライブラリが構文糖としてユーザからのリクエストを代理で受け、裏でシステム側で実行する、といった感じになる。

APIの呼び出しは三ステップで行われる。まず、アプリケーションはライブラリのAPIをinvokeする。次に、ライブラリはライブラリ中のprivate interfaceをinvokeする。このprivate interfaceはRPC stubになっていて、最後にRPCリクエストがシステムプロセスとして、システムサービスに誰が処理してくれるか尋ねる。この仕組みはJavaのreflectionが使われている。

例えば、ClipboardManager.getText()は、IClipboard$Stub$Proxyに引き渡され、システムのClipboardServiceが呼ばれる。

さて、肝心のPermissionのチェックだが、統一ポリシーなどは存在せず、実に色々な箇所で行われる。システムプロセス中のAPI実装でチェックするものもあれば、ライブラリ中で随時チェックするものもある。極一部の権限(INTERNET, WRITE_EXTERNAL_STORAGE, BLUETOOTHなど)は、Unix groupで制御されている。この場合、API側は何もチェックせず、ただinvokeするだけである。

Android NDKで開発できるNative Codeでは、直接にはシステムのPermissionを制御できない。、ソケットやファイルにアクセスする場合、Java wrapperを用意して行うことになる。

Content Providerは、単独のアプリケーションとしてインストールされて他のシステムプロセスやAPIライブラリからは切り離され、抱える情報の保護のために静的/動的なPermissionチェックを行う。アクセス先は、read/writeといった定義と、”content://a/b”のようなpathにより指定される^[2]。

Intentは、全てシステムサービスのActibityManagerServiceを通じて送信される。二つのテクニックによりIntentの送信は制限されている。一つは、Permissionを持っているアプリケーションにだけ送信する仕組みである。もう一つは、システムのIntentはUIDがマッチするプロセスにしか送信しない仕組みである。受信の場合もだいたいはPermissionが必要であり、OSが送信するIntentの受取先を制限している。

(論文では、この後もテストコードを暮ろうとしたらAndroid側が色々アレで大変でしたという話や、APIの分析結果が続きますが、省略。)

1. 一応、本命はapkをアップロードして余分な権限を宣言していないか解析を行えるStowawayの方、のはず。
2. 余談だが、BlackHatなどで発表されたMercuryという「うっかりContent ProviderやServiceに権限をつけ忘れて、publicになっていないか」というチェックを行うためのツールが存在し、最新のAndroguardと組み合わせて使うこともできるらしい(AREには未収録)。

• [BOOK] Application Security for the Android Platform: Processes, Permissions, and Other Safeguards

最近手を出すことが多くなったので、きちんと一冊読んでおこうと確保。薄い本なので英語でも大丈夫。

だらだら公式サイトを見てもいいけど、ウェブだとなんとなく把握しにくいんですよね。適度にまとまった本は本当に助かります。

だらだらと色々見たり読んだりしながらひたすら堕落。

• [NOVEL] 天冥の標6 宿怨 PART1
• [NOVEL] ガンパレード・マーチ 2K 新大陸編 2
• [NOVEL] 連環宇宙
• [NOVEL] 史上最大の発明アルゴリズム: 現代社会を造りあげた根本原理

天冥の標を確保するために、新宿の紀伊国屋へ。

ついでに、とんこつラーメンで夕食として、仕上げに随分久しぶりにBERGに寄ってみた。イングリッシュビターというのがあったので、選択。これが実に私好みのビール。ちびちび飲むのに最高。ただ、つまみ無しで1パイントあるといささかもてあますのも確か。次回は何かつまみながら、本読みつつでもするとしよう。

問題はわかっていても止めなかったので良心から、ではないはず。十分に稼げたから、なのか仕方なく、なのか次の策があるから、なのか。そのあたりは各社違うのだろう。

個人的には面白いゲームには喜んで金を費すが、ソーシャルゲームのやり片には不満。

理由は搾取とかそういうのも多少はあるけれども、一部課金アイテムが明らかにゲーム性ではなくソーシャル性に金を支払っているから。個人的には時間短縮ならば払うこともあるけど、実質的に前線攻略の必須アイテムとなるなら回避、というあたりが基準。そういう意味ではコンプガチャは各人のコレクター性に注目していたから、もしプレイしていたら払う組に入ってしまっていたかもしれない。

…確率は計算できるからしませんけどね。私は愚かしいのでFXなんてできません!というのと同じ程度の線引きでしていません。

特製つけ麺を頼んだが、並で丁度良い感じ。平麺と太麺があったが、後輩いわく平麺の方が良いそうだ。大盛りの量を見たが、以前はともかく今は昼に食べたい量ではない。肉が割とがっつり入っているので、食べごたえもある。

スープがなかなか私好み。最後に割って飲みほしたくなったが、塩分が気になる濃さだったのでぐっと我慢。

自分で地道に地引するしかないかなと思っていたので、省略できるのはまさに願ったり叶ったり。

公開情報だし、気がむいたら適当にサマライズしてのせてもいいかな。