タグ別アーカイブ: iOS

NHKの「偽・佐川」警告記事を批判したIT関係者に徹底反論

NHKが2018/07/27 16:35に公開したこの記事『本物そっくり!?「偽・佐川」に厳重注意を!』(2018/07/27 16:35 NHK)にネット上の批判が集まったらしいが、その批判そのものが間違っていることを徹底的に批判してみる。

それらの批判はこちらの『NHKの「偽・佐川」警告記事に批判集まる。iPhoneが攻撃アプリに感染すると誤解を生む内容』(2018/07/28 20:37 Yahoo!ニュース)という記事でまとめられている。

民間企業でIT技術者として一般社員に情報セキュリティの啓蒙活動をしている立場からすると、上記NHKの記事はきわめて適切である。これを批判した方々は少なくとも啓蒙家としては適性がない。

日本のiPhoneのシェアの異常な高さ

批判の第一点は今回のフィッシングメールでマルウェア感染のリスクがないiPhoneの画面を掲載している点にあった。

しかし日本は世界的に見てiOSのシェアが異常に高い特殊な国である。

こちらがIDCによる2017年日本国内スマートフォンのベンダー別出荷台数だがAppleは約半数を占める。

他方、こちらは全世界の2017年各四半期ベンダー別出荷台数で、サムスンが常に2割強でAppleをしのいでいる。3位以下はHuawei、Xiaomi、OPPOとなっている。

日本人はXiaomi、OPPOなどというメーカーの名前自体知らないだろうし、世界第三位のHuaweiも日本国内のシェアはたった4%だ。

仮にAndroidの画面を使うとして、日本のAndroid端末の画面はキャリア固有アプリのアイコンが並んでいたり、比較的高いシェアのHuaweiはEMUIという独自UI、ASUSは設定画面が独自UIだったりと、そもそも「これが素のAndroidだ」と分かっている一般人などいない。

また一般人がスマホを選ぶとき、iOSとAndroidの違いを理解して機種を選んでいるわけではない。Apple製品の方がデザインが良いとか、友だちや家族にiPhoneを使っている人が多いからなど、技術的観点と無関係な理由で選んでいる。

したがって日本の一般人向けにできるだけ多くの注意を引きとめるために、技術的正確さを犠牲にしてもシェアの観点から「スマホ代表」としてiOS画面を選ぶのは方法論として正しい。

iOSで実害のあるフィッシングメールの存在

今回NHKが取り上げた佐川急便のフィッシングメールはapkファイルのダウンロードへ誘導するもので、たまたまiOSに影響はないだけだ。これが例えば遷移先サイトでApple IDとパスワードを詐取するものであればiOSユーザにも実害がある。

また、一般人は上述のようにiOSとAndroidの違いを技術的に理解しているわけではないため、フィッシングメールの中にiOSに無害なものと、AndroidとiOSの両方に害のあるものといった区別は付かない。

さらに一般人は当然ながら「フィッシング」「マルウェア」などのカテゴリーでサイバー攻撃を認識できない。「なんだか怪しい」という漠然とした不安や恐怖心があるだけだ。

その程度の認識しかない一般人に対して「今回の詐欺はAndroidにしか害がなく、iOSは大丈夫です」と伝えようものなら、まず「Androidって何?」という話になる。運よくその段階をクリアしたとしても「iOSは大丈夫」という間違った安心感を持たせてしまう。

たまたま今回のケースはapkダウンロード型でiOSに害はないが、技術的に正確に「iOSは害がありません」と伝えることで、かえってiOSユーザが別の種類のフィッシングで被害にあうリスクを確実に高める。

今回の啓蒙としては「SMSやメール経由で開いた怪しいサイトには要注意」という、非常にざっくりしたメッセージさえ伝わればよい。

啓蒙活動にかかわる方々は、最も知識レベルの低い聴衆に合わせて情報提供すべきである。そうすればこちらが伝えた内容が正確でないと分かる人たちは喜んで周囲に正しい知識を伝えてくれる。

啓蒙する側としては「スキ」のある内容を伝えた方が情報に伝播力を持たせることができる。まさに今回のNHKの記事にネット上の「専門家」の方々が喜んで食いついたように。

一般ユーザの「怠惰」の正しさ

一般ユーザは技術的なことが分からないので、スマホを購入して使い始めるときにいちいち説明書を読まない。iOSやAndroidの勉強などしない。使いたいアプリがすぐに使い始められさえすれば、OSの設定画面をわざわざ潜っていくなどの手間はかけない。

一般ユーザを致命的なサイバー攻撃から守っているのは、実はこの「怠惰」である。

今回の件もAndroidはデフォルトで提供元不明アプリのインストール許可はオフになっている。ユーザの「怠惰」が正しい結果につながるようにベンダーがフールプルーフ前提の「セキュリティ・バイ・デザイン」をやってくれているからだ。

にもかかわらず、わざわざ「提供元不明アプリのインストール許可はオフにしましょう」などという情報を伝え、それをマジメに聞いてしまった一般人が出てくると、その何割かは確実に逆のことをする。インストール許可をオンにしてしまう。

啓蒙活動においては、相手の情報処理能力に限界を前提として余計な情報を与えないことだ。

余計な情報を与えても何割かの聴衆は30秒後には忘れている。この物忘れの速さも正しい結果につながることがある。

また今回の佐川急便の例では別の面で一般人の「怠惰」が被害を小さくしている。デフォルト設定のAndroidで提供元不明のapkファイルをインストールする手順は非常に面倒だからだ。

間違ってapkファイルのダウンロードボタンをタップしたところで、apkファイルのサイズにもよるが、ダウンロードが終わるまでに別のアプリに移動し、そのうちダウンロードしたことさえ忘れる可能性が高い。これは「怠惰」の成果だ。

仮にダウンロードを待っていたとしても、そもそも提供元不明のアプリをインストールした経験のない一般人は、通知パネルを引き下ろしてダウンロード完了メッセージをタップするという手順が思いつかない。「あれ?さっきボタンを押したけど、ダウンロードしたのはどこ行った?」という程度だ。

この時点で面倒になって「まあどうせ家のポストに不在通知が入るし」とインストールをあきらめるだろう。これも「怠惰」の成果だ。

それでもあきらめずにダウンロード通知を奇跡的にタップできたとすると、提供元不明アプリのインストール警告が現れ、これを受け入れる必要がある。

この時点で「いい加減にしろよ、こっちはそんなにヒマじゃないんだよ。荷物の追跡くらいメールで送ってくればいいだろ」と切れ気味に別のアプリに戻る。これも「怠惰」の勝利だ。

これらはフールプルーフによる「セキュリティ・バイ・デザイン」の成果だ。エンドユーザの「バカ」や「怠惰」を安全な結果へ誘導するための工夫だ。

それを中途半端な啓蒙記事はぶち壊しにする。啓蒙家気取りのみなさんは、少なくともフールプルーフやセキュリティ・バイ・デザインの効果をぶち壊しにしないでほしい。

その効果をぶち壊しても「バカ」で「怠惰」な一般人を啓蒙したいというなら、そういう一般人を1分間以上引き留めるニュース原稿や、10分間以上引き留めるネット記事を書いてみてはどうか。

啓蒙で最も重要なのは知性ではなく感情

まして今回NHKがトレンドマイクロを担ぎ出したことについて、「トレンドマイクロを儲けさせるためだ」とする陰謀論まで出てくる始末だが、NHKがトレンドマイクロを担ぎ出したことも正しい。

無知な一般人に対する啓蒙で最も重要なのは相手の知性に訴えることではなく、感情で釣り上げることだ。

日本人は一般的に権威主義的なので、トレンドマイクロでもシマンテックでもカスペルスキーでも何でもいいので「専門家」を引っ張り出してきて祭り上げ、小難しいことを語らせれば感情で釣り上げることができる。

「なんだかよく分からないけど、偉い人が気を付けろって言ってるから気を付けなきゃ」

ここまでこぎつければ今回の啓蒙活動は成功である。

今回のフィッシングがiOSには害がないとか、Androidの設定画面でどうすれば提供元不明アプリのインストールを防止できるかとか、そうした情報はどうせ聴衆の頭に残らない。

聴衆の感情的なフックを利用してこちらに注意を向けさせ、細かいことは抜きにして危機感さえ持ってもらえれば、その後により正確なことを知ろうという動機づけにつながる。

逆に、最初から技術的に正確なことを伝えようとして「なんだか面倒だ」「よく分からない」とマイナスの動機づけを与えてしまえば、啓蒙活動としては失敗である。

そんなことさえ分からない人たちがツイッターで啓蒙活動っぽいことをやっているのだから、専門家の「裸の王様」具合は滑稽でさえある。

なおこのブログ記事は専門家に向けられたもので、一般人に向けて書かれた啓蒙記事ではない。

iOS swiftのCoreDataをバージョン管理するために必要なAppDelegate.swiftの変更

swift+Xcode7でiOSアプリの開発をやっていて、こんな大事なことがどうしてもっと分かりやすいところに書いていないのだろうと思ったので、自分のメモ代わりにここに書いておく。

アプリの中でデータモデルを定義してmanagedObjectとして扱っているとき、アプリの機能を増やしていくと、どうしてもデータモデルの定義(RDBでいうとテーブル定義みたいなもの)を変更する必要が出てくる。

そこで〜.xcdatamodeldファイルを選択した状態で、Xcode の Editor メニューの Add Model Version… をクリックして、データモデルの新バージョンを作成する。デフォルトでは同じファイル名で末尾に半角スペースとバージョンを示す数字が2から始まって付加され、新しい〜.xcdatamodeldが、元の〜.xcdatamodeldファイルの子供のファイルとして自動生成される。

そして新しく作成された〜.xcdatamodeldファイルの方で、データモデルを変更し、親の〜.xcdatamodeldファイルを選択した状態で、Xcodeのウィンドウの右端のプロパティーの Model Version の Current で新しい方のファイルを選択すればよい。

このようにデータモデルをバージョン管理化した後、の話である。

このとき単に 〜.xcdatamodeld ファイルで Entity (RDBで言うテーブル) に Attribute (RDBで言うカラム)を追加し、対応する 〜+CoreDataProperties.swift ファイルに @NSManaged var 〜という具合に、追加した Attribute と同名の変数を追加して対応させるだけでは、コンパイル・エラーになってしまう。

実は、さらに Appelegate.swift (プロジェクト作成時にXcodeが自動で作成するファイル)内の lazy var persistentStoreCoordinator 関数の内部で NSPersistentStoreCoordinator の addPersistentStoreWithType メソッドを呼び出している部分を、下記に示す、変更前、変更後のように書き換える必要があるのだ!

変更前
try coordinator.addPersistentStoreWithType(NSSQLiteStoreType, configuration: nil, URL: url, options: nil)

変更後
try coordinator.addPersistentStoreWithType(NSSQLiteStoreType, configuration: nil, URL: url, options: [NSMigratePersistentStoresAutomaticallyOption: true, NSInferMappingModelAutomaticallyOption: true])

NSpersistentStoreCoordinatorのインスタンスであるcoordinatorのaddPersistentStoreWithTypeメソッドの4つめの引数 options: に、2つの要素からなる配列を記述する必要があるということ。

これらは NSPersistentStoreCoordinator クラスの定数として定義されている。

一つは NSMigratePersistentStoresAutomaticallyOption で、Store Options 定数の一つとして String 型で定義されている。

もう一つは NSInferMappingModelAutomaticallyOption で、Migration Options 定数の一つとして String 型で定義されている。

これら2つのオブションをキーとし、値を true とする Dictionary 型の引数を options に渡してやると、初めてエラーなしでコンパイルでき、CoreData のデータモデルが自動的にバージョンアップされるようになる。

参考にしたのは以下のページ。

iOS Swift入門 #171】CoreDataのDataModelアップデートのため、マイグレーションする(LightWeight Migration)

Apple社の CoreData の lightweight migration についての公式文書を読んでも、上記のページにも、具体的に AppDelegate.swift 内で addPersistentStoreWithType メソッドを呼び出している部分の options を変更すればよいとまで書かれていなかったので、かなり困った。

正直iOSアプリの開発は、Apple社の公式ドキュメントにコーディング事例が全く無いので、英語で stackoverflow.com を調べまくらないと前進しない。そのあたりが Microsoft の開発者向けチュートリアルなど、公式ドキュメントのバカがつくほど親切な点との大きな違い。

やっぱり Apple ってエリート主義のにおいをプンプンと漂わせてますねぇ。それ自体が良いことだとも、悪いことだとも思わないけれど。