Selfkleptomaniac

Titanium MobileではAnalyticsを切っておきましょう

2年前の記事ですが、AppStoreのトップ無料や人気上位のアプリの68%がUDID（Universal Device Identifier）を送信しているという報告がありました（関連の日本語記事）。

利用状況などを収集してアプリの改善に利用するのはよくあることだとは思います。行動分析のためにデータを収集する場合、端末の識別のために何らかのIDが必要となるわけですが、スマートフォンでは最も簡単に利用できるのがこのUDIDです。このようなIDは以前から日本の携帯電話のサービスプロバイダでは広く利用されており、中にはウェブサービスの認証にまで使われているケースもありましたので、ある意味われわれにとっては非常に身近なものでもあります。

しかし、端末固有の一意なIDとして何かと便利に思われるUDIDですが、これを第三者に送信するのはあまり感心できません。上の報告ではHTTP通信のGETリクエストで送信しているアプリもあったようですが、これは論外です。しかし、もちろんそれだけが理由ではありません。

UDIDの送信がなぜ問題なのかについては諸説あるでしょうが、主な理由として考えられるのがエンドユーザの行動をトラッキングできてしまうことがプライバシーの侵害になるかもしれないという懸念です。同じようなことがいわれてきたブラウザのクッキーであれば、第三者のクッキー（Third-party Cookie）はブラウザの設定などでオプトアウトできるわけですが、UDIDは変更することができないため一度送信されてしまえば相手側の対応がなければ削除されません。アプリによってはその性格上、いつ起動していつ利用されたのか他人に知られたくないケースもあるでしょう。しかしUDIDが取得されてしまえば、第三者にその情報が漏れてしまいます。この手の試みはこれまでもウェブ広告の世界などでプライバシーとビジネスの間のせめぎ合いが何度も繰り返されてきた歴史があるわけですが、たいていはプライバシーの擁護が重視される結論に至っています。

ところでTitanium Mobileですが、Appcelerator社のサービスに登録している方なら一度くらいはAnalyticsの画面を見たことがあるかと思います。アプリのインストールされた数の推移や様々な行動分析が見られるので、開発者だけでなく企画等の担当者も大変重宝します。これらの情報はTitanium MobileのAnalyticsという機能を利用して送信されています。送信はSSLで暗号化されたPOSTリクエストになっているので、途中で覗き見られることについては、iPhoneの3G回線の通信がEnd-to-endのSSLではないなんてことはないでしょうから（ガラケーだとゲートウェイとウェブサーバ間のSSLになっていたりするようですが）、さほど憂慮する必要はなさそうです。さらに、当然ながらAppcelerator社は集積したデータをさらに第三者に転売したり、広告などに悪用したりするようなことはしないと明言しています。その点で現時点で懸念する必要はないと思います。しかし、いくつか問題はあります。（１）データを集積しているAppcelerator社はアプリの配信元、エンドユーザにとっては無関係の第三者であること（２）送信される情報についてアプリの利用者から明確な許諾を得ていないこと（３）UDIDが送信されていること、などがそうです。

これらの対応策は非常に簡単で、tieapp.xmlをテキストエディタなどで開いて

<analytics>false</analytics>

とするだけでこの機能をオフにすることができます。個人的な意見ですが、上記の理由から、現時点ではリリースされるアプリについては必ずこれをやっておく方がよいでしょう。もちろん、UDIDの送信が即、何か悪いことをしている証拠にはならないと思います。しかし、このような取り扱いに注意が必要なデータについては、トラブルを避けるためにも万全な状況でなければ利用しない方がいいはずです。また、iOS5からUDIDの取得が非推奨となったことに伴い、やはりUDIDの送信は避けるべきでしょう。

実際のところどうなっているのか確認してみましたが、残念なことに1.8系の実装（iphone/Classes/PlatformModule.mやiphone/Classes/TiUtils.mを参照のこと）を見る限り、Titanium.Platform.idを送信していますね。1.8.0.1の場合はiphone/Classes/AnalyticsModule.mmを見るとわかります。実際にデータをダンプするには（SSLの通信をキャプチャするような面倒なことが好きな人を除いて）このファイルを下のように変更します。

$ git diff iphone/Classes/AnalyticsModule.mm
diff --git a/iphone/Classes/AnalyticsModule.mm b/iphone/Classes/AnalyticsModule.mm
index f76a472..46c6e81 100644
--- a/iphone/Classes/AnalyticsModule.mm
+++ b/iphone/Classes/AnalyticsModule.mm
@@ -217,6 +217,9 @@ NSString * const TI_DB_VERSION = @"1";
        [request setUseCookiePersistence:YES];
        [request setShouldRedirect:YES];
        NSString * stringifiedData = [SBJSON stringify:data];
+  //debug
+  NSLog(@"[DEBUG] Analytics sending data: %@", stringifiedData);
+  //debug
        [request appendPostData:[stringifiedData dataUsingEncoding:NSUTF8StringEncoding]];
        [request setDelegate:self];

ご覧頂ければわかる通り、UDIDが送信されていますので、やはり上に書いた方法でAnalyticsは停止した方がいいですね。それと、Appcelerator社が悪意をもってこの機能を実装しているのではないこともおわかり頂けるかと思います。だって、そうじゃなきゃソース公開してないですよね？個人的にはこういうところがTitanium Mobileを使い続けることの大きな理由になっています。

＊決してここの部分をいたずらして集積サーバに変なデータを送り込んでしまおうとか考えてるわけじゃないですからね！

また、この点について各方面に問い合わせたところ、Analytics自体は非常に有望なサービスなので、今後はUDIDを利用しないよう変更する予定になっているとのことでした。そのときが来たら再度検討してみたいと思います。

この数日、エントリを書いておきながら公開するべきか非常に悩んでいました。上で説明はしたつもりですが、これは別に情報が勝手に第三者に集積されてしまったというような事件ではなく、単純に機能としてソースまで公開され、ドキュメントにも書かれていることなわけで、簡単に調査も可能なことですから、開発者としては知っていてある意味当然なことです。ただ、どこかで誰かがこの機能について悪意的にかき立てるようなことがあれば、まだまだ少数のコミュニティで活発にやり取りしている状態のTitanium Mobileが今後プラットフォームとして成長する妨げになってしまうような打撃を受けると嫌だな、と思ったので、情報の周知徹底を目的に公開することにしました。

もう一度まとめます。

（１）Analyticsはオフにできるよ
（２）オフにしとけばなんにも怖くないよ
（３）UDIDは今後は使われなくなるよ

以上です。

Popularity: 3% [?]

Titanium Mobileでアプリ内課金（iOS編）

アプリ内課金の実装方法について知りたいという声があったので、参考になればと書いておきます。アプリ開発者の方は権利の15%で取引に応じますの苦労がこれで少しでも減るなら喜ばしいことです。とはいえ、世知辛い世の中ですから、このコードで生じた金銭的問題の責任は放棄しますので、ご利用の際はあくまでも参考程度にとどめ、十分検証した上で実装されるようお願いします。

一応、動作はTiStorekit1.4、Titanium Mobile SDK 1.8.1、非消費型コンテンツで確認しています。

iOSの場合、課金の手続きは

• In App Purchaseが有効になっているかを確認する
• 正しいProduct IDかを確認する
• 購入開始
• 成功ならレシートを受信してチェック、キャンセルやエラーならエラー処理

となります。ここではAppcelerator社から公開されているTiStorekitを使った実装の例で説明します。以前に実装したものを参考にざっと書いた関係で、細かい条件は検証していませんのであしからず。CoffeeScriptだけどいいよね？

事前にiTunes ConnectでIn App Purchaseの設定が完了していることが前提になります。iTunes Connectの使い方は割愛しますが、支払い関連の設定が完了していないとIn App Purchaseは有効になりません。またProvisioning Portalで設定を確認して、正しいProvisioning Profileでビルドしましょう。iOS5からシミュレータからも利用できるようになったようですが、必ず実機で動作確認してください。

そうそう、下のコードではコンストラクタで@SANDBOXをtrueにしていますが、リリース時には変更しましょう！

class InAppPurchase
  constructor:()->
    @ERROR_PRODUCT_ID = {type:'product_id', message:L('inapp_error_product_id')}
    @ERROR_CANMAKEPAYMENT = {type:'canmakepayment', message:L('inapp_error_settings')}
    @ERROR_UNKNOWN = {type:'unknown', message:L('inapp_error_unknown')}
    @SANDBOX = true

  start:(data, success, error)->
    ###
    args  dataは課金対象の商品オブジェクト（{product_id:プロダクトID}）
          sccess、errorはそれぞれcallback関数
    ###

    storekit = require 'ti.storekit'
    if data.product_id == '' || data.product_id == null || data.product_id == undefined
      # なんて防衛的なコード！ #
      error(@ERROR_PRODUCT_ID)
    else if !storekit.canMakePayments
      # AppStoreが有効になっていない #
      error(@ERROR_CANMAKEPAYMENT)
    else
      # 正しいProduct IDかどうかチェック #
      storekit.requestProducts([data.product_id], (e)=>
        if e.success
          product = e.products[0]
          if product != null
            _success = success
            _error = error
            storekit.purchase(product, (elem)->
              if elem.state == storekit.FAILED
                error(@ERROR_PRODUCT_ID)
              else if elem.state == storekit.PURCHASED
                callback = (response)=>
                  if response.success && response.valid
                    _success()
                  else
                    _error(@ERROR_UNKNOWN)

                # subscriptionの場合は下のオブジェクトにsharedSecretプロパティを追加 #
                args = {
                  receipt:elem.receipt
                  sandbox:@SANDBOX
                  callback:callback
                }
                storekit.verifyReceipt(args)
              else if elem.state == storekit.RESTORED
                storekit.restoreCompletedTransactions()
                success()
              else
                Ti.API.info "purchasing..."
            )
          else
            error(@ERROR_UNKNOWN)
        else
          error(@ERROR_PRODUCT_ID)
      )
TiStorekit = new InAppPurchase()
TiStorekit.start(product, success, error)

canMakePaymentsは定数でiOSの設定画面でAppStoreが有効になっていないのでそもそもアプリ内で課金ができない場合はfalseになります。requestProductsでProduct IDが正しいかどうかを確認し、purchaseで購入処理を開始します。successが返ればveryfyReceiptで確認して完了処理を実行します。

レシートの確認まで実装しましたが、ここは迷うところですね。通信に時間がかかったり、またはこのタイミングで処理が中断してしまった場合、利用者にとってはお金を払ったのに購入が正常に完了しないように見えてしまいます。時間がかかるようならキューに入れてレシートは後で確認し、いったん完了処理をしてから、不正があったらそれなりの処理をする、といったような手段で対応するしかないでしょう。かといってレシートを確認しないと、不正な利用を完全に防ぐことができなくなります。

Popularity: 4% [?]

Titaniumでリジェクト・iCloud関連

Titanium Mobileで作ったアプリがリジェクトされたので記念に。

今回リジェクトされた理由は、iCloud対応でデータの格納場所が厳密に定められ、チェック内容が変更になったからです。これからのアプリは生成されたデータを格納する際には以下のルールに従う必要があります。

(1) アプリが再生成できないファイルは/Documentsに保存

例えば、メモ帳アプリでユーザが書いたメモなんかはこちらに保存しないといけません。iCloudで自動的にバックアップされます。

(2) 再生成可能なファイルは/Library/Cachesに

データベースのキャッシュも含む、とありますが、ダウンロードされたファイルなどもここに置くのが正しいようです。

(3) 一時的なファイルはちゃんと/tmpに

アプリ終了時に消すのをお忘れなく。

(4) バックアップされては困るデータは”do not back up”

オフラインでの利用などで使いたい、iCloudやiTunesにバックアップされては困るファイルにはこの属性を追加しましょう。

さて、Titanium Mobileですが、例えばsqliteを使った場合、データファイルは/Library/Application Support/database以下に保存されてしまいます。残念ながら、Appleの新しい規制ではこれはリジェクトの理由になります。

Ti.Database.install('Resouces以下に置いたdbファイル', 'my_app');

このようにinstallを使って設置したデータファイルは/Library/Application Support/database/my_app.sqlとして保存されます。

これをAppleの規制に適応されるためには、例えば

Ti.Database.install('Resouces以下に置いたdbファイル', '../../Caches/my_app');

とすることで、/Library/Caches/my_app.sqlとして保存することができるようになります。

また、ファイルを保存する際にTi.Filesystem.applicationDataDirectoryを使っていた場合は

var root_dir = Ti.Filesystem.applicationDataDirectory + '../Library/Caches/';

このように変更すると/Library/Cachesを指定することができます。

既存のアプリをアップデートする場合は、Ti.Database.installを上のようにしてあげて、アプリの起動時に古いデータファイルを新しい場所に移動してあげるとかしないといけませんね。途中、スペースを含むパスがありますのでこんな風に指定します。

var db_file = 'my_app.sql';
var old_file = Ti.Filesystem.applicationDataDirectory + '../Library/Application%20Support/database/' + db_file;
var new_file = Ti.Filesystem.applicationDataDirectory + '../Library/Caches/' + db_file;
var old = Ti.Filesystem.getFile(old_file);
if(old.exists()){
  old.move(new_file);
}

Popularity: 6% [?]

Titanium Mobileでアプリがリジェクト?!

Appleのアプリ検証ツールのバグでTitanium Mobileで作成されたアプリがリジェクトされるようです。回避方法が発表されていたのでざっくり訳しておきました。

再度追記：Appleが審査用ツールを更新してこの問題はなくなったそうです。もう大丈夫。

追記：なんと、この方法ではうまくいかなかったとのこと。

Update: 2:42pm 11/13/11
Appleの審査でのスキャンを回避する修正がCIサーバ上の全てのリリースブランチでご利用頂けるようになりました。こちらのビルドでアプリを再度申請して頂ければ問題を解消することが出来るはずです。ただし、現在も私たちは今後アプリが「プライベートAPIの利用」と判定されることがないよう、申請済みのアプリでこの修正をテストしています。

Update 6:11pm 11/12/11:
下記の方法では問題は解消されないことが判明しました。現在、Appleの審査で「プライベートAPI」の利用と誤判定されるのを回避できるかどうか、別の方法を内部テスト中です。ご不便をおかけしておりますが、この問題の解決を最優先として取り組んでおります。

元の投稿：
登録したアプリがプライベートなAPIを利用しているというAppleからのフィードバックについてコミュニティから何件か報告がありましたが、まだ「layout」であるとしか確認されていません。TitaniumのアプリケーションはプライベートなAPIを利用してはいないので、私たちはこれはAppleのアプリ解析ツールに何か変更があり、それが間違ってTitaniumのアプリのプロパティを検知しているのではないかと考えています。

Appleの解析ロジックにおけるこの不具合の回避方法ですが、私たちは実装ロジックから「layout」というキーワードの使用を避ける新しいビルドを用意しました。現在もこの修正が正しいものかどうかAppleのApp Storeで検証しているところです。この特別版ビルドのインストールして利用するには、下記の手順に従ってください。

今回のエラーはAppleの処理ロジックが原因でしたが、皆様がApp Storeへの登録作業を問題なく出来るようにするのが私たちの希望です。本件についてご質問、フィードバックなどございましたら、直接私(kwhinnery at appcelerator dot com)までご連絡頂ければ喜んでお手伝い致します。

というわけで、インストール方法はこちらの手順に従ってください。

Popularity: 3% [?]