ソフトウェア

以前から銀行の入出管理はJunsoft Moneyに入れるために、Microsoft Money形式でダウンロードして利用していた。日付を指定せずに前回エクスポートの続きからできるので便利。みずほだと一部要素をテキストエディタで置き換えてあげないとうまくいかなかったが、MUFGはそのまま使えたので、重宝していた…の、だが。

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

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

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

Android APIを追い掛けていて困るのは、どのAPIでどのPermissionが必要かわかりにくいことだ。マニュアルに明記してあることもあるが、大体は「エラーが出たらManifestに」といった場当たり的な対処が推奨されてしまっている。

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には未収録)。 [↩]

Orphenpediaというのを発見したが、情報量が凄い。どうやら、私が読んだのは背約者のあたりまでなので、その後倍くらい続いているようだ。何で止めたかというと…出版間隔か、展開に飽いたのかどっちだっけ。

システムはWikipediaと同じMediawikiベース。2008年9月開始でおよそ3年半近く運営。項目数が1200強ページある割に、「議論」(ノート)の活用があまり無いことから、少人数で各個に編集していると推察される。凄いなあ。

と、思いつつ夏用にログホラのデータを収集する昨今であった。

そういえば、今でこそWikipediaのおかげでWikiとの略称があったが、当初は”Wiki-Wiki”から取ったオリジナルにそって、一部ではWikiWikiWebとよんでいた気がする。現在はOEDにも”Wiki”の名前で登録されたようだし、すっかりオリジナルからも離れたし、Wikiで良いのだろう。

iPhone/iPad用で小会議のレコーダを探しているのだけれど、どれが適当なのかがよくわからない。

本当はマイクつけてやるものだろうし、非常用は携帯電話にしてしまったほうが幸せなのかな。

早速手元のシステムをバージョンアップ。

# freebsd-update upgrade -r 8.3-RELEASE
# freebsd-update install
# shutdown -r now
# freebsd-update install
# freebsd-update install
# shutdown -r now

# mergemaster

jail側もいつものように対応。

# ezjail-admin update -b
# ezjail-admin restart
# ezjail-admin update -P
# PORTSDIR=/jail/basejail/usr/ports/ portsdb -u

各jailの中も適当に、チェックして、アップデートして、後始末。これが面倒だけれども、仕方がない…とやっている間に時間がなくなりそうなので、ここは後日に後まわし。

# portmaster -L
# portmaster --no-confirm -ady -x xz
# find /var/ports -type d -name work -depth 3 -exec rm -r '{}' ';'

アレといっても代名詞ではなく、ARE (Virtual Machine for Android Reverse Engineering) というきちんとしたツール名。

有名所のツールが色々と詰め合わせになっていて、Android のapkファイルの基本的な解析がだいたいできるようになっている。Qtライブラリを利用して色々と環境を作るのが面倒な APKInspector まで入っているのは嬉しい。

というか、APKInspectorを使おうとVMをいじっていた最中に見つけたのでちょっとだけ涙目。まあ、そういうものですよね。

詰め合わせの中身はこんな感じ。

• Androguard
• Android sdk/ndk
• APKInspector
• Apktool
• Axmlprinter
• Ded
• Dex2jar
• DroidBox
• Jad
• Smali/Baksmali

他にも、reverse-androidとか、Mercuryとか、使うと面白そうなものは多いので、まだまだ探しがいがありそうだ。

ソースコードを読むのはそんなに苦にしていないのだけれど、最近のウェブ系はイベントで発火してオブジェクトにより多態化した処理というのが多く、動作から追うことはできても、このメソッドどこからの経路で使われているの? というのが非常に追いにくい。

静的中心に見ている段階なので、実際に動かして動的に解析してやればいいのだろう。言語ごとにcaller/calleeを追うツールが違うので、いまいち使いにくそうなのが懸念点。グラフ書いてソースコードとの対応が取れる程度で良いのだけれど、個人利用の範疇ではあまり無さそう。

まあ、ネタが色々とアレなので通信主体であまり実地に動かしたくないわけで。パーサだけ他のから借りてきて、レイヤつけて自分で解析ツールでもつくるしかないのかねえ…って特殊すぎるしコード量がちょっと多すぎそうだ。

と、そんな趣味(?)に最近手をそめています。

何をするのかは、MagicPlanのサイトの動画を見てもらえば一目瞭然。

部屋の中央からiPad(or iPhone)をかざして、ジャイロでARしつつ、カメラに写る部屋の特徴点を指定。そうすると寸法の入った見取り図ができあがる仕組み。

試してみたが、物が多い部屋でも推測で試せば大体なんとかなる。家具を探しているときとか、引越し先を探す時の内見によさそうだ。

	MagicPlan (Version 2.0)
	カテゴリ:	ユーティリティ
	価格:	無料
	デベロッパ名:	Sensopia
	リリース日:	2011/04/09
	対応デバイス:	iPhone 4 / iPad 2 Wi-Fi+3G / iPad 2 Wi-Fi / iPod touch (4th Gen)

最近、興味が出てAndroidのpermissionまわりに手を出しているのだけれど、どの関数がどの権限を要求しているのかがさっぱりわからない。

公式サイトからは辿れなかったのだけれども、どこかにまとまった表は無いものだろうか。

Readabilityは確かに良いのだけれど、何故か会社の環境だとChromeのプラグインで2ステップになってしまって、非常に使い勝手が悪い。ifttt.comを経由してのDeliciousへの登録も、一々Favoriteをつけないと取り込んでくれない。

しかし、Reederとの連携が良いのでInstapaperには戻りたくない。

そこで、Instapaperで記録→DeliciousとReadabilityに反映、と流れを整理した。

Instapaper→Deliciousはタイトルをとりこぼすことが多いのが難点だが、まあReadability連携のほうで普段すればなんとかなる。

なお、事ここに至り、タグは完全に捨ててます。

ブラウザなり、Googleリーダーで読んだ場合は、基本的にbookmarkletかプラグイン経由でReadabilityに保存。Reederなりで読んだ場合も、連携機能経由で保存。

ifttt.comは次のように設定してある。

1. Instapaper(RSS)が更新されたら、DeliciousReadabilityに登録。これはTweetAtokなどInstapaperしか対応していないクライアントがあるため。
2. Readabilityでfavoriteがついたら、Deliciousに登録。本当は全部放りこみたいのだけれど、現状fav以外に選択肢無し。
3. Deliciousに登録されたら、Evernoteの専用ノートブックに放りこむ。

TwitterのFavもDeliciousに流れるようにしてあるので、これでどこに集めようが基本的にDelicious経由でEvernoteにURLが集まる仕組み。Readabilityがimportもサポートしていてくれるなら、Deliciousの流れを逆にしてReadabilityに集めるところなんだけど。難しい。

なお、Readabilityのfavは、家のMac版のReederで毎日夜にちまちまと処理している。

今迄気になる記事をクリップするのに使っていたInstapaperのbookmarkletが、いきなり改悪。今迄は左端でこっそり保存していたものが、何故か全画面ブラックアウトでの保存になる。公式を見ると、全部書き直して高速化とマルチ環境対応とのことだけど、保存している間読めなくなるのは面倒。

ということで、いつのまにか無料になっていたReadabilityに手を出してみる。調べてみると、iOS版クライアントは普通に手にはいるし、iOS/Mac版両方のReederは連携して未読の表示が可能。となかなかの対応ぶり。

ちょっと乗り換えて試してみようかな。

一点だけ不便が。ifttt で Instapaper のRSSからDeliciousに登録して集約していたのだけど、ReadabilityはFavoriteをつけたものしか対象にできない様子。何かないのかな。

Readability™
カテゴリ: ニュース
価格: 無料

Reeder
カテゴリ: ニュース
価格: ￥250

米長永世棋聖「築いた万里の長城、穴が開いた」　電王戦敗北後の会見　全文 – 芸能 – 最新ニュース一覧 – 楽天woman

電王戦リアルタイム実況 by やねうらお – やねうらお－よっちゃんイカを食べながら、息子語録を書き綴る

電王戦観戦記 ほかではあまり語られない舞台裏

ひとまずはボンクラーズの勝利となった様子。評価状態などを交えた詳しい解析はそのうちどこかに載ることでしょう。

興業としては、元々あからで挑んでいた所に別ラインからのコンピュータの挑戦ということで、若干状況が混乱して見える。前回の話からすると現役棋士とするにはスポンサー料が足りない、というのもあるのかな。次回もあるとの事なので、これはこれで楽しみ。

iPod touchで利用しているスケジューラ、iKoyomi2がアイコンを変更して鼠色の汚い何かになってしまった。2ヶ月表示の閲覧性が良いため、私はメインのスケジューラとして4つしかない特等席に割当てて活用していたのだが、流石に見栄えの限度というものがある。

そこで、代替品をさがしてみたのだけれども、これがなかなか無い。二ヶ月表示の、ダブルタップで予定時刻がズームで見えるというのはユニーク機能らしい。

仕方がないので、しばらく使い続けてアイコン変更を待つしかないか。App Storeのレビューもアイコンへの提言で埋もれているし、そのうちかわるだろう。

WordPress をたった3分で3倍高速化する方法 [MO Cache]を見て、手元を見直す。

キャッシュシステムをwp-cacheからWP File Cache + WMO Cacheに変更。

最初はPersistent cacheとしてW3 Total Cacheを試してみたのだけれども、ファイルキャッシュだけを扱うにしてはやけに大仰だったのであきらめました。ちなみに、Activateのまま削除するとwp-content/以下のファイルを延々消さないと管理画面に辿りつけなくなります。