ログフリー VPN(Virtual private network)を更新しました。
PHP の $_SESSIONの値がNULLになる場合の解決方法
PHPで二重処理を回避するためにsession_start() という関数がある。 これは、session_start();を呼び出して一度セッションを開始すると、
（１）一定時間、セッションを保つ
（２）session_destroy()が呼ばれるまで、$_SESSION[ ]変数の値を保持する。
という機能を持っている。 更に、session_destroy()が呼ばれると、ブラウザのバックでは戻ることが出来なくなる。
OISEYER のホームページに新しいプライバシーポリシーをアップロードして、参照できるようにした。更に新しいプライバシーポリシーには、
と呼ばれるプライバシーに関する法律に基づいた要求を送ることができる。
このフォームの送信で session_start()を利用して、フォームを記述した。 自宅のWebサーバ + php8.3 で動作確認してからWebホスティングの該当場所にアップロードした。
アップロードしたフォームで入力して送信すると、振る舞いがおかしい。自宅のサーバでの振る舞いと異なる。 そこで、PHPの変数を va_dump で調べてみた。 すると、セッションで保持している $_SESSION[ ] で定義している変数の値がNULLになっている。 何故NULLになるのか全くわからない。 そこで、googleで「HP の $_SESSIONの値がNULLになる」で調べてみた。 すると、AIが
考えられる原因と確認事項
- `session_start()`が実行されていない
- セッションの有効期限切れ:
- 意図しないセッション変数の削除:
- セッション変数の上書き
- null値の判定:
との結果がでたが、当てはまらない。 また複数の人のブログでは、
session_start()のファイル内の位置について言及しており、<?php の次に置かなければsession_start()が失敗して変数が消えてしまうらしい。また、他のブログには、<?php から複数の改行があるだけでもうまく行かないとの言及があった。しかし、どちらの場合もこちらの状況には当てはまらない。
そこで、セッションのエラーを見ることにした。何らかのエラーがあれば、それで値が消える可能があると思って、エラーログを取るようにした。まず、PHPコード
ini_set('log_errors', 1);
ini_set('error_log', 'php_session_error.log');
を書き込んで、php.ini に
allow_log = ~/php-errors.log
を追加した。 これでエラー見ることにした。対象のページを開くと、エラーが出力される。 その内容は
[02-Oct-2025 00:08:11 UTC] PHP Warning: session_start(): Session cannot be started after headers have already been sent in ...
02-Oct-2025 00:08:11 UTC] PHP Warning: Undefined array key "SessionID" in .,.
02-Oct-2025 00:08:14 UTC] PHP Warning: session_start(): Session cannot be started after headers have already been sent in ...
02-Oct-2025 00:08:14 UTC] PHP Warning: Undefined global variable $_SESSION in ...
02-Oct-2025 00:08:14 UTC] PHP Warning: Trying to access array offset on null in ...
というエラーが記録された。 一番最初の行は、既にセッションを開始しているので、スタートできないと言うもの。 これは、以前のセッションが正しく終了していないので当然でると思う。
二行目、SessionIDというアレーのキーが定義されていない。三行目も一行目と同じで
セッションが開始できない旨。これは、送信ボタンをクリックするとセッションを継続させるため、session_start()を呼んでいることで発生するエラーだ。四行目$_SESSIONとういう広域変数が定義されていない旨だ。これは、変数をアクセスする場合、変数に値が代入されているかどうかを検証する必要があることを示している。最後の行は、問題で配列へのオフセットをNULLをにしようしている旨だ。おそらくこれが原因で変数の値がNULLになっていると思う。
で、これらのワーニングを取るべき変数のアクセスに関して、isset 関数を利用した。具体的には
if( isset($_POST['SessionID'])) {
....
}
のような記述を加えた。 同様に $_SESSIONにも
isset($_SESSION['xxxx'] )) {
...
}
のような記述を加えた。 この結果、ワーニングは、
session_start(): Session cannot be started after headers have already been sent in ...
とPHP Warning: Trying to access array offset on null in なったが、相変わらずセッションで確保した変数の値がNULLになる。
試しに一旦セッションのエラー出力を停止して、ページを表示してからフォームに入兎力して「送信」ボタンをクリックすると変数に値が残っている。
一応これでうまくいった。 行ったことをまとめると
- セッションのエラーを出力するために、ini_set('log_errors', 1); とini_set('error_log', 'php_session_error.log');を書き加えた。
- ワーニングがsession_start(): とTrying to access array offset on null ... になるまで、修正した。
- 最後にセッションのエラーを出力するのを停止した。
全く原因がわからないが、ホスティングのWebサーバの場合、複数の機器をあたかも一つのサーバにあるように振る舞う仕組みであるため、セッションのための変数を保存するパスがNULLをであったりするので、これが影響している可能性もある。
AT&T Internet Security
近年様々なインターネットセキュリティとい言葉が様々な場所で見かける。YouTUBEで動画を見ていると、YouTuberがVPNの宣伝をしている場合もある。それもVPNを使うとあたかもセキュリティが強化されます的なことを述べている。
さてVPNについては、以前に
という記事で紹介しているので改めて詳しく述べないが、会社や特定の組織専横のVPN以外の一般に開放しているVPNを利用することで、セキュリティが強化されることは殆どないと言っても過言ではないと思っている。 理由は簡単でVPNサーバから一般のインターネットを利用して接続したいサーバ等に接続するため。 また、VPNを使ってもWiFIから侵入される危険は一切回避できない。
AT&Tは、毎日の様にインターネットセキュリティを勧めてくる。 さて、セキュリティという点について個人的な感想は、
- セキュリティが突破されてもそれが、利用者由来の原因なのかセキュリティシステムの原因なのかよくわからない。
- ウィルスに感染するのは、インターネットを介して感染するよりもWIFI経由で感染する場合が多い。（著者は経験済み）
- WiFIから侵入に関しては殆どのセキュリティソフトウェアは約立たない。
また、近年のウィルスソフトウェアは、感染している機器に関してあまり何もしないが、CPUリソースを使って他人のWIFIへの侵入を試みるようだ。近年のPCは、CPUパワーが十分あるので、ウィルスが様々な解析を行うには十分なリソースがあると言える。ウィルスに感染している機器を使っている人は感染に気が付かないし、WIFIの通信速度は通常のインターネットより十分速いので、近隣の人が迷惑を被るだけだ。 ある日突然、ネットワークが遅くなったといったことが起こる。
セキュリティで個人的に最も問題だと思いっている点は、
- セキュリティが突破されてもそれが、利用者由来の原因なのかセキュリティシステムの原因なのかよくわからない。
という点だ。 つまり金銭をかけても、リスクが低減するかもしれないだけで、異常があった場合には、大切なデータは吹っ飛び、個人情報は拡散してしまうが、その責任を追求できない。 一番の例が安倍元総理であろう。彼はSPのカードに保護されていた一種のセキュリティによって守られていた。しかし、結果は事実の通りである。 つまり、セキュリティという商売は、売る方のリスクが最低限でよく結果が伴わなくても、責任が追求されないビジネルモデルであると言える。セキュリティは一種の抑止力になると思うが、強制的に突破しようする人やプログラム等に対して残念ながら無力であると言える。更に重要な点は、インターネットのセキュリティが物理的に見えない点であろう。物理的に見えないので、計算機空間存在するデータだけになる。 しかもそのデータは例え契約していても利用者に開放されない点あるため、責任の追求ができない。
即ち、利用者が自分自身で気をつけるか、チェックの必要がある点だ。他人（企業やセキュリティソフトウェア）に頼るには十分ではないと認識し、それでも頼る場合、何かあった場合にはその責任はすべて頼った自分自身であると認識する必要があると思う。
KeyHoleTVを視聴することで、WIFIが他人等に利用されることを検知することは可能である。しかし、あくまで検知であって、プロテクトではない。 セキュリティはプロテクトを行うように見せかえていて、実際一部に関してはプロテクトしてくれるだろうが、未知なものに対処ができないので確実とは言えない。
情報を得るためにインターネットを利用する場合は、KeyHoleTVを使うことを勧める。
KeyHoleTVは内部でバッファをもっているため、PCのバッファを利用しない。一般のブラウザはバッファをPCのファイルとして確保する。動画を見ていてもバッファされるし、ウェブページを見てもクッキーやらのデータを確保する。
ブラウザを使う場合、相手のサイトに対して十分に注意する必要があると思う。特にWindowsPCを利用されている場合、リスクが高くなる。これは、WindowsPCが十分に存在しているため、ウィルスを感染させると苦労に見合う結果になるからだ。 同様にiOSデバイスも近年その対象になりつつある。これは主にマルウェアだと思う。モバイル端末は能力が向上しているが、それでもマルウェア対策ソフトを動作させると負荷が増えてバッテリーの消費が激しくなる。サイトの閲覧やメールを見ることもできるだけiOSデバイスでは避けたほうが良いかもしれない。
近年やたらとクッキーの確保に関して問い合わせがくる。 これは、そのサイトがサードパーティのクッキーを使っているために発生する。 ブラウザの設定の既定値でサードパーティのクッキー（放とんのが広告用）ブロックする設定になっているために発生する。
KeyHoleTVのプレミアムモジュールキーの購入サイトは、クッキーを利用しているが、サードパーティのクッキーではなく、利用者が入力したデータを記憶するためにクッキーを利用しているので、サーバから強制的にクッキーを送りつけているのではない。
Windows Update 後、KeyHoleTVが動作しなくなった方へ
どうしそうなった
本日KeyHoleVideoを動作させているWindows10にUpdateがかかった。 自動でアップデートがかかるようになっているので、これはどうしようもない。 しかし、Windowsを再起動した後、KeyHoleVideoはおろかKeyHoleTVも動作しなくなった。 アプリは起動するがログインできない。 このような経験がある視聴者もいらっしゃると思います。
さて、このような状況になった場合、殆どの場合がUDPのパケットが届かないのが原因で、どこかでUDPのパケットを止めている者がいる。 殆どの場合Windowsの ファイアウォールで止めているので確認してみた。
図１で示したように、KeyHoleVideoもKeyHoleTVも例外のアプリとして設定されている。でも接続できない。
早速Googleで「Windows 10 UDP does not work」で検索すると、
というような案内がでてくる。日本語の検索では
となっている。 既に例外アプリで登録されているので、ここからハマった。
結論からいうと
何らかの理由（おそらくWindowsの不具合）で、表示上例外が設定されているが、実はされていないので、もう一度設定する必要がある。 アプリを一旦消去（スタートメニュからKeyHoleTVを選んで選択するとUnInstallがあるのでそれを選ぶ。するとアプリが消去される。 ファイアウォールの例外の確認を行う。
許可されたアプリで、KeyHoleTVを探す。 許可されたアプリは、ABC順になっているので「K」で始まるアプリまでスクロールすると消えていない場合、表示される。 ここで、表示されている場合KeyHoleTVを選んで、「消去」ボタンをクリックする。 これで、ファイアウォールの許可リストからKeyHoleTVが消える。
消えた後、KeyHoleTVをダウンロードして再インストールを行う。
Windows版KeyHoleTVダウンロードとWindows8,10用インストールマニュアル
の手順に従ってインストールすると利用可能になった。
ハマった内容
（１）レジストリの値が何らかの理由で戻っている場合がある
KeyHoleTVやKeyHoleVideoは、過去 v2p.keyholetv.jp というドメイン名のサーバとアクセスしていた。 この値は、Windowsの場合レジストリに入っている。 Updateが発生し再起動した時、レジストリの値が v2p.keyholetv.jpに戻っていた。 現在は、OISEYER.NET であるため、レジストリの内容を変更した結果、アプリが全く動作しなくなった。 従って、手動でレジストリの内容を変更した場合、動作しない場合がある。 また、ファイアウォールの例外を消して、アプリを再起動して許可を与えた場合でも、レジストリの値が戻っている場合があるので、再インストールすることをお勧めします。
（２）ファイアウォールを無効にしても動作しない可能性がある。
ファイアウォールを無効し、PCを再起動後、アプリを動作させみた結果、動作しなかった。 従って、アプリの消去と例外アプリの消去と再インストールが必要だと思う。
（３） UDPの許可のルールが記述したりしたが、レジストリの値が戻っていることに気が付かなかったので、全く無意味になってしまった。
ログフリー VPN(Virtual private network)
VPNの実態
VPN(Virtual private network)というサービスは、VPNサーバと顧客の端末、VPNにサーバ同士が接続して、暗号化された通信をVPNサーバ間及び端末（PCやタブレット、スマートフォーン等）間で行います。 端末には基本的にVPN用のアプリがあります。 このアプリが端末の通信を全てVPNサーバ送信し受信も全てVPNサーバからになります。 また、ルータにVPNを設定する場合もあります。この場合、ルータに接続している全ての機器がVPN経由になります。
そもそも、VPNは企業が用いるプライベートネットワーク（殆ど場合、ローカルエリアネットワーク） をグローバルネットワークで利用しようとして開発された経緯あります。
it-trend.jpさて企業でVPNを使う場合、問題はありません。 多くの場合、個人端末（PCやスマートフォーン、タブレット等）から企業のVPNサーバに接続して、企業が持つプライベートネットワーク上に点在するデータベースや業務ソフトを利用するわけです。 例え、企業のプライベートネットワークが分散していて複数の地域にまたがっていたとしても、全ての通信は、VPNサーバ経由で暗号化されていますし、条件によっては複数の暗号化したデータのやり取りがVPNサーバ間で行われるかも知れません。
ここで、問題となるのは個人的にVPNを提供している会社と契約して、そのVPNサーバを経由してWEBページやインターネットを利用したサービスを受けることです。 何が問題になるかはっきりするために、現状のVPNを使ったWebやインターネットサービスのアクセスとVPNを使わない場合のアクセスの例を示します。
図１ VPNと通常の通信
図１で示した赤や青の長方形は、インターネット上でデータを送受信するデータをパケットと呼ばれ、全てのインターネット上で通信する際に用いられます。 パケットは、ヘッダとペイロードから成り立っています。 ヘッダには自分のインターネット上のアドレスと送信相手のアドレス等が収められています。 図中の下にあるVPNを使わない場合のパケットはヘッダと本来のペイロードから構成されています。 本来のペイロードには、送信したい内容が格納されています。 このペイロードの部分は場合によっては暗号化されています。 VPNを利用する場合、WEBサーバに届けるパケットをVPN用のパケットのペイロードに収めてVPNサーバと通信します。 その後、VPNサーバはVPN用のペイロードから本来のパケットを取り出し、ヘッダにある送信元のアドレスをVPNサーバのアドレスに変更してWEBサーバに通信します。このため、VPNサーバからWEBサーバへの通信のパケットは、赤色のヘッダと青色のヘッダの合成になっています。 また、VPNサーバに接続すると、全ての通信がVPNサーバとの通信になります。 図では、WEBサーバとの接続を示しましたが別のサービスでも同様です。例えば、DNSはネットワーク上の名前をアドレスに変換するサービスで、VPNを使わない場合プロパイダが提供するDNSサービスを受けますが、VPNを使う場合、VPNに登録されているDNSサービスを利用します。殆どのインターネットを利用するアプリは、DNSを利用してホスト名からアドレスを求めます。従ってDNSによる通信は必ず発生しますが。DNS検索ではTLS（Transport Layer Security）によって暗号化する仕様が追加され、現在では殆ど暗号化されています。 更に殆どのWebページがSSLを用いたペイロードを暗号化した通信を行っています。 SSLについては
で説明されています。このサイトで記述してある「SSL暗号化通信の流れ」は、
- 接続要求
- SSLサーバ証明書と公開鍵をクライアント側へ送付、更に秘密鍵の作成
- クライアント側で共通鍵を作成
- 共通鍵(セッションキー）を公開鍵で暗号化しサーバ側へ送付
- サーバ側は秘密鍵で共通鍵(セッションキー）を復号
- サーバとクライアントは共通鍵(セッションキー)で暗号・復号したSSLの通信を開始
という順番です。 さて、VPNサーバは端末側とWEBサーバとを仲介する位置にあり、その間を流れる全てのパケットを双方に転送しています。 転送の際、端末側への送受信はVPNの暗号化が行われます。本来は端末側とWEBサーバ側でSSLの暗号化を設定するわですが、VPNサーバを介していることで、VPNサーバがもし、秘密鍵の生成や共通鍵の生成を行うことができると、端末側はWEBサーバと暗号化通信をしているつもりでも、実際はVPNサーバと暗号化通信を行う結果になります。更にVPNサーバ内で完全に復号化されたデータを解析することができます。 WEBサーバ側は端末と通信しているつもりでも、実際はVPNサーバと暗号化通信していることになります。 この状態は端末側、サーバ側の両者では一切判明しませんが、もしVPNサーバがHTML5で定義している端末の地図上の位置情報の獲得で、本来の端末の位置を返さず別の位置を返答する場合、VPNサーバはSSLで暗号化された通信を完全に復号していると考えることが出来ます。 実際に海外から日本にあるVPNサーバと接続して
radiko(ラジコ) | インターネット・スマホアプリで聴けるラジオ に接続してみて、ラジオを聴くことができる場合は、HTML5で定義している端末の地図上の位置情報をVPNサーバが解析しておそらくVPNサーバが存在する位置情報を返しています。 このことは、VPNサーバが端末側とWEBサーバが側の通信で、VPNサーバ内では暗号化した通信文が平文に復号されていることを意味します。 平文に復号されたHML文章を解析しないとHTML5で定義された構文が分からないからです。 このような状況下ではVPN利用者の個人情報やクレジットカードの番号等はVPNサーバにとって一つの情報として蓄積可能ですし、他者に情報を渡すこともできます。 VPNを運営する企業がそのようなことをしない場合でも、VPNサーバがハッキングされると同様なことが起こりえます。
近年ログフリーなVPNも出ています。
このログフリーと謳っているVPNを運営する企業のプライバシーポリシーを確認すると、
下記の情報を収集しません
- VPNサーバーに接続した接続元のIPアドレスやタイムスタンプ
- 通信内容や閲覧履歴
- DNSクエリ
となっています。 プライバシーポリシーに記載されている内容では、平文のデータを収集していないだけで、利用しないという記述がありません。 従ってどこかにその情報を送信してもプライバシーポリシーに違反しているわけではありません。特に平文を解析するのは、セキュリティのためにという謳い文句があるので、他の組織に送信して依頼する場合も可能ということになります。 VPNサーバのその特性で全ての通信を受け入れます。このため、VPNの顧客が何らかの脅威になる場合がありえます。 そこで、暗号化したパケットを復号してから解析し自己保全を務めなければなりません。ですから、利用者が用いている一般に利用されているような暗号化（例えばSSL)では、VPNサーバは必ず複合してパケットの内容を精査している可能性が高いと思っています。そうでないと、利用者からのハッキングやアッタクが防げませんし、専門的な第三者機関に依頼するのも当然です。 VPNを運営する企業は通信内容を収集していませんのでプライバシーポリシーに違反もしていません。
平文のデータを解析するとパスワードや個人の趣向や動向などをAIを利用した解析が可能となります。 その結果もし対象の個人が自分のクレジットカードに対して頻繁にチェックしていない場合などは、少額のサブスクリプション契約を勝手に締結されるかも知れません。
VPNを運営する企業の謳い文句である「セキュリティの強化」ですが、近年多くのWEBサーバがSSLを導入しているため通信内容が他人に露見する可能性が低いと考えられます。 更にDNSに関しても近年暗号化されていますので、第三者が覗き見ることは少ないと考えられます。 暗号化されていない通信を利用者が用いる場合は、VPNが有効に活用されると思いますが、VPNサーバから送信するパケットは暗号化されいません。 企業が利用するVPNの場合は、VPNサーバから企業内のサーバに接続するような一種のLAN環境ですから、VPNサーバ間、VPNと利用者端末間が暗号化されているだけで問題がありません。 しかし、一般の利用者の場合は全く異なります。 多くの場合、パケットの監視は何らかのサーバ付近で行われることが多いようです。 ですから、どこにセキュリティの強化があるのかよく分かりません。 唯一考えられるセキュリティの強化は、公共のWIFIを利用した場合、パケットが抜かれる・コピーされるという問題が発生しますが、暗号化されたパケットをコピーされたり抜かれても特に問題は発生しませんし、コピーされる場合VPNのサーバの負荷が増える可能性があります。 VPNサーバの仕様にもよりますが、オーバフローしてサーバが停止したり、最悪VPNサーバがハッキングされる原因になるだけです。
また、Google等に検索履歴等から個人の趣向などの収集を気にするため、VPNを使おうとする場合もあるかも知れません。 しかし、もしG-Mailのアカウントを保持しており、それにログインしている場合はVPNを使おうとも全く問題がなく収集される結果になります。検索履歴の情報がGoogle等に渡るのが嫌なら、G-Mailにログインせずプライベートモードでブラウザを使うべきだと思っています。 同時に常にモデムの電源を頻繁に入り切りしておくべきでょう。 これでアドレスが変わり、少なくともアドレスから紐付けしにくなり得ます。 しかし、IPアドレスから地図上の位置に関しては、プロバイダが用意するアドレスに依存するため、ある程度地図上の位置情報が固定されてしまいます。 このあたりはVPNを使った方が良いかも知れません。しかし携帯端末やタブレットの場合、地図上の位置情報を端末が持っていますので、HTML５で問い合わされると、VPNサーバが暗号化を復号しない限り利用者の位置情報をGoogleに提供されるでしょう。
ログフリーは、追跡ができないのか
基本的には、日本国内にあるサーバのログを残す必要もなければ、開示することもありません。 しかし、何らかのサイバー犯罪や特定の人物や組織に対して誹謗中傷などが行われ、その通信経路にVPNサーバがある場合、裁判所はVPNサーバの業者にログの開示を要求できます。電話に対しても同様なことができます。具体的には、盗聴する機器を職員が設置して、司法関係者が聴くという場合です。 確かな証拠がある違法な場合で、サーバ設置者がログの開示を拒否したり、存在しないこを照明すると、裁判所から記録を取るような命令が下ります。それも拒否される場合、強制捜査が行われます。最悪従業員が逮捕され、司法当局がサーバを管理下に置く場合もあります。 当然、強制捜査が行わている情報は、顧客に開示されません。 もし開示すると別の法律違反となる可能性が高いと思います。 強制捜査が行われている間の個人情報の追跡は結果的にできてしまいます。
ここで、司法当局者は強制捜査によって対象外の個人情報も獲得出来てしまいますが、司法当局者は、守秘義務があるので問題にはなりません。しかし、ここで得た他の人の個人情報が別犯罪であることが分かって場合、それが犯罪の証拠として採用されるかどうかは分かりませんが、次の強制捜査の対象になることは確実でしょう。
ここで、重要なことは、
- 全ての利用者がVPNを介して犯罪を行っていないことが前提として、ログフリーを行っているということをVPN会社は述べていること
- 強制捜査が行われていることは分からないこと（停止したりすると、司法当局が営業妨害になってしまう）
- 個人がVPNを使って違法なことしている場合、それが当局によってわかれば、強制捜査の対象になること
- 強制捜査によって、芋づる式に対象利用者が分かってしまうこと
- 強制捜査中や裁判所からの命令で記録をっている間はいくらでも追跡ができてしまうこと
更に、民事の場合でも裁判所からの命令が発行できる点です。これは、これだけの額の被害があって、その被害はVPNによってもたらされているという証拠がある場合、確実にログが取らされます。 そうでなければ、VPNの会社が損害賠償を支払う必要がありますが、おそらくしないでしょう。 多くの場合、これらを回避するために、第三者による査察を受け入れており、利用者が違法なことをしていないことを証明して、記録の公開をしない場合もあります。 しかし、犯罪の証拠があれば、逆に隠蔽として扱われる場合もありえます。
有料のVPNの場合たとえ別のVPNを介して契約しても、利用した金融機関から追跡される可能性が高い。 第３国等の金融期間を利用しようとすると、別問題が発生する可能性がある。最も一般的な問題は、海外に複数の口座を持っている場合の脱税やマネーロンダリングに帰着する場合が多い。
何故、上記のようなことを知っているかというと、KeyHoleシステムには、チャット機能があります。 チャットを使って、特定の個人に対して誹謗中傷の文書を記述することが可能になり得ます。 そこで司法関係者にKeyHoleシステムを始める前に相談をした結果です。
国際関係が複雑な昨今の状況でのVPN
現在、国際関係が複雑で、ある意味混沌としている状況です。敵対する国同士で戦争や紛争を起こしている場合もあります。このような状況でVPNを利用することは、VPNサーバが保持している個人の通信履歴が、関係機関より閲覧可能な状況になり得ます。
例えば、VPNサーバから敵対もしくは輸出等の制限がかけられている国にアクセスを行う人がいるという事実があると場合、そのVPNサーバに国は、安全保障を理由に情報の提出を養成できます。
インターネットのパケットは、送信先と送信元のアドレスが入っているので、国際通信を行う拠点では、送信先のアドレスや対象の送信元調べることができます。現在緊張関係にある国に通信を特定のサーバから行うことは、緊張関係にある国にとっても、また送信元の国とっても「安全保障」という錦の御旗のもとに閲覧される可能性が高くなります。発信元の国はだれが利用したかをVPNサーバを運営している会社に問い合わせるが可能になります。
VPNサーバを利用することで、利用者の場所やどこに通信したかの情報は、一般のハッカーからは見えなくなりますが、国にはすべての情報が筒抜けになり得ます。 多くのハッカーは個人の通信をみるのではなく、どちらかというと、特定の企業などのサイトにアクセスしてくる通信を見ていると考えています。
多くの人がVPNを利用して通信を行っている場合、国は情報の取り放題です。ここには個人のプライバシーは、ありません。VPNを提供している企業のプライバシーポリシーにも記載されていると思いますが、「法的な根拠がある場合」すべての個人情報は、関係機関に提出されます。
何故、こんなことを記述しているか
まず、日本の地上波で流れるテレビ番組を対象地域以外で視聴することは著作権の侵害に当たります。 テレビ番組は、テレビ局だけで構築した著作物で構成されているわけではなく、音（音楽）、映像、出演者など様々な著作物や肖像の複合体になります。このため、テレビ局が保持していない著作物や肖像の権利は、持ち主にあります。 テレビ局は、テレビ放送で利用するための使用料を支払っています。 さて、ここで言うテレビ放送ですが、地上波は特定の地域だけ放送を行うことを前提としている場合が以前は殆どでした。 これがあっためテレビ番組がなかなかインターネットにテレビ局が流さなかった理由の一つです。 近年多くの番組はインターネット上で公開されています。これは、番組中の人物や著作権保持者との間でインターネットで公開してもよいと
契約が締結された結果です。 さて、このインターネット上で公開可能でも、日本国内のみ可能と海外も含めて可能という扱いがあります。 例えばTVerやIPTVは、基本的に日本国内で視聴可能です。 例えば、Radiko、TVerやIPTVのサーバは日本国外からのIPアドレスを弾いています。 それを国外で視聴する場合、視聴者は著作権法に抵触する可能性があります。 理由は、テレビ局とその番組が構成する他の著作権や肖像権等の利用範囲外となるからです。
おそらく、最悪の状況はVPNに接続してHTML5の端末の地図上の位置情報をVPNが本来の端末の位置情報を返さない場合で、VPN利用者が著作権侵害であるとことを認識しつつ、動画を楽しんでいることだと思う。まず、VPNサーバはSSLで暗号化したHTMLを完全に復号して構文を解析している。 即ち、利用者とWEBサーバのやり取りを完全に他のシステムに送信可能である点が上げられる。 また、利用者は自分が犯罪を犯している可能性を考えているので、例えVPNサーバが違法なことをしても、それを法的機関に報告することに戸惑いを覚える可能性が高い。 例えVPNを運営する企業に悪意がなくても、VPNサーバがハッキングされれば同じことが発生して、おそらく犯罪の発見が遅れることなってしまう。企業が使うVPNとは異なり、一般の利用者に提供されるVPNサービスは、利用者の情報を秘匿する代わりに、VPNを使わない場合に比べて安全とは言えないかも知れない。
過去日本のテレビ番組を流すために、利用者に機器を購入してもらい、それを設置して管理する企業がありました。 「まねきTV」という企業で、著作権侵害の裁判で一審では無罪となりましたが、最高裁では著作権の侵害が認められました。
この時、「まねきTV」が訴訟の対象になり、利用者は特に問題になりませんでした。 さて、問題はここからです。 VPNを運営している企業はVPNを運営しているのであって、VPN自身は全くの違法性がないことで、プロバイダと同一の扱いです。 インターネットを利用した販売でプロバイダや回線業者が罰せらることはありません。利用者がVPNを使って著作権を侵害している可能性がある点です。 即ち利用者が著作物を持っている企業から訴訟の対象になるということになります。VPNの企業は違法なことをしている利用者を守るはずもなく、簡単に情報の開示を行います。
VPNによる日本在住の人にとっての不利益
真っ先に上げられるのは、VPNサーバがある回線の混雑でしょう。VPNは、VPNサーバと利用者とVPNサーバ間で暗号化した通信を行っています。 図１（VPNと通常の通信）でも明らかなようにVPNの通信には、ヘッダ情報を付加します。 それだけで単純に通信量が増加します。また、動画を提供する多くのサーバはMTU (Maximum Transmission Unit)の大きさを考えてパケットを構成している場合があります。 効率よくパケットを構築して送信すると、ネットワークに負荷がかかりにくくなります。 しかし、VPNを利用するとせっかく動画サーバが調整したMTUよりもおおきくなり、結果的に複数のパケットに分割されたりするため効率よく通信ができません。
IPTVやTVerをVPNを介さないで視聴する場合、IPTVをやTVerサーバの通信による制限がありえます。 しかし、個々の人に届けるパケットは様々なネットワーク上のノードにより分散されます。 即ちサーバが十分通信容量がある場合特に問題が発生しません。 しかし、VPNサーバを仲介すると、VPNサーバ自身の通信回線の制限に引きずらます。 VPNサーバはプロバイダが用意しているほどノードになるVPNサーバが展開できないと思いますので結果的に通信の制限がかかります。 更に、本来は分散して特定のネットワークに負荷が掛からないようしているのにも拘わらず、VPNを介することでVPNサーバ付近のネットワークに本来は掛からない負荷がかかり、その周辺の在住の人にとって通信しにくい状況に陥ります。 このため、特定の地域の通信速度は遅くなり、ネット上良く見かける
等は、VPNサーバが設置されるとすぐに変化して情報が当てになりません。 また、TVerやIPTVのサーバも接続されるアドレスや接続数によって複数のサーバを上手く割り当てているはずですが、VPNサーバの数と利用者の数を比較すると圧倒的に利用者の数の方が多いため、いくらTVerやIPTVのサーバを分散しても、TVer、IPTVのサーバとVPNサーバの間の通信の制限に依存する結果となります。 以前KeyHoleTVの顧客でVPNを導入された方がいました。 VPNの設定でUDPを通信可能にしてもらっても、音が途切れ映像が停止するような状況に陥りました。 これは、VPNサーバやVPNのネットワークの性能がKeyHoleシステムのサーバの性能やネットワークの性能より遥かに劣っているために発生した問題です。
無料、もしくはNHKのBS放送は基本的にインターネット上に流れないのは、おそらくVPNでIPTVやTVer等が世界中に流れるのが原因であると思っている。 一番の問題は、米国の企業が著作権を持つ放送がBS放送で送信されることだと思っている。 例えば、MLB（メジャーリーグ・ベースボール）が代表で、NHKのBS放送で頻繁に放送されている。 米国は著作権に関して、最も厳しい対応するし、個人に対しても訴訟が頻繁に起こる。 VPNによるIPTV、TVer等の海外からの視聴を制限しない限り、地上波で視聴できる可能性が低い。 本来ならば、地上波でMLBを視聴できる日本国民が一種の被害を受けていると思う。
VPNを利用するのは安全なのか
企業で利用する場合のVPNは企業が保証しているので安全だと言えます。更に、VPNサーバの接続先が企業のLANであるため問題なく利用できるでしょう。 しかし、一般の利用者がVPNを使うのは絶対に安全であるとは言えないと思っています。 VPNを使う多くの場合、対象の地域で特定のサービスが受けられないので、VPNを経由してそのサービスを利用するというものです。 対象の地域のサービスが受けられないのは、対象のサービスの契約が地域限定となっている場合や何らかの犯罪防止の可能性があります。 特に有名なものと一つとして、日本国内でジブリ映画の視聴をインターネットで出来ない点です。これは、動画を配信しているNetFlex等が日本国内でジブリ映画を放映するための権利を保有していないために発生する問題のようです。詳しくは、
をご覧ください。
多くのブログやウェブマガジン等でジブリ映画の視聴方法が寄稿されています。例えば、
や
等でしょう。 気になる点は、これらのサイトにあるVPNの説明で、殆どが広告になっている点でしょうか。 広告主に対して、不都合な事実を記載することはないと思います。
さて基本的な問題を上げますと、日本や北米でVPNを使ってジブリを視聴する行為は、著作権の侵害になると思っています。具体的には、おそらく 違法ダウンロード - Wikipedia に当たると思います。重要な点はVPN業者は違法ダウンロードを行っていません。特別な通信回線を提供しているだけですので、違法ダウンロードの行為はあくまでも利用者になり、摘発されれば罰金や刑事罰がくだされる可能性があります。
上記の’ことから、VPNを使って違法ダウンロードを行った場合は、例えネットワーク的には安全かも知れませんが、個人が罰金刑や刑事罰を受けるのは安全と言えないかも知れません。
また、ログフリー等と述べてあたかも司法当局か利用者が見つからないように見える仕組みを提供しています。違法ダウンロードは、親告罪のためジブリが申し立てをする必要があります。しかし親告されてているかどうかは残念ながら分かりません。ただ、親告されている場合は既に強制捜査されているかも知れません。そうなると対象のVPNサーバに司法当局が遠隔でログを取っている可能性があります。重要なことは司法当局がログを取得しても、VPN運営会社はログを取っていない点ですので、この企業が掲げているプライバシーポリシーには違反していない点です。これはNTTの電話交換器に司法当局者がNTTに依頼して盗聴装置を取り付けることに似ています。
最も恐ろしいのは、VPNの顧客が違法ダウンロードと知りつつVPNを利用して視聴していることだと思います。顧客が違法性を考えているので、例えVPNの会社がセキュリティを理由にSSLの暗号を復号して、それを専門の組織に渡したり、その複合した情報を利用しても、おそらく被害届けを出さないでしょう。 また、復号した情報を元に利用者が簡単にわかるようなことをしないと思います。更に、別の利用者によってハッキングされた場合も同様です。複数のWEBサーバ等に対してハッキングを行っていたような犯罪組織は、VPNのサーバだけを狙えば、複数の個人情報を得られれることが可能になります。個人的には、通信のセキュリティ等というレベルの話ではないと感じています。理由は簡単で、犯罪組織は個人のパスワードを得て正しく金融機関にログインできるからです。従って、VPNを使えば安全であるということは、絶対にあり得ませんし、かえって危険が増す可能性があります。VPNを運営する会社はVPN性質上、顧客を選べませんし、様々な通信がVPN経由で可能になります。即ち顧客が脅威となる場合がありえます。サービスを限定し通信プロファイルを縛る場合、サーバのセキュリティは守られやすくなりますが、VPN運営会社は選ぶことが出来ません。
プロトコルには階層があって、VPNは下層の階層に対して行っているため、上位の階層のプロトコルが殆ど利用可能になります。従って、VPNサーバは殆どのプロトコルを受け付ける必要が’あります。このため、VPNサーバの保守は、他のサーバの保守と比べて煩雑になり得ます。この事からも理解できるようにVPNサーバの保守では、顧客が何をしているかを調べる必要がありますし、暗号を復号して専門組織にその情報を渡していることも当然と言えます。
VPNを利用することは、VPNが行う通信が暗号化されているため、通信内容が他者にはわかりにくいのは事実です。 しかし、近年SSLによる暗号化でWEBサーバとの通信は暗号化されていますし、DNSによる検索も暗号化されているので、特にVPNの方が安全かということは無いはずです。暗号化されていない通信を利用する場合は、VPNを使う方が安全であると思います。しかし、VPNサーバから対象のサーバまでは暗号化されていない通信を行うので、VPNサーバの付近を見張っているだけで、暗号化されていない通信を見つけることが可能になります。この場合、VPNを使う方が安全ではないと考えることが出来ます。更に、VPNサーバの乗っ取りやVPNの運営会社自身が依頼する復号したパケットの精査など、新たな脅威があります。この脅威はおそらく暗号化した通信の安全性よりも脅威だと断言できます。
KeyHoleシステムのよる配信
はじめに
一般に地上波の再配信は、著作権法に抵触する。VPNを使った場合でも同様で、VPN業者に対して使用制限をかける要請を行うことが出来る。 さて、KeyHoleシステムのよる日本の地上波の配信は、著作権法に抵触するが、KeyHoleシステムの配信速度は、地上波デジタル放送による中継システムより早く送信可能である。
上記の動画の下の小さい画面がKeyHoleTVで上の大きいものがテレビである。テレビは、テレビの受信が難視聴地域のためケーブルテレビを利用しており、近畿地方で受信したKeyHoleTVとテレビ映像を撮影した。 東京で行われている国会の中継をNHKが行ってるが明らかにKeyHoleTVの受信の方が早い。東京で地上波を受信してKeyHoleシステムで再配信したにも拘わらずである。地上波を東京から近畿地方、ケーブルテレビと中継した結果遅延が生じてKeyHoleシステムの配信速度を下回っている。 近畿地方でこの遅延が生じているので、より離れた地域でどのくらい遅延が生じるか見当がつかない。
もしテレビ局がの地上波に変換する前の映像と音声をKeyHoleシステムで配信すれば、日本全国に、およそ0.5秒の遅延で配信可能になる。 この0.5秒の遅延はラジオ番組をKeyHoleシステムで配信した場合も同様で、他のシステム（例えばラジコなど）と比べて圧倒的に早く送信可能である。 当然ラジオ局のインターネット番組でも圧倒的にKeyHoleTVの受信速度は早い。
更に、現在はあまり普及していないがワンセグと呼ばれる特定の帯域の電波を使ったテレビ放送もあるが、これはそもそも地上波（フルセグ）よりかなり遅い。 KeHoleTVと比べてみると明らかで、これを比べる動画を下に示す。
小さい画面がワンセグで大きい方がKeyHoleTVである。動画が示しているように、明らかにKeyHoleTVの方が早い。
KeyHoleTVはこの二つの事実をもって著作権法に対抗している。日本のテレビ局は、放送免許を取得する条件として、緊急な通知をいち早く放送する必要がある。 以前のアナログ放送の場合は、光の速度で受信出来ていたので遅延なしに緊急な通知が放送できた。 しかし地上波デジタル放送になったため、テレビのデジタル信号に情報を載せると遅延が発生する。
地上波デジタル放送は、アナログ放送時と比べて情報の伝達量が多いため、高周波数の電波帯を利用している。アンテナを交換したり、ケーブルテレビや光テレビに変換された日本の方は多数いると思う。一般に高い周波数の電波は低い周波数の電波と比べて直進性が増す。 このため障害物の影響を受けにくい高い電波塔が必要で東京スカイツリーはこのために建造されてといっても過言ではない。 このことは、以下のニュースサイトの内容でも確認できる
高い直進性は、障害物により電波の受信が困難になる場合ある。この対策の一つにIPTVや光TV、ケーブルTVがある。特にIPTVのは、インターネットパケットを利用した地上波デジタル放送の送信で、TCP/IPを用いた通信によりテレビの受信ができる。 IPTVの遅延は、デジタル放送からIPに変換するための遅延とインターネットによる遅延、TCPによる遅延があり分単位の遅延が発生する。
上記に示しているのは、IPTVで受信した場合の時間の違いである。 テレビ画面の時間と現時間との比較をしてみると分単位の遅延が生じている。
上記のことから、KeyHoleTV以外では遅延の幅おおきくなる。
受信速度が早いKeyHoleTV
今まで、日本のテレビ局は地上波の再配信に対して法的な対応を取ってきた。 これは「まねきTV」事件の結果からも明らかである。 以下のその判例を示す。
上記のように日本のテレビ局は、再配信に対する法的な対応を取っている。何故このような対応を日本のテレビ局が取っているかという点は、
（１）出演者に対する支払いの問題
（２）利用している音楽、映像などの利用料の問題
があると以前著者がテレビ局と番組最作社との話し合いでわかった。 テレビ局は、出演者や利用している音楽や映像の二次利用の契約を締結していない場合が多く再配信をしてまうと、出演者や音楽や映像の二次利用対する支払いが生じる可能性高くなる。このことを防止するため、テレビ局は断固とした対応を取っている。
さて、日本のテレビ局が断固とした対応を取っているが、KeyHoleシステムに対してはどうかというと、実験を始めた当初TBS、東京MXを除いた各社から停止の要求が来た。この時、KeyHoleシステムの詳細を要求が来た会社に対して案内を送付した。 その後、各社からの停止の要求は来ていない。 しかし、FIFAから弊社に対してワールドカップの試合に関してその間だけ配信の停止の要求が来た。 そこで、弊社はワールカップの放送時間だけ配信を停止する機構を設けて対応した。 しかし、２０１１年に起こった東日本大震災以降、FIFAからの停止の要求はない。 何故、このようなことが起こるかというと全ては「受信速度が早い」ということに帰着する。 ２０１１年の震災では津波による被害が大きい。津波による避難は、いち早く情報を獲得する必要がある。津波は物理学の方程式で、津波の速度（v）は水深（h）と重力加速度（g）を用いて
v＝√gh （m/s）として表すことが出来る。
上記で示したサイトの例でも明らかなように一秒でも早く逃げる必要がある。
KeyHoleシステムは条件よっては地上波デジタル放送の中継した場合の放送より早く、ワンセグに関しては無条件でワンセグより早く、他のインターネットを介した情報伝達より早く情報を伝えることができる。 日本は立憲民衆主義国家で、日本国憲法第二十五条に国民には生存権があり、国家には生活保障の義務があることが書かれている。また、日本国憲法九十八条は違憲の法令を無効としている。
KeyHoleシステムは、特定の条件下では著作権法を違憲することが可能になる。それは、災害が発生思想な場合や発生した後で津波が起こる場合である。 もし災害が予測可能であったり、津波の到着が完全に予測され時間に猶予が必ずあると保証できる場合、おそくらKeyHoleシステムによる再配信は停止させられていると思う。 残念ながら災害の予想は完全ではなく、沿岸部断層が多い日本では津波の到着までの時間が非常に短い。このため、KeyHoleシステムでは常に再配信ができており、１５年以上再配信を続けている。
KeyHoleシステムによる恩恵
KeyHoleシステムで日本のテレビの再配信を行ったことによる恩恵はKeyHoleシステムの視聴者だけではないと思っている。 KeyHoleTVが出るまで殆どの再配信システムは、放送局の訴えにより停止してきた。 唯一KeyHoleTVだけが長期間再配信を続けている。
KeyHoleTVの場合、海外にも日本国内に利用者がいる。 このため、弊社のホームページやKeyHoleシステムは誰でも閲覧可能で制限を設けていない。 KeyHoleシステムを始めてから他のシステムによる再配信のシステムが現れてきた。 殆どのシステムがIPTVを利用したシステムで日本国内でIPTVを受信してそれを海外のサーバに再配信を行っている。 しかもそれらのサービスは、一旦メールしてから契約するような形式になっていたり、ホームページが日本国内からアクセス出来ないようにしたり当局からの追求をできるだけ抜けるようにしている。 これらのシステムでは、当局による摘発があまり行われていない。 これがKeyHoleシステムの恩恵であると考えている。
単純な話、当局はKeyHoleシステムを止める手段がない。法的な根拠もなく人権を守るシステムを当局が摘発することもできない。 更に、KeyHoleTVの存在、開発元や私の情報は全テレビ局、総務省や国会議員も知らせている点である。 KeyHoleシステムを存在を国が知っているにも掛からわす、テレビ局や国が断固とした態度を取らない。
IPTVの再配信を利用するシステムは、VPNを利用した場合と、IPTVのパケット海外の特定のサイトに送信する日本国内の固定IPであるので、違法な配信の証拠を当局が掴めば、VPNの会社に対して制限を加えっるように要請するだろうし、特定の海外サイトに通信をするアドレスにも立ち入り検査が可能で、簡単の排除できると思う。
これらのことから、IPTVのサイトにKeyHoleTVの顧客を減少させようしている気がしてならない。 KeyHoleTVが配信をやめれば、IPTVのサイトの全滅と著作権侵害に対する損害倍書を求めると思う。 KeyHoleTVは速さを追求しているためどうしても画面がカクカクする場合あり、また動画も大きくなっても鮮明ではないので、経済原則に則って視聴者が奪われるのは、どうすることもできないが、KeyHoleシステムの配信が停止した後、おそらく他のシステムは摘発を受けて視聴できなると予想できる。
現在、KeyHoleシステム以上に早く（もしくは同等）にデジタルで配信できるシステムは、著者の知る限り存在していない。もし読者の方々がビデオチャットシステムを想定するのであれば、
（１）音に関して割れる、途切れる可能性が高い。
（２）通常のチャットと比べて通信量が増加し、動画停止する場合がある。
の問題点があると思っている。 （１）に関しては音の圧縮と声の圧縮では音と声の
周波数帯が違うのが原因である。 音の方が声よりも周波数帯が広いので、声の圧縮を音の圧縮で利用すると声の帯域以外の音が割れたり違う音になる。これは、特定の周波数対して有効になるような圧縮方法では対象以外の周波数の圧縮では、正しい周波数がデコードできないことによる。
（２）に関しては、近年、条件を細分化した圧縮方式により、効率的に圧縮できるようになっており、細分化した条件が異なれば違う方法の圧縮方式がとられる。例えば、映画などの蓄積された映像を圧縮する場合では、一部の映像情報を再利用することで圧縮率を上げている場合が多い。録画されているので録画されている映像の何秒前の映像の一部が利用可能となり、その映像データが必要がなく対象の映像を利用しているという情報だけで十分である。 しかしこのような方法は、テレビ放送で利用すると、番組の途中で視聴者が見る場合、視聴者が視聴を開始した時間以前の情報がないため、全ての映像が映らず、何か別の映像が映る場合がある。 読者の諸兄も圧縮率を上げた映像を再生する際、シークバーを動かして時間を飛ばした時、灰色の画面で何かが写っているような映像を見たことがあると思う。このような状況を避けるために、一定間隔で映像の全てを放送して、参照するのは一つ前の全映像にするようにしている。 これが地デジ番組を視聴した時、すぐに番組が映らない原因の一つであり、圧縮率が上がらない原因の一つである。 動画の一分毎に映像を溜めて圧縮して配信すれば、圧縮率が向上するが、遅延が一分以上になってしまう。
またチャットシステムは、人が対象として写っている場合を想定した圧縮を行っているので、そのままテレビ画像を配信しても圧縮率が下がる。 具体的な例としてスマートフォーンのカメラには人の顔を認識できるような機構がある。 即ち特定の領域以外の圧縮高めて、特定の領域では圧縮率を下げることで、チャットしいてる人の顔がはっきり見えるようになり、情報量の削減に繋がる。 また、チャットシステムは、ズームはあってもパン（画像を上下左右にする）や画像の切り替えはあまり行われていない。これも、圧縮率の向上に一役買っている。ところがテレビ番組は、画面の’切り替え、パンやズームが頻繁に行われる。
上記のようにテレビの映像では、特定の場合に上手く行っている方法がそのまま利用できない。
iOS15によるKeyHoleTV の修正
KeyHoleTVがIOS15で動作しない
iOS１５がリリースされた。 iOS14まで動作していたKeyHoleTVは、完全に動作しなくなった。KeyHoleTVを起動すると、以下のようなダイアログが表示された。
これらは、利用者から報告を受けたので、手持ちのiPhoneをiOS15にアップグレードして、XCode10で再コンパイルして動作させてみた。 同じダイアログが表示され動作しない。
XCodeのアップデートとMacOSのアップデートとMacの不具合
iOS15用のXCodeは、XCode13が必要で、XCode13は、MacOS 11.6 (BIg Sur)にしないといけない。 そこで、ます使っているMacMiniのOSを11.6にアップグレードし、その後、XCode13をインストールした。
XCode13を起動して、KeyHoleTVのXCodeのプロジェクトファイルを読み込ませてみると、すんなり読み込んで開発環境が整った。
デバックするためには、シミュレータを動作させる。 シミュレータは、XCodeのホタン一つで起動するので、起動して動作確認を行うと、シミュレータが起動せず、Macが落ちて再起動がかかる。何度やっても結果は同じ。 一応Macのセーフモードを起動してみた。 また、機器の動作確認を行うことができるので、それもやった見た。 特に問題は報告されない。 しかし、XCodeでシミュレータを動作させると、Macが落ちて再起動がかかる。 ここで、一応XCodeのバグ報告で現象をAppleに報告した。
KeyHoleTVが動作しない原因
シミュレータが動作しないので、手持ちのiPhoneで動作確認を行うことにした。 プログラムを実行させてみると、iPhoneのCPU消費が異常に増えていることが分かった。そして、プログラムが異常終了する。 iPhoneのアプリは、アプリが異常終了すると、main に戻ってどこで異常したかがよくわからない場合ある。少なくとも、KeyHoleTVのコードではなく、iOSのライブラリで異常終了している。
KeyHoleTVは、画面遷移のために、iOSのライブラリでUINavigationContoller, UIViewControllerを利用している。 KeyHoleTVは利用者名が登録されていない状態では、画面遷移して「既存の利用者名」と「利用者登録」のボタンを表示するUIViewControllerの画面に飛ぶ。 そこで、この画面に飛ぶ処理にブレークポイントを設置して動作させてみた。
すると、画面遷移をするライブラリメッソド(pushViewController:animated:)が画面遷移せず、何度も呼び出されていることが分かった。
KeyHoleTVはタイマーのメソッドを利用して、画面遷移の状態を管理する値により処理をする仕掛けを用いているからで、遷移した後、状態を変更して再び、遷移しないようしていた。 この仕掛けは、利用者名の入力やパスワードの入力をすると、ログインボタンが有効になるような処理を行っている。
iOS14までは、遷移をさせると、viewWillAppear: や viewDidAppear:のメソッドが呼び出されていた。KeyHoleTVは、viewWillAppearの処理の中で、遷移の状態の値を変更していた。 何度も画面遷移を呼び出していることから、viewWillAppearが呼び出されないことが判明した。 そこで、iOS開発のドキュメントを調べてみると、
Note
If a view controller is presented by a view controller inside of a popover, this method is not invoked on the presenting view controller after the presented controller is dismissed.
となっていた。 元の UIView Controller は閉じていないが、viewWillAppearが呼び出されない。 理由はわからないが、呼び出されないので、画面遷移のライブラリメッソドを呼び出した後で、画面の状態を管理する値を変更してみた。 すると、画面遷移が行われた。
画面遷移が行われたが、ボタンの表示が無茶苦茶になった。KeyHoleTVは、viewDidAppearで画面上のボタンの配置を行っているからで、viewDidAppearが呼ばれない状況では、正しく画面の配置がなされていない。 ここで、しばらくハマった。画面遷移が行われる直前に画面の内容を変更したいが、うまく行かない。 ここで、色々試してみたが殆どがうまく行かない。
Mac MINi SSDの問題発生
何度もプログラムを作りデバックしていたが、突然XCodeでコンパイルの最中にMacが落ちて再起動するようになった。 何度もハードウェアのチェックを行ったが、エラーは見られない。 セーフモードで起動した時だけうまく動作する。しかし、セーフモードで起動すると、iPhoneとの接続でデバッグが出来ない場合があった。 当然シミュレータは立ち上がらない。
遂にAppleにコンタクトを取って状況を説明してみたが、彼らは、私が出した不具合の報告を読んでおり、解決策が見つけられない。
そこで、フット気がついたことがあった。 Mac Miniは、SSDう。を使っている。SSDは、USBメモリと同様で書き込み回数に制限がある。例え使用したファイルなどがディスクの容量未満であっても、一度書き込んだデータは、絶対に消えず、消したというフラグが立つだけ。更にディスク管理のアプリは、どのくらいSSDの有効領域があるかを教えてくれないし、システムチェックでも引っかからない。
XCodeは、コンパイルしたデータを一旦保存しそれらをリンクする。この作業を繰り返し行うとSSDの寿命が減少する。 おそらく、これが原因でMacが落ちたりするのであろうと想定して、外付けのハードディスクを購入した。 外付けのハードディスクが当着した後、バックアップを取ったり、起動ディスクを構築したり、ホームフォルダを外付けディスクに移動した。 これらの作業の結果、XCodeでシミュレータが起動するようになり、Macも落ちなくなった。
viewDidLayoutSubviewsによる解決
開発ドキュメントを色々読んで見た結果、viewDidLayoutSubviewsが使えるかも知れないと思い、プログラムを実装した。 この結果pushViewController:animated で遷移した時は、一度だけ呼び出されることが分かった。また、デバイスが移転した時も呼び出される。 これは、AutoLayout と呼ばれる機構が実装されたからで、ストーリボードを使った場合、UIViewControllerに配置する部品の位置を関節的に設定でき、デバイスの大きさが変わっても、相対的にボタンなどがうまく配置される。 しかし、KeyHoleTV
は、ストーリボードを利用していないので、プログラムで設定する必要がある。 最初は、自動レイアウトするようにプログラムを記述したが全く動作しない。おそらく何らかの初期状態の設定が必要だと思う。
