IT」カテゴリーアーカイブ

欧州データ保護会議のGDPR「地理的範囲」パブコメ用ガイドライン要約(1)

2018/11/23欧州データ保護会議がGDPR第3条「地理的範囲」についてパブリックコメント用ガイドラインを公開した。コメント募集期間は2018/11/23~2019/01/18。

Guidelines 3/2018 on the territorial scope of the GDPR (Article 3) – version for public consultation (2018/11/23 欧州データ保護会議EDPB)

23ページあるガイドラインから要点をピックアップしてみる。

「地理的範囲」について問題になるのは以下の3点。

1.事業所(establishment)に関する適用基準:第3条(1)
2.対象(targeting)に関する適用基準:第3条(2)
3.国際公法によりEU加盟国の国内法が適用される場合:第3条(3)

3つ目は直接関係ないと思われるので省略する。

1.事業所(establishment)に関する適用基準:第3条(1)

事業所に関する適用基準の論点として以下の4点が挙げられている。それぞれガイドンラインに書かれている事例を読むのが近道と思われる。

a)「EU域内の事業所」の「EU域内」の解釈
b)「事業所の活動に関連して」なされる個人データの処理の「活動に関連して」の解釈
c)データ処理がEU域内で起こっているかどうかにかかわらず、EU域内のデータ管理者または処理者にGDPRが適用されることについて
d)「事業者」の解釈

1.a)「EU域内の事業所」の「EU域内」の解釈

まず1.a)「EU域内の事業所」の「EU域内」の解釈の事例。

例1 : 米国本社の自動車メーカーがブリュッセルに完全な管理下にある支店を持ち、マーケティングや広告を含め欧州の全業務を統括している。

このベルギー支社は自動車メーカーの経済活動の性質から実質的で実効的な活動を行っている安定した配置(arrangement)とみなせる。したがってベルギー支店はGDPRの意味するところで、EU域内の事業所とみなすことができる。

対象となる事例だけを見ても分かりづらいが、対象外となる事例も書かれている。

非EU企業がEU域内に事業所を持っているが、単に運営するWebサイトがEU域内でアクセスできるというだけでは対象に含まれない。

つまりEU域内で「real and effective activities(実質的で実効的な活動)」を行う事業所があれば、その事業所を統括する企業がEU域外にあっても、事業所の規模にかかわらず、非常に小さなものでも(even a minimal one)GDPRの適用対象ということだ。

では「real and effective」とはどういう意味なのかについては、このガイドラインにも書かれていない。

単にWebサイトがEU域内でアクセス可能なことは「real and effective activities」ではない。

ではEU域外の企業がEU域内でアクセスできるWebサイトを運営している場合、このWebサイトがどこまでの機能やサービスを提供していれば「real and effective」な活動をしていると見なされ、GDPR対象となるのか。

それは、1.b)「事業所の活動に関連して」なされる個人データの処理の「活動に関連して」の解釈の部分に書かれている。

1.b)「事業所の活動に関連して」の「活動に関連して」の解釈

b)はさらに次の2つの論点に分けられている。

i) EU域外のデータ管理者または処理者とEU域内の事業所の関係性
ii) EU域内の収益

1.b)i)EU域外のデータ管理者または処理者とEU域内の事業所の関係性について

EU域内の事業所が実際にいかなるデータ処理を行っていなくても、EU域外のデータ管理者または処理者とEU域内の事業所が「密接に(inextricably)」関連していればGDPRが適用される。

ではどの程度「密接に(inextricably)」関連していれば適用されるのかについては「事実についてケースバイケースの分析が密接な関連を示せば」とあり、結局ケースバイケースの判断になると書かれている。

1.b)ii) EU域内の収益について

EU域内の事業所がEU域内の活動が、域外のデータ管理者またはデータ処理者と「密接に関連する」と言える程度に収益をあげている場合は、GDPRの適用対象になるとある。

つまり収益基準は密接性基準で判断されることになり、収益基準自体に金額の基準があるわけではない。

そこで欧州データ保護会議は非EU企業や組織はデータ処理活動についてアセスメントを行うことを勧めている。

第一に、個人データが処理されているかどうか、第二に、個人データ処理の目的である活動とEU域内の組織の間に関連があるかどうか。関連があると確認できた場合は、その関連の質がGDPR適用対象となるかどうかの鍵になる。

ここで事例が出て来る。

例2 : 中国拠点のECサイトが、データ処理活動は完全に中国国内だけで行っているが、ベルリンに欧州オフィスを持ち、EU市場向けの市場予測やマーケティング・キャンペーンを主導的に行っている。

この場合、そのEU市場向けの市場予測やマーケティング・キャンペーンがECサイトの提供するサービスで収益をあげることに明白に貢献している限りにおいて、ベルリンにある欧州オフィスの活動は中国ECサイトによって行われる個人データ処理と密接に関連していると見なせる。したがって、この中国企業による個人データ処理は欧州オフィスの活動の文脈で行われていると見なせ、GDPR第3条(1)により適用対象となる。

この事例は当然すぎる。EU域内で収益をあげるためにECサイトを運営しているのだから、EU個人データ処理が中国国内に完全に限定されていてもGDPR対象になるのは当たり前だ。

例3 : 南アフリカのホテルリゾート・チェーンが、英語、ドイツ語、フランス語、スペイン語で利用できるウェブサイトでパッケージサービスを提供している。ただし同社はEU域内にオフィス、代表者、安定した配置(stable arrangement)を一つも持っていない。

この場合、EU域内に代表者や安定した配置が一つもないため、南アフリカのデータ管理者と関連したEU域内の事業所と見なせる会社は存在しない。したがって当該データ処理はGDPRの第3条(1)の対象にならない。

しかしながら、このEU域外のデータ管理者によって行われるデータ処理がGDPR第3条(2)に該当しないかを具体的に(in concreto)分析する必要がある。

この事例は、GDPR第3条(1)だけに基づけばこの南アフリカ企業はGDPR適用対象外だが、後述の第3条(2)に基づいて適用対象になるおそれがある、という意味だ。つまりこの例3はまだ結論が出ていない。

1.c)データ処理がEU域内で起こっているかどうかにかかわらず、EU域内のデータ管理者または処理者にGDPRが適用されることについて

これは事例から見てみる。

例4 : フランス企業がモロッコ、アルジェリア、チュニジアの顧客だけが利用できるカーシェアリングアプリを開発した。このサービスはこれら3か国のみで利用可能だが、全ての個人データ処理活動はフランスのデータ管理者で行われている。

個人データ収集は非EU国で起こっているが、この場合の個人データの後続の処理はEU域内のデータ管理者の活動の文脈で行われている。したがって非EUのデータ主体の個人データに関する処理であっても、このフランス企業が行うデータ処理にGDPR第3条(1)が適用される。

EU域外国籍のデータ主体や、EU域外居住のデータ主体の個人データ処理であっても、EU域内のデータ管理者が行っていればGDPRが適用されるということだ。

1.d)「事業者」の解釈

1.d)「事業者」の解釈についてもi)とii)に分かれている。

i) EU域内のデータ管理者がGDPR適用外のデータ処理者を使って行うデータ処理
ii) EU域内のデータ処理者の事業所の活動の文脈で行われるデータ処理

1.d)i)EU域内のデータ管理者がGDPR適用外のデータ処理者を使って行うデータ処理

GDPRが適用されるデータ管理者が、EU域外にありGDPRが適用されないデータ処理者を使う場合、GDPR第28条(3)にある契約または法的措置が必要になる。したがってGDPR適用外のデータ処理者もある程度までGDPRの義務を課せられる。

例6 : フィンランドの研究機関がサーミ人に関する調査を行った。同機関はロシアのサーミ人だけに関するプロジェクトを立ち上げた。このプロジェクトについて同機関はカナダにあるデータ処理者を使った。

GDPRは形式的にはカナダのデータ処理者に直接適用されないが、フィンランドのデータ管理者は、GDPRの要求を満たすようにデータを処理し、データ主体の権利を保護するよう、適切な措置を行う十分な保証を提供するデータ処理者のみを使うよう義務付けられている。フィンランドのデータ処理者はカナダのデータ処理者とデータ処理合意(data processing agreement)を締結する必要があり、データ処理者の義務は法的な行為の中で明記される。

これはいわゆるデータ管理者~EU域外データ処理者間のSCC(Standard Contractual Clauses)枠組みなどのことを指しており、問題ないだろう。

1.d)ii) EU域内のデータ処理者の事業所の活動の文脈で行われるデータ処理

ここではデータ管理者とデータ処理者の区別が書かれている。

例7 : スペインのデータ処理者が、顧客の個人データ処理のために、データ管理者であるメキシコの小売企業と契約を結んだ。メキシコの企業はそのサービスをメキシコ市場だけに提供しており、データ処理はEU域外のデータ主体のみに関わる。

このケースで、メキシコの小売企業は商品やサービスの提供を通じてEU域内の個人を対象としておらず、EU域内の個人の行動の監視も行っていない。したがってEU域外のデータ管理者によるデータ処理はGDPRが適用されない。

GDPRの規定はデータ管理者には適用されないが、データ処理者はスペインにある事業所として、それ自身の活動の文脈において行われるいかなるデータ処理についても、GDPRによって課される義務を果たす必要がある。

つまり、EU域内のデータ処理者が、EU域外のデータ管理者の単なる代理でデータ処理を行う場合でも、データ処理者はGDPRのデータ処理者に対する規定の適用を受けるということだ。

さらに、EU域内のデータ処理者は自身のデータ処理がEUやEU域内の各国法を遵守するようにしなければいけない。データ管理者からの指示がGDPRやEU域内の各国の国内法に違反する場合、データ管理者にただちにそのことを知らせる必要がある。

これはEU域内のデータ処理者が、域外のデータ管理者にとっての「データヘイヴン」にならないようにするためだと書かれている。

EU域内のデータ処理者が、意図的にEU域外のデータ管理者からデータ処理を委託された体にすることで、GDPRやEU域内の個人データ保護法制逃れをするのを防ぐためだ。

しかし、委託元のEU域外のデータ管理者には、EU域内のデータ処理者に委託したことを理由として、追加の義務が課せられることはない。では全くGDPRが適用されないのかというとそうではない。それはまだ先に書かれている。

以上で「1.事業所(establishment)に関する適用基準:第3条(1)」が終わった。

残りの「2.対象(targeting)に関する適用基準:第3条(2)」については別記事に書く。

個人的な感想を書けば、この時点ですでに論理展開が非常に複雑で、解釈が明確になるどころか、逆に理解が難しくなっている。しかも「case by case」の判断や自己アセスメントで決定する場合もあるとも書かれている。これでガイドラインと言えるのだろうか、という気はするが…。

PowerShellでRedmine REST APIにJSON形式でPOSTしてプロジェクトを新規作成する

PowerShellでRedmine REST APIにJSON形式でデータをPOSTしてプロジェクトを新規作成するとき、注意すべき事項は以下の2点。

・連想配列(ハッシュ)でPOSTするデータを用意するとき、プロジェクトの属性データ全体を”project”キーの値とした連想配列にする必要がある。
・連想配列(ハッシュ)をUTF8でエンコードする必要がある。
・APIアクセスキーを access_key をキーとしてデータに含める必要がある。

たとえば、作成したいプロジェクトの属性データは下記とします。


$data = @{
"name" = "テストのプロジェクト";
"identifier" = "testproject";
"description" = "";
"status" = 1;
"is_public" = "true";
"enabled_module_names" = @("issue_tracking", "time_tracking");
};

このデータを http://(ホスト名)/projects.json にPOSTしても422 Errorになります。

まずaccess_keyを追加する必要があります。


$data["access_key"] = "(APIアクセスキーの文字列)"

次に属性データ全体を project というキーの値にしてからPOSTする必要があります。


$postdata = @{"project" = $data}

さらにUTF8にエンコードする必要があるので。


$jsondata = ConvertTo-Json -InputObject $postdata
$jsonUTF8data = [System.Text.Encoding]::UTF8.GetBytes($jsondata)

この $jsonUTF8data をInvoke-RestMethodの-Bodyパラメータに設定します。


Invoke-RestMethod -Uri $postURI -Method POST -ContentType "application/json" -Body $jsonUTF8data -Credential $cred

これでようやく422 Errorが解消します。

GDPRの日本に対する「相互的十分性認定」は実際は「不十分」かつ「片務的」のように見える:個人情報保護委員会のパブコメへの回答から

欧州個人データ保護規則(GDPR)について、日本が欧州から欧州個人データの域外移転について十分性認定を受け、今年2018年中には正式に発効する。

その十分性認定を受けることができたのは、日本の個人情報保護委員会が、既存の個人情報保護法への補完的ルールとして「個人情報の保護に関する法律に係るEU域内から十分性認定により移転を受けた個人データの取扱いに関する補完的ルール」(以下「補完的ルール」)を制定、パブリックコメント募集を経て正式に発効させたことだ。

しかも今回の十分性認定は「相互的 mutual」なもので、欧州個人データを欧州から日本へ「without being subject to any further safeguards or authorisations(何らこれ以上の安全措置や認証を条件とすることなく)」(‘Questions & Answers on the Japan adequacy decision’ 2018/07/17 欧州委員会)域外移転できると同時に、日本から日本の個人データを欧州へ域外移転できることになった。

・・・はずである。

「相互的」とは普通に理解すればそういうことで、欧州委員会も「this is the first time the EU and a third country agreed on a reciprocal recognition of the adequate level of data protection(EUと第三国が個人データ保護の十分性レベルの相互認証に合意した最初の事例である)」と、わざわざこの実績を誇っている(‘Questions & Answers on the Japan adequacy decision’(欧州委員会 2018/07/17))。

ところが、日本の個人情報保護委員会が上記、補完的ルールのパブコメで集まった意見に対するオフィシャルな回答をつけた『「個人情報の保護に関する法律についてのガイドライン(EU域内から十分性認定により移転を受けた個人データの取扱い編)(案)」に関する意見募集結果』(2018/08/24)を読むと、がく然とする。

日本政府側は「相互的」ということについて対応する気がないらしいからだ。

この「意見募集結果」にある個人情報保護委員会の回答に何度も出てくる次の決まり文句が、それを雄弁に物語っている。

本案は、EU 域内から十分性認定に基づき日本国内に移転した個人に関する情報の取扱いについて適用されるものであり、それ以外の情報に適用されるものではありません。

今回の十分性認定は「相互的」であるが、にもかかわらず個人情報保護委員会が、欧州へ移転された日本の個人のデータの取扱いについて補完的ルールをいっさい示していないし、欧州に補完的ルールの制定を求めてもいない。つまり、個人情報保護委員会は現行の個人情報保護法で良いと考えていることになる。

しかしGDPRと個人情報保護法を比べると、明らかにGDPRの方が厳しい。

ということは、個人情報保護委員会は欧州個人データより自国民の個人情報の方がゆるく扱われても構わないと宣言しているようなものだ。

このことは「意見募集結果」に何度も登場する次の決まり文句が明確に示している。

当委員会は、EU の GDPR の各種規定に関する解釈権限を有していないため、GDPR の解釈についての回答は差し控えさせていただきます。また、当委員会では、引き続き、GDPR の制度概要及び本案の内容について、情報発信と周知広報に努めてまいります。

日本政府(個人情報保護委員会)は今回の十分性認定が「相互的」であるにもかかわらず、GDPRの解釈を欧州に丸投げしている。

このことは、欧州個人データが日本へ移転された場合は、GDPRに沿った補完的ルールで対応するが、日本の個人データが欧州へ移転された場合は、GDPRに沿ってどう取り扱われるかは感知しない、と言っているのと同じことだ。

そうでないというなら、日本政府はGDPRの解釈について回答できる必要がある。それができず欧州側に丸投げでは「平等」で「相互的」な十分性認定とは言えない。

このことに理不尽さを感じる日本の企業や組織がなぜ現れないのだろうか?

個人ブログ運営者がGDPR(欧州一般データ保護規則)に大騒ぎしている愚かさ加減

日本語の個人ブログ運用者が、Google Analyticsで閲覧者をトラッキングしているというので、手間をかけてGDPR(EU一般データ保護規則)対応しているが、物事の発生確率について常識的に考えよう。

GDPR違反に制裁金(administrative fines)を課すかどうかはEU各国にある監督機関(supervisory authority)が執行権を持つ。

世界中に無数にある個人ウェブサイトから、あなたのブログを狙い撃ちして、わざわざあなたに英語で少なくない分量の質問書を送信し、状況を詳細に調査し、制裁金を課すべきかどうか、課す場合には金額をいくらにするかを決めるために、あなたと何往復もやり取りすると、あなたは本気で信じているのだろうか。

監督機関は、そんなにヒマではない。

ご自身のブログがEUの監督機関に狙い撃ちされるのを心配して手間をかけるくらいなら、あなたの日常生活にはもっと心配する価値があり、もっと手間を掛ける必要のあることが山ほどあるはずだ。

EUの監督機関が調査するとすれば、最優先なのはEEA域内で一般的に使われている言語および通貨で、EEA域内の自然人に商品やサービスを提供するウェブサイトのうち、多額の制裁金を徴収できそうな大企業だ。

そこから規模やプライバシー侵害リスクの大きそうなウェブサイトで優先順位付けして調査して行くとして、それだけでも何年かかるか分からない。

日本は今年2018年中には欧州委員会から正式に個人データ域外移転に関する十分性認定を受けられる見込みだ。米国の保護貿易傾斜に対抗して欧州が日本とのEPAを急いだおかげの「棚ぼた」で、日本の十分性認定が前倒しになったためだ。

十分性認定を受ければ「何ら追加の安全措置の必要なく」欧州個人データを日本へ移転できる。

結果、あなたが心配すべきことは、あなたのブログが日本の国内法である個人情報保護法を遵守しているかどうかだ。

ところであなたは自分のブログのコメント欄やアンケートフォーム、Google Analyticsで収集している日本人の個人情報が、日本の個人情報保護法に違反していないかを真剣に考えたことがあるだろうか。

単なる一個人が自分のブログについて「GDPRだ!大変だ!」というこの空騒ぎは、いつになったら終わるんだろう。

追記)

ちなみにGDPRのRecital 23では、欧州の個人に商品またはサービスを有償無償にかかわらず提供している場合は、欧州域外の個人や企業にもGDPRはたしかに適用される。

しかし適用されるかどうかの判断基準も書かれており、欧州域内で一般的に使われている言語、または、通貨が使われており、明らかに欧州域内の個人向けだと分かる場合のみに適用される。

したがってRecital 23を読む限りでは日本語の個人ブログはGDPR適用外となる。

ただし、Recital 24に域外適用のもう一つの場合が書かれており、欧州域内個人の欧州域内での行動をモニタリング(monitoring)する場合は域外適用される。

しかしながら、何がモニター(monitor)にあたるかの判断基準も書かれている。欧州域内個人のインターネット上の行動を追跡し、欧州域内個人のプロファイリングをする場合、特に、その個人に関する特定の意思決定や、その個人の嗜好、行動、意見を分析・予測する場合にモニタリングとみなされる。

Google AnalyticsやAdsenseのCookieを心配している個人ブロガーの皆さんは、このRecital 24の域外適用のことを言っている。

書かれているとおり、単にCookieを収集するだけで放置している場合はモニタリングに当たらず、GDPR適用外となる。どうしても心配ならGoogle AlanyticsやAdsenseに限らず、アクセス分析やネット広告サービスはすべて削除する必要がある。

またグローバルIPで欧州からのアクセスを遮断すればよいという記事もたまに見かけるが、GDPRの条文のどこにも、グローバルIPで欧州からのアクセスを遮断しさえすればGDPRの域外適用を免除されるとは書かれていない。

その個人が欧州域内かどうかはインターネット上の技術で決まるわけではなく、物理的に、実際に、欧州域内に存在するかどうかで決まる、としかGDPRには書かれていない。

たとえば、欧州域内の個人がVPNを使って欧州域外の国のグローバルIPからアクセスしてきた場合も、欧州域内の個人がアクセスしてきたことになる。

グローバルIPだけで欧州かどうかを判断する方法ではGDPR適用を逃れることはできない。

また、個人でブログを運営する場合、技術力のある方々は自力でWordpressにプラグインを入れるなどの対応で、Cookie取得についてユーザの事前同意を取ることはできるだろう。

しかしITの知識がほぼない方々が、手軽に始められるブログサービスに乗っかって、そのサービスが自動でアクセス数集計をしてくれるとか、コメント欄があるとか、アンケート機能があるというケースの方が多いはずだ。たとえばアメブロのユーザなど。

個人ブログの運営者で必死になってCookie対策やグローバルIP制限(上述のようにこれは対策にならない)をしている方々は、欧州の監督機関が、例えばすべてのアメブロユーザを摘発しに来るというような事態を本気で信じているのだろうか。

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の設定画面でどうすれば提供元不明アプリのインストールを防止できるかとか、そうした情報はどうせ聴衆の頭に残らない。

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

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

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

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