これは

Apple/Googleは、COVID-19対策として、濃厚暴露通知の仕組みを提供しています。この仕組みは、それぞれの国の健康保健を担当する省庁がアプリケーションを開発して、そのアプリが1国あたり1アプリのみ承認されて、活用されています。

その濃厚暴露のアプリケーションのインストール率を、iOSデバイスで簡易に見る方法の紹介です。

手順

iPhone/iPad touch/iPadなどの、iOSデバイスを用意します。iOSのバージョンは、今の時点で最新iOSは13.5ですが、動いているiOSのバージョンが"13.5よりも古いもの"を使います。iOS13.5以降では、濃厚暴露のBLEアドバタイジングパケットは、iOSアプリケーションからは見えなくなります。

用意するもの: iOS13.5以前のiOSデバイス(iPhone/ iPod touch / iPadなど)。iOS13.5以降では、この方法は使えません。

まず、nRF Connectというアプリケーションをインストールします。これはBLEのSoC開発で有名なNordic Semi.社が提供している、BLEデバイス開発によく使われる無償iOSアプリケーションです。

https://apps.apple.com/jp/app/nrf-connect/id1054362403

まずアプリケーションを起動します。この状態で、画面上部のナビテーションの右ボタンにある"Scan"ボタンを押せば、BLEアドバタイジングパケットの収集が始まります。

この収集は、“Stop Scan"を押せば停止します。またアプリの設定にある収集時間が経過すれば、自動的にスキャンは停止します。収集時間は、画面下右にある設定画面で変更できます。デフォルト値は2分ですから、デフォルト値のまま使えばいいでしょう。

“スキャン"を押すと、濃厚曝露のパケット以外にも多数のBLEアドバタジングパケットが表示されます。目的とするパケットがあまりに多いと見づらいので、フィルタリングを設定します。

画面上部に"Filtering Active"というテキスト表示が出ているはずです。その右にある上向き矢印のボタンを押します。フィルタ設定が出てくるので、“Services"という項目を設定します。プルダウン入力を押すと、いくつか選択が出てきますから"Exposure Notification Service"を選択します。そして、このフィルタリングが有効になるように、その右にあるトグルスイッチを、オンにします。

もしも"Exposure Notification Service”という項目が表示されていない場合は、どこか濃厚暴露のパケットが出ているところで、スキャンをして、そういうサービスがあるんだよとアプリに検出させてみてください。

フィルタリングを有効にした画面が、これになります。

スキャンしている間、濃厚暴露のパケットが検出した順でテーブル表示に出てきます。画面上の数値(この画像だと、4/89)は、前の数値（画像だと4)が検出した濃厚暴露の数を、後ろの数値(89)は、多分検出したBLEパケットの総数を表示しています(もしかしたら、濃厚暴露のパケットは引き算してあるのかもしれないけど、わかんないです)

たいていのスマートホンは、BLEアドバタイジングをしているので、この89がスマートホンの台数、そして4つは濃厚暴露のアプリが起動していて周囲にアドバタイジングをしていると、わかります。

仕組み

濃厚暴露は、BLEアドバタイジングを利用した仕組みです。あとは、省略。

濃厚暴露のパケットは、200~300ミリ秒周期と、かなりの頻度で送信されていますから、道端に立ってモニタリングしていれば、通過する車それぞれからのパケットを拾ってカウントできます。

注意点

BLEアドバタイジングをするのは、スマホだけではありません。ウエアラブル機器やパソコンあるいはカーナビ、場合によってはマウスやペンシルなどの周辺機器も、アドバタイジングをします。そのため、デバイスの総数がスマートホンとは限らず、見かけ多めに出てしまうかもしれません。

スキャン時間をやたらと長くすると、本当の端末の数と、このアプリの表示の数が、ズレてきます。2分くらいスキャンすれば、スマートホンと濃厚暴露の検出には、もう十分です。

スマートホンは、セキュリティとプライバシーを保護するために、BLEアドバタイジングのMACアドレスを10分か15分くらいの周期で変更します。ですから例えば30分もスキャンすれば、端末が一台しかなくても、アドレスが変更するたびに異なる発信源としてカウントしてしまうので、アプリでは三台くらいに見えてしまいます。

また、濃厚曝露通知のアドバタイジングパケットも、プライバシー保護のために、同じようにパケットの内容を変更します。そのために、長時間スキャンをしていると、見かけで濃厚暴露のアプリをインストールしている端末数が、増えていきます。

2020年7月10日に、いくつかのiOSアプリケーションで起動時にクラッシュする不具合が発生して、話題になりまた騒動になっていました。

Facebook SDKとは?

Facebookが提供する、アプリケーションに組み込んで利用するライブラリです。いくつかのライブラリがありますが、Facebook SDKは、 https://developers.facebook.com/docs/app-events/overview

アプリ広告の成果を追跡したり、効果的なシェア機能を実装したり、Facebookを使ってアプリへのログインを促す、最も簡単な方法です。

というものです。

アプリのイベントを記録して、Facebookが提供する環境でログ収集と分析ができるようです。使ったことないので、よく知らないのですが。 ユーザの行動や購買記録の収集のみならず、カスタムなイベントを設定して収集できるようで、汎用のログ収集手段としても使われるのでしょう、たぶん。

イッシューはお祭り騒ぎ

Facebook開発者サイト https://developers.facebook.com/support/bugs/329763701368293/ の不具合の報告では、クラッシュしたアプリのスタックが報告されてファイリングされる一方で、囃立てるコメントが大量について、お祭り騒ぎになっていたようです。

Facebook SDKのソースコード はGithubに公開されています。Githubでもイッシューの登録に続いて、お祭り騒ぎのコメントがたくさんついていました。 https://github.com/facebook/facebook-ios-sdk/issues/1431

原因とその修正

原因は、SDKの実装がサーバーからのレスポンスを暗黙的に扱っていたこと、そしてサーバレスポンスの変化による例外発生です。

その騒動の原因は、Facebook SDKにある、制限されるデータのフィルタリング機能が、アプリ起動時にFacebookのサーバーからセンシティブとして検出されたイベントとパラメータを読み込みます。ここが、サーバ側からのレスポンスをチェックしていなかったために、サーバ側の変更でデータ構造が変化すると、例外を発生してしまうというものです。Objective-Cで、よくやっちゃうやつですね。

修正差分は、https://github.com/facebook/facebook-ios-sdk/commit/b1ec939cb994dbcf85b495ec747753289271f105 にあります。サーバから受け取ったレスポンスは辞書データとして渡されます。その辞書で特定のキーで値があるか、なければnil扱いとする、そのような変更が入っています。

この修正部分に対するテストコード https://github.com/facebook/facebook-ios-sdk/commit/64cc769c8bad9ffa25c60085367ff08c3492a3e2 。

イッシューにあったスタックにある、例外の発生箇所は、FBSDKEventDeactivationManager.m 65行目 あたりです。コード自体は、サーバからデータを取得して処理するだけのコードです。

https://github.com/facebook/facebook-ios-sdk/blame/a6fd9f03f042a9f999b81a824c0b09917beeb927/FBSDKCoreKit/FBSDKCoreKit/AppEvents/Internal/EventDeactivation/FBSDKEventDeactivationManager.m

Blameで見ると11日前、6月末に変更が入っていますが、その変更自体は、サーバからのデータ取得をアプリ起動中1回に制限するだけのものなので、このサーバーからデータを取得する処理自体は、(めんどいから調べていませんけど)ずっと以前からあったのでしょう。

https://github.com/facebook/facebook-ios-sdk/commit/a6fd9f03f042a9f999b81a824c0b09917beeb927

影響

このSDKを組み込んでいれば、アプリが起動時にクラッシュするという不具合ですらから、このSDKを使っていれば影響します。ソーシャルメディアやソーシャルゲーム、スマートキー、ドローンの操縦アプリなど、いくつものアプリケーションが影響を受けたようです。

スマートキーのアプリが起動しなければ、自宅に入れなくなりそうです。ドローンでは、操縦中にアプリがクラッシュして起動しないためドローンを喪失する方もいたようです

対策?

アプリの利用者が取れる対策は、ありません。Facebookのサーバレスポンスの変更が原因でしょうから、機内モードで使えばアプリが動く可能性はあります。ですが、アプリの起動後にネットワークをオンにすれば、いつかはこの部分がサーバにアクセスしてクラッシュするでしょう。ネットワークへの接続がなくても問題がないアプリは、とても少ないでしょうから、避けようがないとしか言いようがありません。

アプリ開発者が行うべきことは、更新されたSDKでビルドして、アプリケーションを更新することです。今はおそらくFacebookのサーバーが、クラッシュを起こさないレスポンスを返しているのでしょう。急ぐことはないかもしれませんが、アプリケーションの適切な更新時に、この不具合への修正が盛り込まれたSDKに更新すべきでしょう。

このようなことが今後起きないように、アプリケーション開発者が取れる根本的な対策は、ありません。SDKの内容を個別にレビューするのは、Facebookに雇用された開発者の仕事です。そんな仕事ができるなら、Facebookに雇用されるだけでしょう。ただ、サーバレスポンスの変更で容易にクラッシュするという部分が他にないのかなど、徹底的なレビュー祭りが社内の開発者で行われるのか、また不具合がレポートされたら動けばいいやとするのかは、今後の信頼感に繋がるのかなという気がします。

この世の中の色々なものがネットワークで繋がった時代は、地球のどこかにあるサーバの振る舞いがちょっと変わると、自宅にすら入れなくなる、よくある体験がよくある出来事として体験されたと思います。自分が所有しているはずの何かは、その制御権をネットワークを通じて他に渡している状態なので、そんなことも起きるのでしょう。

読んでみる本

IoTという単語で大学で長年提唱と研究をされている方の本。IoTとは、ユビキタスであり、どこでもコンピューター、超機能分散システムであるという提案から、次の社会のあり方を提案する感じ。

閉じたネットワークから開かれたオープンなネットワークとは言っているけど、その実は、そのネットワークをつかる製品群やサービス自体は、有象無象の正体不明のものが入り込むというものではなく、統制が取れた1つの管理社会みたいなイメージで書かれている印象を受ける。きっと、日本であれば、ドコモ1社があれば、あとは価格競争のために2社あればいいけど、別にドコモがあればいいよね、みたいな世界観が暗黙の前提にあるのだろう。

科学とは、必ず反論して検証して汎用化するものであり、検証できるものだから、科学であろう。未来に対してこうなるという福音を提示するのであれば、それは未来という結果を固定する、ただの出来の悪い宗教だ。21世紀になった現代には、勘違いするだけで、読むだけ害悪だと思う。

スマートホンと連携する機能がある腕時計を、商品企画し実際に会社を立ち上げて販売している方が書いた本。

自身の企画の道筋と製品化までの流れを端的に書いていて、とても実践的であり、また成功したプロダクトを出して会社を立ち上げて販売流通をしている実績が背景にあると思えば、言葉に宿る説得力も強い。

一般的なハードウェアを企画し販売すると言う、また前例があまりないと言う新規商品ジャンルを切り開くと言う視点で、一つ一つの事柄は読んでいて当たり前のことと思うが、基本が大切だと思えば、実際に始める前に、また動いている時も要所要所で、この本を読み返して、自分たちが行っていることが具体的に何かを一歩一歩確かめるそういったチェックシートとして活用もできそうで、実践する方にとっての価値は非常に高そうだ。

今のネットワーク技術があれば、車産業に関わる会社がその内部で、どんな変化ができるかといった話である。つまり、車に関わる製造販売流通のそれぞれの企業の内側の話であり、消費者にとって新たな価値があるとかそういった話ではない。企業活動は、安く作り、高く売る、大量に、それだけである。それのための設計物流を、今時の技術で練り直すと、という本である。

どんな技術やテーマを持ってこようとも、とどのつまりは、企業間の競争の話でしかない。会社に属しているならば、戦略から他の会社より生産性が劣れば、存続の危機にすら繋がるだろうから、それは競争がもたらす暴力的なまでの利益と損失を背景にした、企業にとっての恐怖と希望を原動力にした、脅しでしかない。

今時の、企業にとっては暴力的な競争にとって遅れまいと言うための情報収集としての価値はあるだろうが、企業の中での改革でしかないので面白みは無い。

インターフェースデザインで、コンピューターの中にある寝たのでだが、人の体や活動にどう結びつけるのかと言うどこに焦点がある本である。対象はデザイナーやエンジニア。 読んでいて興味深いし、面白さも感じるのだけど、内容をまとめようとすれば、正直、私には何が何やら分りません。

何をするかも決まっていない状態での、商品企画の立ち上げで、なんとなく集められた/集まった人たちが、お互いを知る時に、例えば、デザイナーやエンジニアの方が初めて会ったときに、なんとなくスマートフォンと連携する何かを作りたいなぁとか考えているときに、一緒に行こうこの本を読んでみるその体験を通じてお互いを押したりすると言う、そういうネタの使い方がいいんじゃないかなぁと思います。

後はIoTの技術を紹介した本とかがいっぱいある。それ自体はいっぱいあるので読んでいけばいい。

感想

ザ・インターネットというものは、実在していて、そのおかげで、引越しても回線契約をすれば世界のどこかにあるサーバを通じてサービスを受けられるし、スマートホンであれば電波が届くところならば、(物流がなければ、物は届かないだろうけど)どこからでもサービスにアクセスできる。

IoTという単語を冠した、本をざっと読むと、形ある物に軸足がある。“インターネット"という単語を入れておきながら、その語っていることは、消費者から見れば、その会社の製品を買えばサービスに参加できるという、ただの購買とそのサービス利用に過ぎない。それは勘違いだろう。

ものを購入することでサービスを利用する、つまり参加させてあげるというのが最初から組み込まれている。このものはインターネットを利用したまた、商品サービスであってそれ以外のものではないと言うことだ。また企業の内部の効率について言及したものの、他社に対して生産性を取るようなことになってはいけないと言う、暴力的な脅しであり、それが実際に生産力を上げるかどうかと言うのはここの会社の経理の判断であろう。非常に暴力的である。

インターネットの利点は、インターネットプロトコルという形のない取り決めとしての規格があり、それをみんなで参加して、みんなで利用している、1つの場であろう。2つあってはならない。なぜなら、分断は、サービスがそこにいけば利用できるという、いわば市場の機能を失わせるだろうから。そのインターネットいう世界には、事業者としては、そのネットワークを実装したソフトウェアやハードウェアの設計製造販売で参加もできれば、そのネットワークを流通として活用してサービス提供もできる。

iOS、Flutter、Ionic(Angular)それぞれのサンプルアプリケーションを、iOSネイティブアプリとしてリリースビルドして、実機のアプリサイズを確認してみました。

ソースコード は https://github.com/reinforce-lab/ios-ionic-flutter-helloworld-size-comparison にあります。

実機はiPhone Xs、ビルド環境は、Xcode 12 beta (12A6159), iOS14.0 (beta1)です。 それぞれリリースビルドで、実機にアプリを転送して、設定アプリのストレージから、アプリサイズを確認した。

• iOS 新規作成プロジェクト hello world app: 197kB
• Ionic 6.10.1: 93.5MB
• Flutter 1.17.5: 66.4MB

マルチ/クロスプラットホーム開発環境は、実行に必要なライブラリやリソースファイルを全てアプリケーションにバンドする他ありません。 本来はここから、バンドルされているリソースの種類と大きさを列挙して、可能であれば使用していないリソースをバンドルさせないようにしてサイズの削減効果を評価すべきなのでしょう。 ですが、依存関係の解決は、ソフトウェア開発環境の基本的な仕組みであり、個別で末端のアプリでごちゃごちゃするようなものには思えません。 やる前から決めつけるのはどうかとは思いますが、やったとしても、結果が出るようなものでもなく、結果が出ても本家にそのビルド工夫をフィードバックしないと、新規アプリごとに同じ作業が発生するだけなど、どこまでもめんどくさいだけでしょう。

画面を1つ表示するだけのアプリケーションであっても、結構なサイズになるのだなと雑な感想を持ったくらいです。

What’s new in location https://developer.apple.com/videos/play/wwdc2020/10660

CoreLocationの、ユーザ許可がiOS14で変わります。プライバシーの保護のために、位置情報の利用にはこれまでも考慮が重ねられてきましたが、iOS14ではさらに、利用者に正確な位置情報を要求した時に、利用者が低精度の位置情報利用を選択して許可できるようになります。

位置情報利用のダイアログに、位置情報を正確/低精度を切り替えるボタンが表示されて、ユーザはそれで切り替えができます。最初から低精度な位置情報を要求している場合には、このボタンは表示されません。

アプリケーションが、本当に正確な位置情報を必要とするときは、一時的に正確な位置情報を要求するなど、アプリの目的に合わせた位置情報取得の実装が必要になります。また、この位置情報の利用許可は、WatchアプリとiPhoneアプリ間で、同期します。Watchのコンパニオンアプリで位置情報の利用を許可すれば、iPhoneの本体アプリでもその許可が有効になります。

低精度の位置情報は、円の領域で与えられます。その中央にユーザがいるわけではありません。位置情報は、利用者の真の位置情報にノイズを加えたものではありません。その利用者は、その円のどこかに入っている、という程度の情報です。

例えば、車で移動しているとき、円の領域のなかを利用者が移動していき、円の縁にくれば、その円の領域は更新されて、次に利用者がいるだろう領域を示します。

低精度の位置情報で、Visit APIでバックグラウンド動作をするときは、移動がなければ通知はなく、移動があるときは1時間に4回程度の通知がきます。Visit APIは、正確な位置情報取得時でも、低精度な取得時でも、位置に入った時刻それ自体は、訪れた時刻が通知されます。低精度だからと言って、時間まで低精度になるわけではありません。

ビーコン及びそのほかの領域モニタリングが、.reducedAccurary　では無効になります。

AppClipsではalwaysの位置情報は使えない。1日有効です。

Widgetでは、info.plistにNSWidgetWantsLocationを含めます。