<前の日記(2022年04月01日) 最新 編集

高木浩光@自宅の日記

目次 はじめに 連絡先:blog@takagi-hiromitsu.jp
訪問者数 本日: 116   昨日: 1259

2022年06月09日

競争政策が消費者の安全・詐欺被害耐性を破壊しに来た

内閣デジタル市場競争本部の「デジタル市場競争会議ワーキンググループ」が、「モバイル・エコシステムに関する 競争評価中間報告」 に対するパブリックコメントを募集している(今月10日23時59分まで)。これについては先月、ITmediaニュース「小寺信良のIT大作戦」で、「「iPhoneにサイドローディングさせろ」を国が言うのは妥当か」との記事が出ていて話題になっていた(はてブの反応スラドの反応)。

中間報告の内容は多岐にわたっており、全部を把握していないが、ざっと見ると、技術的に誤った理解を前提にし、ろくに調査することなく技術面を蔑ろにしている箇所が、チラホラある。会合の記録を見ると、会議は非公開で行われ、パブコメ開始までに議事録も出して来ない*1。委員に技術者はいないし、技術者からの意見聴取もしていないようだ。そのくせ、技術的な問題があればパブコメで意見がくるだろうという丸投げスタンスのようだ。

○成田審議官 (略)中間報告をまとめて外に出すことによって、それでパブコメもやりますし、そこでいろいろコメントをくださいねという言い方をしております。広告のときもそうでありましたけれども、中間報告の段階でそのプロセスをとろうとすると、いつまでも中間報告が出せなくなるという意味で、広い意味での関係者に広く問題意識を伝えて、広く意見を募っていくというプロセスを早い段階でやったほうがいいという意味で、今回、事前にこの案をプラットフォームと調整するということは我々のほうでは考えておりません。そういう前提の中で、先ほど御指摘のあったようなコミュニケーションのことをよく考えていく必要があるのかなと思ってございます。(略)

(略)

○増島議員 (略)ここはどうしても専門的なものになってしまうというのは、デジタル広告のときもそうだったのですけれども、仕方がないのかなと感じがしているところであります。

その結果、パブコメをかけて誰が回答をしてくれるのですかという話になると、回答をしてもらえる人たちというのは相当少なくなってくるように思うのですけれども、事柄の性質上これはやむを得ないとも感じているところであります。

具体的には、今我々として誰からコメントを欲しいと考えているのかということで言うと、例えばこれを出したときに、規模が小さい事業者からはあまり回答は期待できない。もしあるとすると、すごく大ざっぱな、ビッグテックの横暴はやめてほしい、そういう回答はあるのだと思うのですけれども、今回のレポートを全部ただしく消化したうえでの回答は基本的には考えにくいだろうということがまず一つ。

(略)それから、日本のデジタルの分野でそれなりの地位を占めている事業者ないし事業者団体が、自分たちのビジネスに影響が及びかねないところについて、大きな観点から何か意見してくるだろうということと、逆にビッグテックに煮え湯を飲まされているトピックについて、ここをもっとこうするべきだとか、これに賛成であるということを言ってくる。多分大きく言うと、そういうような分布になるのではないか、こんな感じがするのですね。

我々が世の中から欲しいコメントは基本的にそういうものでよかったのかどうかというところが、先ほど上野山委員がおっしゃったところの一つ、我々としての向き合い方ということなのではないかなと感じたところです。

例えば、消費者団体から、今回のトピックにつき、これをきちんと消化して、真意を酌んだコメントがもらえるような状態はあり得るのだろうかということを考えたときに、ふだん我々は消費者団体の方々といろいろな場面でお付き合いをしていますけれども、彼らの持っているエクスパタイズとの関係でもなかなか難しいところがあるのだろうなと感じておりまして、そこは彼らが勉強不足だとかリテラシーが足りないというよりは、扱っているトピックとの関係でどうしても限界というものがあるのではないか。逆に言うと、幾らこうした反応を欲しいセクターに答えてもらおうと思って書こうとしても、扱っているものの事柄上、そのようなプロダクトはつくりにくいのではないか、こういう感じがいたしました。

デジタル市場競争会議ワーキンググループ第34回議事録

これは甚だ面倒臭いが、私からは「サイドローディング」の部分についてだけ苦言を出しておこうと思う。

まず、「サイドローディング」という言葉は、Androidの方の用語のようだが、この中間報告では以下のように定義している。「OS事業者の提供するアプリストア以外のアプリストア」の利用も「サイドローディング」 に含めているようだ。(元のGoogleの定義(注16)では「ウェブサイトからダウンロード」の方だけのところ。)

7. アプリストアの拘束(Apple)

(1) 事実関係とそれを踏まえた課題と評価
1) 事実関係(サイドローディングの禁止)
○ iPhone向けのアプリは、Appleが運営するAppStoreでのみ配信されており、AppStore以外のアプリストアからアプリをダウンロードすること、又はウェブサイトから直接アプリをダウンロードすること(以下、OS事業者の提供するアプリストア以外のアプリストアやウェブサイトからダウンロードすることを総称して「サイドローディング」という。)についてはAppStoreのサービス開始以降、一切認められていない。

モバイル・エコシステムに関する 競争評価中間報告

中間報告が主張することは以下。法的に義務付けることが予定されている。

(3) 対応のオプションと主に御意見をいただきたい事項
1) 対応のオプション
上記のような競争上の懸念がある場合に、対応のオプションとして、以下のようなものが考えられるか。

オプションA:サイドローディングを許容する義務

○現状、iPhoneにはAppStoreのみがプリインストールされ、AppStoreがデフォルトのアプリストアとして設定されており、かつ、AppStore以外のアプリ配信方法が認められていない。その結果、全てのユーザーがAppStoreでiOS用アプリをダウンロードしている。

○その結果として、競争上の懸念が生じていると認められるときは、iPhoneユーザーがAppStore以外のアプリストアを利用できるようにするとともに、ウェブサイトからのアプリの直接ダウンロードも可能となるようにすることで、iOS用アプリの配信において競争が生じるようにすることが考えられる。

○そこで、一定規模以上のOSを提供する事業者がアプリストアを提供する場合には、ユーザーが
サードパーティのアプリストアをインストールでき、それをデフォルトとして選択できるようにする
ブラウザを使ってアプリを直接ダウンロードできるようにする
プリインストールされているアプリストアを非表示又はアンインストールできるようにする
義務を課す規律を導入することが考えられるのではないか。

○また、上記義務を課すとともに、サイドローディングを認めた場合でも、プライバシーやセキュリティを担保するための何らかの手段を検討することも考えられるのではないか。例えば、他のアプリストアの選択肢を排除するのではなく、当該他のアプリストアについても、自社のアプリストアにおけるアプリ審査と同水準の審査を実施することを担保する何らかの仕組み(例えば、関係事業者等による認証制度、ガイドライン等)を設けた上で、当該他のアプリストアのサービス提供を許容することも考えられるのではないか。

モバイル・エコシステムに関する 競争評価中間報告

「オプションA」とあるが、Bはなく、もうこれ一択になっている。

まあ、競争がないから手数料が高止まりしているという話は理解できるし、競争上の問題があることは、10年前にスマホが普及し始めた時にも、総務省の「スマートフォンプライバシーイニシアティブ」で、アプリストアの選択制は論点には挙がったし、もっと言えば、20年前のガラケー全盛期にも、iモードの公式メニューの運営や公式サイトの認定がdocomo独占なのがけしからんという業界の声があって、公式メニューを利用者が選択できるようにするとか、そもそも水平分業にするのだという計画が、総務省で検討されていて、頓挫した歴史がある*2

アプリストアの選択制は、まあ、やってみてもいいんじゃないの? でもやるところあるの? という感じだ。 選べるようになったとして、アプリ開発者側は複数のアプリストアに出品せざるを得なくなってかえって高コストになったりしない? といった疑問は湧く。(そういう話は10年前に済んでいたのではなかったのか?)

しかし、今回のデジタル市場競争本部の動きはそれに止まらない。「ウェブサイトからのアプリの直接ダウンロードも可能となるようにする」「ブラウザを使ってアプリを直接ダウンロードできるようにする」とも主張しているのだ。

Androidがまさにそれを可能にする機能を設けているので、まあ、それもやったらいいんじゃない?という声は、エンジニア界隈にはありそうだ。自己責任で選べるようになってたらいいじゃないの?というわけだ。

しかし、さらに、今回のデジタル市場競争本部の動きはそれに止まらない。Androidの方のサイドローディングについても、以下のように法的義務付けが計画されているのだ。

8.サイドローディングの制限(Google)
(1) 事実関係とそれを踏まえた課題と評価
1) 事実関係
(略)

(サイドローディング時にユーザーが実行する手順)
○Android端末は、初期設定ではサイドローディングは無効にされており、ユーザーが設定を変更することでサイドローディングが有効になる。
(略)

(サイドローディング時の警告表示や手順がサイドローディングを躊躇わせるおそれ)
(略)

○ しかしながら、「セキュリティ上の理由から、・・・インストールすることはできません。」、「お使いのデバイスに悪影響を与える可能性があります。」、「電話と個人データが攻撃を受けやすくなります。」などの表示がなされており、そのような表示に接したデバイスの仕組み等に詳しくないユーザー等は、セキュリティ上のリスクを恐れてサイドローディングを躊躇するおそれが高いと考えられる。

○ また、上記の警告は、ダウンロードしたアプリが有害なものかどうかをスキャンするGooglePlayProtect(GPP)によってPHAとして検出されていないアプリである場合でも表示される点では、注意喚起としては過剰であるとも考えられる

○ また、Android端末でアプリ・デベロッパのアプリをサイドローディングする手順については、GooglePlayからのダウンロードの場合と比較して手順が多く、それも、サイドローディングを使いにくくする方向に作用している懸念もある。

○ APKファイルをダウンロードするときは、さらにダウンロードフォルダに移動するといった追加的手順も必要になるとされており、以上の懸念は強まる。

○ 実際、以下の具体的な指摘がなされているところ。
サイドローディングをするに当たってはセキュリティ設定の変更が必要、警告の表示が仰々しい、警告に付された説明が難しいといったこともあり、ユーザーからするとそこまでしてアプリをサイドローディングしようとはならない。デベロッパの開発したアプリストアを利用する人はいない。
・サイドローディングの際には、警告が表示され、インストールされるまでの手順も多く、不安が煽られていることもあり、人々はサイドローディングのアプリはFraud等のリスクが大きく、Google Playは安全性があると考えている。
・サイドローディングの際の警告の表示や、煩雑な手続は不当だと思う。セキュリティ等の警告を出している中には既に信頼できるアプリであることは分かっているものも含まれるはずである。サイドローディングに対してそうした煩雑なプロセスを取らせることで、アプリストアからインストールさせるようにしている。AppleやGoogleの主張は、AppStoreやGooglePlayStoreを経由することでさらに安全になるというものだが、そうしたアプリストアの審査を経たところでより安全になるというわけではない。要するに、警告のメッセージはアプリストア外でのサイドローディングを思いとどまらせることに意味がある
・APKファイルのダウンロードは可能だが、APKファイルを一旦フォルダにダウンロードし、当該フォルダを開いてアプリをインストールするなどの手順が増え、また、その際にも警告が表示されるため、実際にはアプリストア経由の方がダウンロードしやすい
・アプリをサイドローディングする場合は、設定の変更も含めで15段階程度の手順が必要となるのに対し、GooglePlayでアプリをダウンロードする場合は少ない手順で済む。それでも敢えてサイドローディングを選ぶ人がいるかは疑問である18

(略)

(2) 現時点での競争上の評価
(サイドローディングの抑制)

(略)

○ しかし、警告の表示方法(表示頻度、警告の際の文字のフォントサイズ、警告の文言、メッセージの処理方法等)次第では、ユーザーにセキュリティ・リスクを過大評価させ、サイドローディングに対する警戒心を持たせて思いとどまらせるおそれがあり、結果的にサイドローディングを実質的に抑制する効果が生じることにもなり得る。

(略)

○ 実際にも、前記のとおり、サイドローディングがGooglePlayからのダウンロードと比べて大幅に少ないとする指摘がある。Googleからは、アプリの全ダウンロード件数に占めるサイドローディングの割合について、サイドローディングが低調であるという指摘に反証するデータが示されていない。

○ 以上のことから、警告の表示や手順などの要因が、ユーザーにサイドローディングを思いとどまらせているという疑念は払しょくできないのではないか。

(アプリ配信分野における事実上の独占による影響)
○ サイドローディングが抑制されれば、Android用アプリの配信は事実上、GooglePlayが専ら利用され、Android用アプリの配信分野における競争が機能し難い状態になり、その結果、Appleによるアプリストア拘束と同様に、手数料の競争価格より高い水準での設定、アプリストアのサービス面における競争による改善の阻害などの競争上の懸念が生じるおそれがあると考えられる。

○ また、ブラウザを使ったウェブ・サービスがOS環境に依存しないことに鑑みれば、ブラウザを使ったアプリの直接ダウンロードが警告表示などによって躊躇されることにより、ブラウザからのサイドローディングがGooglePlayからのダウンロードに対して競争上不利になることで、モバイルOS間の競争が減少するおそれもある。

(略)

1) 対応のオプション
上記のような競争上の懸念がある場合に、対応のオプションとして、以下のようなものが考えられるか。
(オプションA:サイドローディングによるアプリ配信を制限する行為の禁止)

○ サイドローディングによるアプリの配信を事実上制限するような警告表示、複雑な手順等の行為一般を禁止する必要があるのではないか。また、エンドユーザーの判断力を低下させたり、誤認させるような表記やデザインなど多様な行為によって、サイドローディングが事実上制限されることもあることから、サイドローディングに関してユーザーにとって不利な決定に誘導するような行為も禁止する必要があるのではないか。

○ そこで、一定規模以上のOSを提供する事業者がアプリストアを提供する場合には、サイドローディングによるアプリの配信を制限することを禁止する規律を導入することが考えられるのではないか。

モバイル・エコシステムに関する 競争評価中間報告

またしても「オプションA」しかない。

つまり、警告や余分なステップなしに任意のWebサイトからアプリをインストールできるようにしろというのである。エンジニア的発想からすれば、自己責任でセキュリティを解除して独自アプリを入れられたら楽しいと思うかもしれないが、これはそういう話ではない。これは、高齢者等の情報弱者を含めた一般の利用者に対して、公式ストアからの利用と「平等に」野良アプリも利用できるようにしろ、という話になっている。

それもそのはず、これは競争政策の話だからだ。どのストアも一切優遇されることなく任意に選べるべき、ということになるし、狭義のサイドダウンロードも、全く確認なしに即動くようにしろ、ということになる。これはトンデモだ。

「煩雑なプロセスを取らせることで、アプリストアからインストールさせるようにしている。」「警告のメッセージはアプリストア外でのサイドローディングを思いとどまらせることに意味がある。」のあたりに至っては、もはや陰謀論の世界。こんなのを真に受けた中間報告をよくもまあ委員は素通ししたものだ。恥を知った方がいいよ。

セキュリティをいったいどう心得てるのか? というと、どうもこの会議は以下のような認識らしい。

(サイドローディングの禁止がデバイスのセキュリティ確保に資する程度)
(略)

○ デベロッパの中には、iOSデバイスのセキュリティは、ハードウェアに組み込まれた数多くのセキュリティ対策(データの暗号化、ファイアーウォール、アンチウイルス等)と、アプリによるモバイル・デバイスのリソースへのアクセスを制限するサンドボックス・モデルによって実現されており、AppStore審査では、追加のセキュリティ機能はほとんどないと述べる者もいる。また、以下の指摘もなされている。

(略)
・Appleはプライバシーやセキュリティを理由にあげることがよくあるが、こういってしまえば、プライバシーやセキュリティを保護する必要性については否定できず、どういう点に問題があり得るかは技術的専門性やAppleのデバイスの詳細等も分からないと何とも言えず、それ以上突っ込めなくなるので、便利な口実になっているという印象を受ける。
(略)

○ アプリストア拘束が、セキュリティ、プライバシーの問題にどの程度寄与しているか疑問の声がある中で、アプリストアの拘束が様々な懸念や競争上の懸念を生じさせている状況にあることに鑑みれば、同拘束は、総合的にみて、弊害(コスト、リスク)の方が大きい可能性があるのではないか。

(サイドローディングが認容されているMacデバイスとの違い)
○ 同じAppleのコンピューティング・デバイスであっても、iPhoneではサイドローディングが禁じられている一方で、Macではサイドローディングを自由にすることができるようになっている

○ セキュリティを確保する必要性は、MacパソコンにもiPhoneにもあると考えられるが、サイドローディングが可能か否かについて、両デバイス間でここまで完全なる相違があることに正当な理由があるのかという疑問があるとの指摘もある。

モバイル・エコシステムに関する 競争評価中間報告

いやいやいや、あのねえ、 今やmacOSも主要なアプリはApp Storeから購入だし、野良でダウンロードしたものもそう簡単には起動できないようになってるんだよ。

そもそもMacでアプリを頻繁にインストールするものじゃない。基本的な作業環境を整えたら滅多に追加アプリを入れないというのが普通。それに対して、スマホのアプリ場合は、Webサイトとの中間に位置する。つまり、Webサイトは、SNSからのジャンプで初めて訪れるサイトも毎日閲覧するわけだけども、これはWebの機能が限定されていてどんな怪しいサイトを閲覧しても安全なように仕様が設計されているのに対して、それでは使える機能が少なすぎるからということで、スマホアプリという中間のものが登場したわけだ。なので、スマホアプリはWebサイトより危険なものであるし、Macの扱いと違って、わりと頻繁に新しいアプリをインストールする生活を送ることになる。ここにどうやって安心を確保するのかだ。

中間報告は、「リソースへのアクセスを制限するサンドボックス・モデルによって実現されており」というが、permissionモデルで足りると言うのであろうか。ボタン一発押したら即アウトなアプリが蔓延しても、高齢者にボタンを押すのは自己責任だと君らは言うのか?

今更「「署名済みActiveXコントロールのダウンロード」を有効にしてください」と同じ過ちを繰り返すの? もう17年前だよこれ? *3

何がどう危険なのか全く調べてないじゃないか。いちからか?いちからせつめいしないとだめか? めんどくさいわ。なんでこんな陰謀論報告書にいちいち我々が手弁当で意見を書いて出さないといけないんだ。💢💢💢

とりあえず、パブコメが終わったら、近頃のワームの実態を追いかけているリサーチャの証言や、警察庁の話を聞くべきだろう。

*1 パブコメが始まってだいぶ経ってから第34回の議事録だけ出てきた。

*2 この件については2007年6月30日の日記に書いてある。

*3 ちなみに、今日、これをやれと指示するのは、政府統一基準の遵守事項6.3.1(2)(a)(オ)「情報セキュリティ水準を低下させる設定変更を、OSやソフトウェア等の利用者に要求することがないよう……」違反である。


<前の日記(2022年04月01日) 最新 編集

最近のタイトル

2022年06月09日

2022年04月01日

2022年01月19日

2021年12月26日

2021年10月06日

2021年08月23日

2021年07月12日

2020年09月14日

2020年08月01日

2019年10月05日

2019年08月03日

2019年07月08日

2019年06月25日

2019年06月09日

2019年05月19日

2019年05月12日

2019年03月19日

2019年03月16日

2019年03月09日

2019年03月07日

2019年02月19日

2019年02月11日

2018年12月26日

2018年10月31日

2018年06月17日

2018年06月10日

2018年05月19日

2018年05月04日

2018年03月07日

2017年12月29日

2017年10月29日

2017年10月22日

2017年07月22日

2017年06月04日

2017年05月13日

2017年05月05日

2017年04月08日

2017年03月10日

2017年03月05日

2017年02月18日

2017年01月08日

2017年01月04日

2016年12月30日

2016年12月04日

2016年11月29日

2016年11月23日

2016年11月05日

2016年10月25日

2016年10月10日

2016年08月23日

2016年07月23日

2016年07月16日

2016年07月02日

2016年06月12日

2016年06月03日

2016年04月23日

2016年04月06日

2016年03月27日

2016年03月14日

2016年03月06日

2016年02月24日

2016年02月20日

2016年02月11日

2016年02月05日

2016年01月31日

2015年12月12日

2015年12月06日

2015年11月23日

2015年11月21日

2015年11月07日

2015年10月20日

2015年07月02日

2015年06月14日

2015年03月15日

2015年03月10日

2015年03月08日

2015年01月05日

2014年12月27日

2014年11月12日

2014年09月07日

2014年07月18日

2014年04月23日

2014年04月22日

2000|01|
2003|05|06|07|08|09|10|11|12|
2004|01|02|03|04|05|06|07|08|09|10|11|12|
2005|01|02|03|04|05|06|07|08|09|10|11|12|
2006|01|02|03|04|05|06|07|08|09|10|11|12|
2007|01|02|03|04|05|06|07|08|09|10|11|12|
2008|01|02|03|04|05|06|07|08|09|10|11|12|
2009|01|02|03|05|06|07|08|09|10|11|12|
2010|01|02|03|04|05|06|07|08|09|10|11|12|
2011|01|02|03|05|06|07|08|09|10|11|12|
2012|02|03|04|05|06|07|08|09|
2013|01|02|03|04|05|06|07|
2014|01|04|07|09|11|12|
2015|01|03|06|07|10|11|12|
2016|01|02|03|04|06|07|08|10|11|12|
2017|01|02|03|04|05|06|07|10|12|
2018|03|05|06|10|12|
2019|02|03|05|06|07|08|10|
2020|08|09|
2021|07|08|10|12|
2022|01|04|06|
<前の日記(2022年04月01日) 最新 編集