2012-02-06
Google Checkout の個人情報の扱いについて、Google から回答が来ました
Google Checkout の個人情報の扱いに関して、1/25に Google に以下の問い合わせメールを送ってありました。
Googleウォレットチームご担当者殿
村上です。いつもお世話になっております。
以下の件すでに修正されているということですが、現在でも購入者の郵便番号、住所の一部、
本名、メールアドレスは以前表示されており、1月14日にお問い合わせさせていただいたときと比べ
何も改善されていないように見受けられます。（昨年12月初旬頃までは、メールアドレスは
@google.checkout.com のテンポラリアドレスとなっていましたので、その時と比べても悪化している
ように思われます）
これはもうこれ以上改善されない御積りなのでしょうか？先に依頼させていただきましたとおり、
販売者側としては無用な個人情報を提供された場合、販売数が5,000件を超えた時点で個人情報
取扱事業者となる義務が発生してしまうため、提供されないことを強く希望いたします。
以上、よろしくお願いいたします。
で、これに対する回答が今日届きました。以下全文。
お客様
お問い合わせありがとうございます。
お返事が遅くなりましたこと、大変申し訳ございません。
購入者のメールアドレスに関するご質問についてお答えします。Google は、購入者のメールアドレスを
お客様のようなデベロッパー (販売者) がご覧になることができるようにすることが適切であると判断し、
購入者がメールアドレスを匿名にする選択肢の提供を中止しております。例えば、アプリケーションに
関してカスタマーサポートを提供する場合や、取引に問題が発生した場合など、多くのデベロッパーが
購入者と連絡を取るためにこの情報を必要とされています。購入者のメールアドレスは、購入者とデベ
ロッパーの双方にご同意いただいている、 Google ウォレット プライバシー ポリシーに従って、デベ
ロッパーと共有されています。なお、この変更は、先般ご連絡致しました不具合に関係するものではあ
りません。
デベロッパーによる購入者の個人情報の取り扱いについては、適用のある規約・ポリシー類（以下のペ
ージにある規約およびポリシーが含まれます）をご参照ください。
1. Google を介した支払いの許可 - 利用規約 (Google ウォレット 販売者 利用規約)
https://checkout.google.com/termsOfService?type=Seller
2. Google Checkout 販売者 ポリシーおよびガイドライン
https://support.google.com/checkout/sell/bin/answer.py?hl=ja&answer=46174
3. Android マーケット デベロッパー販売/配布契約書
http://www.android.com/us/developer-distribution-agreement.html
4. Android マーケット デベロッパー プログラム ポリシー
http://www.android.com/us/developer-content-policy.html
5. Google ウォレット プライバシー ポリシー
https://checkout.google.com/files/privacy.html?hl=ja
今後とも Google ウォレット をよろしくお願い致します。
Google チーム
えーと、利用者のメールアドレスは販売者に通知しますと。このことは Google ウォレットプライバシーポリシーに記載されているということだそうです。たぶん「情報の共有」の節のことを指しているものと思いますが、私にはメールアドレスを販売者に渡すようにはちょっと読めなかったのですが、たぶん私の読解力が足りていないのに相違ありません。正しい解釈の仕方がわかる方は是非教えていただきたく。
まぁ、別にメールアドレスが必要だったら、それでもいいです。実際、サポートで必要になる場合もあるかもしれませんし（私はいらないが。ユーザから問い合わせくればわかるんだし)。でもメールアドレスを販売者に渡すよ、って利用者にわかりやすく示しておく必要はあると思うのですけどね。
それと、住所の一部が開示されていることに関しては一切この回答では言及されていませんが、こっちも同じ解釈なんでしょうか。
再度質問を送っても良いのですが、たぶん回答が返ってくるときには３月から発効する新しいプライバシーポリシーを見ろ、ということになりそうな気が激しくするのでやる気でないなー。
Permalink | コメント(0) | トラックバック(0) | 20:43 
Google AdWords 成功の法則
2012-01-04
最近 Android Market の売上レポートに購入者の個人情報が思いっきり入るようになってしまった件
注: '12/1/13、Google側が誤りであったことを認めたとのことです。詳細は一番下の追記参照。
最近、Android Market の売上レポートに購入者の完全な名前・住所・電話番号・メールアドレスなどが表示されるようになってしまい、少々困っています。
Android Market でのアプリ売上は Google Checkout というサイトで確認できるようになっており、それぞれの売上ごとに詳細なレポートを閲覧できるようになっています。以下はその中の抜粋です（個人情報は全部塗りつぶしています)
配送先というところに、購入者の完全な住所・名前・携帯電話番号・メールアドレスが入ってしまっています。この配送先は前からレポートには出ていたのですが、以前は情報は部分的なものでした（住所は番地なし、電話番号なし、メールアドレスは @checkout.google.com のようなテンポラリなもの)
厳密には、完全な情報が入っているものとそうでないものが混在している（どういうルールなのかは知りません）のですが、ここ最近になってほとんどのレポートに完全な情報が入るようになってしまっています。
買う側からするとこのような情報が Google からアプリ販売者に行っているとはたぶん思っていないでしょう。販売する側からしてもそんな情報もらってしまったら個人情報としてきちんと管理しなければならず、はっきり言って迷惑です。
これが Google 側のプライバシーポリシーでどういうことになっているのかを少し確認してみました。これは Google Wallet プライバシーポリシー が該当します。この中に「情報の共有」という項があり、個人情報は基本的に第三者には渡さないが、例外条件が７個あると書いてあります。詳細は原文を見てもらうとして、だいたいこんな感じ。
- 取り引きの処理とアカウントの管理に必要な場合
- 不正行為、セキュリティ上の問題、技術的な問題を検知、防止、またはその他これらに対処するため
- ユーザーの同意がある場合
- 個人情報の処理を委託するため
- 法的な理由とか不正行為への対処とか財産の保全とかのため
- 販売者発行のクレジットカードを利用するケース
- 個人を特定できない集計情報
このうち、2〜7の条件はアプリ販売者に情報を渡す理由にはならなさそうです。1番目はやや微妙で注文のキャンセル処理で必要だと言えなくもないですが、条文を見るかぎり渡すのは電話番号だけで、しかも電話番号を渡した場合はユーザに通知されることとなっています。
ダメじゃねーか ＞Google
正直、購入者の完全な住所とかを販売者に渡してしまうのは、このプライバシーポリシーに激しく違反しているような気がします。識者の意見を聞きたいところ。
ちなみに、Apple の AppStore がどうなっているかですが、こちらは売れた本数しか報告してこないので、個人情報は一切販売者には渡されません。さすがですね。(逆に言えば個別に返金とかできないんですが)
1/5 8:07AM 補足: 上記は Android Market の有料アプリ販売の場合です。無料アプリの場合、Google checkout にはレポートは出ませんので個人情報は開発者側には渡されません。念のため。
2012/1/7 23:22追記: 上記の現象は'11/12/17以降のすべての注文に対して発生していましたが、現在確認したところ該当する注文について番地・電話番号は表示されなくなっています。何らかの対策がされたのかもしれません。ただ、それでも番地を含まない住所、名前、メールアドレスはまだ表示されています。
2012/1/13 0:32追記: ニュース出ましたね ⇒ グーグル 誤って個人情報表示。でもまだ番地なし住所、名前、メールアドレスは出てるんですが、これはこのままなんでしょうか？
2012/2/6 1:00追記: すでに1ヶ月経過しましたが、番地なし住所、名前、メールアドレスはまだ出ています。これはもうこのままのようですね。
2012/2/6 20:44追記: Google から回答メール来たので、次のエントリに詳細を書きました。
Permalink | コメント(47) | トラックバック(8) | 22:41 
2011-12-12
Android Market / Google Checkout から売上明細を自動ダウンロードするツールを作った
Android Market および Google Checkout から、Android アプリの売上明細とオーダー一覧をダウンロードするツールを作ってみました。github で公開しています。
http://github.com/tmurakam/android-checkout-scraper
とりあえず CSV でダウンロードするだけです。これを使って、売上のグラフ作るとか、誰かシステム作ってくれると嬉しい。
Permalink | コメント(0) | トラックバック(0) | 00:01 
2011-10-11
HTTPS を使ってるアプリを AppStore や Android Market で配信するときの輸出手続きについて（その4) - 商務省BISに暗号登録してみたよ！
その３までで終わるつもりだったのですが、せっかくなので米国商務省BISに暗号登録までやってみました。
参考にしたのはこちらのブログです → Apple iTunes export restrictions on apps
やってみたら思いのほか簡単に ERN 取得できたので、やり方を書いてみようと思います。
登録するアプリについて
登録するアプリは、今開発中のこれです。
どこで暗号を使っているかというと、Twitter でツイートするところです。認証部分のところですね。このアプリは iOS5 専用で作っていて、Twitter のライブラリは iOS5 標準搭載のを使ってます。
みてわかる通り、このアプリはホームユースなので、その２に書いた通り Category 5, Part 2 には該当しません。また、該当したとしてもそもそも Twitter の認証でしか https を使ってないので、5D992-NLR で申告なしで輸出可能です。
にも関わらず、なぜ暗号登録をしたのか？理由は、単に暗号登録をしてみたかったからというだけです。我ながらマゾだと思いますw
追記: ちょっと勘違いしていたのですが、ERN は製品ごとではなくて、ベンダごとに１個とればよいようです。私は既に取得したので、今後は取る必要はないということですね。iOS に搭載されている標準暗号しか使わない場合は、ERNさえ最初にとっとけば製品毎に個別に申請はしなくていい、、、と思います。
SNAP-R への登録
まず最初にやるべきことは、SNAP-Rでのアカウント登録です。
これは SNAP-Rのサイトにいって、”Register online for a SNAP-R account”と書いてあるリンクをクリックして登録するだけです。個人で登録する場合、Company Name には個人名を入れて登録すればいいでしょう。
フォームに記入／送信が完了してしばらくすると、BISからメールが飛んできます。あとは記載されているリンクに従ってアカウント設定をすれば完了です。
EAR Part 742, Supplement 5 の資料を作成
ここが一番面倒なところです。BIS に提出する資料の作成です。
資料は、EAR Part 742 の末尾のほうにある "Supplement 5" に回答する形で作ります。PDF でしか書類を受け付けてくれないので、Word で作って PDF にするなりしてください。今回は Google docs で作りました。
Google docs 上にテンプレートを作成しましたので、参考にしてください → テンプレート
また、私が作成した資料をここにおいておきますので、煮るなり焼くなりどうぞ (住所とかは伏せてあります)
SNAP-R 上で暗号登録
いよいよ SNAP-R で暗号を登録します。
SNAP-R にログインしたら、画面左にある "Create Work Item" をクリックします。新規 Item の作成画面になりますので、"Encryption Registration" を選びます。(番号分類申請するときはこっちじゃなくて、Common Classification Request になるので注意)。Reference Number はアルファベット３文字 + 数字４文字で適当につけていいです。ここでは安直に "ERN0001" にしました。
登録画面になりますが、基本的なフォームは全部埋まっているはずです。画面一番下の「Documents attached to application」のところに、先ほど作成したドキュメントをアップロードします。"View and Manage Supporting Document" のリンクをクリックし、"Upload Supporting Document" をクリックすると、アップロード画面になります。
Document Type は "Encryption Registration Supp. No.5 to Part 742" を選びます。あとは適当で。
アップロードが終わったら、Item に戻り、「Preview Work Item to Submit」を押します。確認したらもう一度 Submit。
最後に署名画面が出ますので、名前や Title を入力します。名前は、Firstname 一文字 + "." + Lastname で書く必要があるので注意。
終わったら、画面左にある "View Messages" を見ると、メッセージが届いています。これを開くと ERN 番号が書いてあります。
おめでとう、これで ERN 取得完了です！！！
あとは、この画面をキャプチャしておきましょう。iTunes connect でアプリを登録するときに、このキャプチャした資料を添付すれば OK です。
まとめ
これで無事 ERN を取得できました。
マスマーケット暗号 742.15(b) に該当するアプリで iOS に搭載されている標準暗号のみを使用するアプリの場合(つまり 742.15(b)(1) に該当する場合)、さしあたり iTunes connect へのアップロード時にこの ERN を提示すればその場でアプリを提出できます。
あとは、年１回の自己番号分類報告を作成してBISにメールで送付する必要があります。が、これは簡単な CSV ファイルを作って送るだけなので、そんなに大変じゃない、、、、と思います。
なお、非標準暗号を使っている場合 (742.15(b)(3)に該当する）はやや面倒で、BIS に番号分類申請をして CCATS を取得する必要があります。
Android Market でも、基本的には同じ手続きをしておけばよいかと思います。
10/12: まとめの内容を訂正しました (742.15(b)(4)が事実上使えないことがわかったため)
Permalink | コメント(1) | トラックバック(1) | 19:22 
2011-10-10
HTTPS を使ってるアプリを AppStore や Android Market で配信するときの輸出手続きについて（その3) - 暗号分類
前回のエントリで、EAR の Category 5, Part 2 に該当するかどうかの判定まで書きました。今回は、該当する場合に、さらに暗号の分類をする方法について書いてみます。分類によっては無許可で輸出できるケースがあります。
どこを見るかですが、今度は暗号を使用する品目に対するEARの規制の 2. の中にあるフローチャート2をみて分類していきます。(原文はこちら)
なお、以下の説明で Q. の番号は説明のために私が勝手に振ってます （前回の Q. の番号と重複しないように振ってあります)
Q5. 一般に公開されている暗号ソースコードですか？
AppStore/Android Marketで配信するアプリはソースコードではなくてバイナリですから、ここは No になります。
蛇足ですが、オープンソースなどで一般公開されている暗号ソースコードは許可例外TSU(740.13(e))というものを使ってテロ支援国以外に輸出できるようになっています。
Q6. ベータテストソフトウェアですか？
当然 No ですよね？
Q7. 鍵長が対称鍵56ビット以下、非対称鍵512ビット以下、楕円暗号鍵112ビット以下ですか？
鍵長がこれ以下の場合は、5D992-NLR (No License Required)に分類され、申告なしで輸出できます。
HTTPS(SSL)の場合、鍵長はクライアントとサーバの組み合わせで決まります。DES-56bit だと対称鍵56ビットなので条件を満たしますが、今時そんなものは使わず対称鍵128ビットを使うので、ここは No ということになるでしょう。
Q8. 5A002の注釈(除外条項)通りに限定された暗号ですか？
5A002の注釈はこちらを見てください。２ページ目の注と書かれているところです。ここに挙げられているものは5D992-NLRに分類され、申告なしで輸出できます。
ここには、スマートカード、銀行業務、携帯用無線電話機関連、コードレス電話関連、無線PAN、などなどがあります。ちょっと量が多いので、注釈を読んでください（だんだんなげやりになってきた、、、)
銀行業務のくだりは、iTunes Connect の２番目の質問の d) が該当しますね。
Q9. 認証のみですか？
ここ結構重要。暗号機能が認証のためにだけ使われていれば、5D992-NLR として申告なしで輸出できます。
前回エントリで Twitter クライアントの例をあげましたが、Twitter API で HTTPS を使うのはおもに認証部分で、ツイートするところは HTTP を使いますので、本項目により申告なしにできる可能性があります(ダイレクトメッセージの取得など一部の API は HTTPS なので、これを使ってるとダメですが、、、)
なお、これは iTunes Connect の２番目の質問の c) が該当します。
Q10. マスマーケット製品ですか？
輸出したいものがマスマーケット品かどうかで判断がわかれます。
マスマーケット品の定義はこちらの注３に書いてあるので確認してください。AppStore/Android Marketで配信するアプリは、(a)電子取引により一般に入手可能で、(b)暗号機能が使用者によって変更不可能で、(c)インストール時に供給者による支援が不要で、(d)必要に応じて当局に詳細を提供できる、のでほぼマスマーケット品に該当するといえるでしょう。
10/11追記: 非標準暗号を使っている場合は、マスマーケット品にはなりませんので注意。これは§742.15(b)のところにかいてあります。
マスマーケット品の場合は、そうでないものよりだいぶ規制が緩くなります。以下の説明はマスマーケット品だとして説明しています。
Q11. マスマーケット品の場合、鍵長が対象鍵64ビット以下、非対称鍵768ビット以下、楕円暗号鍵128ビット以下ですか？
マスマーケット品の場合、Q7より鍵長の基準がちょっとだけ緩くなります。この条件を満たしていれば 5D992-NLR として申告なしで輸出できます。
んが、HTTPS は先に述べたとおり、No になるかと思います。
対称鍵64ビット超のマスマーケット暗号
Q11 が No だった場合、対称鍵64ビット超のマスマーケット暗号として、EAR §742.15 を使用することになります。
これについては§742.15の (b) にある「鍵長が64ビットを超えるマスマーケット暗号」云々を確認します。また、こちらにも簡単な表があります(原文はこちら)
(b)項には 1), 3), 4)の３つがあり、4) に該当した場合は 5D992-NLR として申告なしで輸出できます。
、、、が、下に書いた通り 4) は事実上使えませんので、1) か 3) を使わなければなりません。
742.15 (b)(4) マスマーケット番号分類請求、暗号登録及び自己番号分類報告の要求事項の除外
(b)(4)にはさらに i) と ii) があります。i) は短距離無線暗号(WLANとか)なので、アプリはあまり関係ありません。
ii) は、米国原産ソースコードやツールキットを使って開発されたもの、あるいは組み込んだものです。ただし、その暗号機能がすでに商務省BISにより番号分類されて、登録・承認されていることが条件です。
iOSに組み込まれている暗号機能は BIS により承認されているので、この条件が合致するはずです。
Apple 製品に搭載されている暗号機能については、Apple の Export Compliance に書いてあります。iOS SDK は 5D992.c で NLR (許可不要)。CCATS 番号は G136387 となっています。
なお、Android の場合は、含まれる暗号が承認されているかどうかも不明。Google のサイトかどこかに書いてあるんでしょうか？
10/12修正: 残念ながら、(b)(4)(ii) の条項は「米国からの」輸出には適用できないことが判明しました。したがって、AppStore や Android Market で配信するアプリではこれを使うことはできません。標準暗号のみを使っている場合は (b)(1) を、非標準暗号を使っている場合は (b)(3) を使うしかありません。
742.15 (b)(1) 即時のマスマーケット承認
これは暗号登録を BIS に提出し、ERN (Encryption Registration Number)を発行してもらえれば、5D992-NLRとして輸出ができます。ただし、以下の (b)(3)の品目を除きます。
ただし、この場合は自己番号分類報告というのを年に１度提出しなければなりません。まあ、CSVファイルを作ってメールで送るだけなんで、大した手間ではないですが。
742.15 (b)(3) 特定のマスマーケット貨物、ソフトウェア及び部分品に対して義務付けられる番号分類請求
(b)(3)に該当する条件はいくつかありますが、特に重要なのは「非標準暗号」を使っている場合。
(b)(3)の場合、ERNの発行の他に、番号分類請求をする必要があります。番号分類請求をして30日経過したら、5D992-NLRとして輸出が可能です。
まとめ
上記のとおり分類した結果、5D992-NLRで申告不要、となった場合は申告は不要です。iTunes connect の暗号の２番目の質問は Yes になると思います。
これが No になる場合は、米国商務省 BIS に暗号登録を申請し、ERN を取得しなければなりません(742.15(b)(3)の場合はさらに番号分類申請をしてCCATSを取得)。iTunes Connect では ERN や CCATS をアップロードする必要があります。Android Market では一切提出は求められないですが、ちゃんとやっておけよという項目はありますね（そーいうのは怖いって)。
なお、BISへの申請は全部 Web 上でできるようになっています。これは SNAP-R というシステムでできます。SNAP-RについてはSNAP-Rオンライン提出に記述があります。申請自体は30分あればできるよー、ということになっているようです（つーか、書類書くの３０分で終わらねーよ！と思うのですが）
ちなみに私は個人で SNAP-R のアカウントだけ取りました。でも、申告が必要な状態にはなってないのでまだ ERN 取得はしたことないですけどね。本当は ERN 取得までやって、そのやり方まで書けるとよかったんですが。→ 10/11追記 : ERN 取得しました。次のエントリに詳細を書いてあります。
以上で、暗号を使っているアプリを配信するときの輸出に関する説明は終わりです。この手の解説が全然なかったので、少しでも開発者の皆さんのお役に立てれば幸いです。
Permalink | コメント(0) | トラックバック(1) | 03:31 
HTTPS を使ってるアプリを AppStore や Android Market で配信するときの輸出手続きについて（その2) - 規制対象になるかどうかの判断
今回は、暗号を使用しているアプリが、EAR で実際に規制されるかどうかについて書いてみます。
※ 最初に断っておきますが、私は法律の専門家ではないので、間違いとかが入っている可能性がなくはないです。ですので、この記事を信用して損害を被ったとしても保証はいたしかねます。また、間違いがあれば指摘してくださいね。前回の記事がはてなブックマークの人気エントリ入りして内心ひやひやしてます。
Category 5, Part 2 で規制されるかの確認
暗号品目は、EAR の規制品目 (CCL, Commerce Control List) の中の Category 5, Part 2 というところにあります。暗号品目には貨物（ハードとか）、ソフト、技術などがありますが、AppStore/Android Market で配布するものはもちろんソフトです。そして暗号ソフトは 5D002 とか 5D992 という品目番号になります (この番号のことを、ECCN（Export Control Classification Number, 輸出規制品目分類番号）と言います)
ここでは、この Category 5, Part 2 に該当するかどうか調べるわけですが、まず 暗号使用品目のEAR規制 というところの中にある フローチャート1 を見ていきます (原文はこっちです)。
もし該当していない、となった場合は、暗号に関しては無許可で輸出が可能です (もちろん、本当に輸出可能かどうかは、他のリスト規制やキャッチオール規制もちゃんと見たうえで、、、になるわけですが、そこまでは説明しきれません。あしからず）
Q1. その品目は、暗号技術を使用するように設計していますかまたは暗号機能を搭載していますか？
最初の質問がこれ。ようは暗号を使ってるか、搭載してるか？と聞いているわけです。暗号を全然使ってなければ No ですが、OS の標準暗号ライブラリを「使って」いる場合はここは Yes と答えます。HTTPS を使っている場合は当然 Yes です。
これは AppStore の Export Compliance で真っ先に聞かれる質問 ("Is your product designed to use cryptography or does it contain or incorporate cryptography?") と同じですね。
Q2. このハードウェア又はソフトウェアは医療の最終用途のために特別に設計したものですか？
医療用途向けのハード、ソフトは規制対象から外れます。まぁ、たいていの場合は No ですね。
なお、どういうものが医療の最終用途か、というのは EAR にきちんと書いてあるので、該当しそうな場合は確認してみてください。
Q4. その暗号機能は、知的所有権保護または著作権保護に限定されていますか？
Q3. はややこしいので先に Q4 を見ます。
これは要するに、DRM 用途にしか暗号を使ってなければ規制対象外ですよ、ということです。DLNA とかはそうですね。
なお、HTTPS 通信は大概 DRM 用途じゃない(そういう場合もあるかもしれないが）ですので、ここは No になることが多いと思います。
Q3. その製品は注4により定められるものですか？
これはいわゆる副次的暗号に関連する判断です。これはややこしい。
これについては、研究WG 副次的暗号あたりが参考になります。というかこれ読め。
注４というのはどの品目が、暗号規制から削除されましたか？に書いてあります。注４だけ抜粋。
注4：カテゴリー５パート２は、"暗号"を組み込んでいる又は使用している品目であって、
次のすべての条件を満たすものには適用されない：
a. 品目の主たる機能又は一連の機能が次のいずれにも該当しないもの：
1."情報セキュリティー"；
2. コンピュータ（これらのためのオペレーティングシステム、部品及び部分品を含む）；
3. 情報の送信、受信若しくは保存（娯楽、マスコミュニケーション放送、デジタル著作権管理若しくは医療
記録管理を支援するものを除く）；又は
4.ネットワーキング（ネットワークの操作、管理、運用及び構築を含む）；
b. 暗号機能がこれらの品目の主たる機能又は一連の機能の支援のためにのみ用いられているもの；
並びに
c. 必要に応じて、上記のa項及びb項で定める条件に適合していることを確認するために、品目の詳細が
アクセスでき、かつ、請求があり次第、輸出国のしかるべき当局に提示されること。
条件として a, b, c があって、この３つを全部満たしていれば規制されません。
判定のためには、まずソフトウェアの「主たる目的」を考える必要があります。ここでは例として Twitter クライアントを例にあげてみましょう。この場合、主たる目的は「ツイートの送信、受信」です。
まず a. について見ていくと、主たる機能が1〜4のいずれにも該当しなければOKです。1 はセキュリティそのものが目的（アンチウィルスとかファイヤウォールとか）、2 は主にOS とかドライバ(通常アプリは該当しない)、3 は情報の送受信と保存、4 はネットワーク管理系です。この中でくせものは 3. ですね。
Twitter クライアントの主たる目的は「ツイートの送信、受信」なので、3 が該当します。ただ、3. には除外条件がついていて、娯楽、マスコミ放送、DRM、医療記録用途は除外です。Twitter クライアントが娯楽用途（たとえば今何を食べたかツイートするとか）のものなら、娯楽用途ということで除外できます。ですが、ビジネス用だったら除外できません。この辺の判断はちょっと難しいですが、EAR のほうには具体例があげてあるのでそちらを見てみるのもいいでしょう。
b. に関してですが、暗号機能が主たる機能の支援のためにのみに使われていれば OK です（主たる目的以外の用途はだめ、、、ということ）。Twitter では認証時(OAuth)に HTTPS 通信をしますが、これはもちろん主たる目的の「ツイートの送受信」の支援で必要なものなので、OK と考えてよいと思います。
c. に関しては問題ないでしょう。当局から詳細突っ込まれたときにちゃんと答えられるようにしておけということです。
そんなわけで、娯楽用のTwitterクライアントはセーフですが、ビジネス用（もしくはビジネス用にも使える）Twitterクライアントはアウト、ということになるかと思います。ただ、実際のところTwitter クライアントは別の条件によりセーフになると思われますが、これについでは次回書きます。
ここまでのまとめ
上記のように、Q1 から Q4 の質問をどれか一つクリアできれば、規制はかかりませんので、申告は不要です。
ちなみに、Q2からQ4までの質問は、iTunes Connect の暗号関連の質問の２番目の質問に含まれています。
You can answer "YES" to question #2, if the encryption in your app is: (a) is specially designed
for medical end-use; (b) is limited to intellectual property or copyright protection; (c) is
limited to authentication, digital signature or the decryption of data or files; (d) is
specially designed and limited for banking use or 'money transactions'; (e) is limited to
“fixed” data compression or coding techniques; or (f) if your app meets the descriptions
provided in Note 4 to Category 5 Part 2.
Q2 は a), Q3 は f), Q4 は b) です。
ちなみに、e) は暗号の定義の話で「“暗号処理”には、”固定式”のデータ圧縮又は符号化技術を含まない」というもので、要は秘匿パラメータ(鍵)を使わないものは暗号とは言わないということみたいです (これは Category5, Part2 の Technical Note のところに書いてあります)
残念ながらどれもクリアできなかった場合は、Category 5, Part 2 に該当することになりますので、米国商務省 BIS に対して何らかの申告が必要になる可能性が大です。
ですが、上の iTunes connect の質問の c), d) のように無許可で済むケースもあります。この判定については次のエントリで書きたいと思います。
Permalink | コメント(0) | トラックバック(1) | 00:13 
