piu lentoの日々 (piu lento days)

自作ソフト2個※の改良をしていて間が開いた。プログラムの変更・修正は面倒だが、動作確認に時間が掛かるものは大変だ。これは そのうちの1個で、動作確認が比較的短かく済んだものだ。

※面倒なことを同時にするつもりはなく、片方が片付いてから もう片方を始めたのだが、片付いたつもりがミスが見付かったりして、結局 同時進行になってしまった。途中で、いろいろなことが同時に起こり、頭がおかしくなりそうになって全部ぶちまけたくなるような、危ない場面もあった・・・

はじめに・概要

題は当たり前のことだけど難しい。: 以前 自作ソフト(Spotifyのミニプレーヤ Minisp)を新版(現行)のSpotifyアプリに対応させた時に手を抜いた※ために いくつかの問題(問題Aとする)が起こったが、別の問題(問題Bとする: PCのスリープからの復帰後にMinispがハングすることがある。: これも手抜きが発端の可能性がある)を直すために試行錯誤したら、そもそもの問題Bについては不明なものの、問題Aは直せた。 (ここの記述は いくら手直ししても、自分で読んでも分かりにくかったので、下のように時系列のリストにした。: 6/5 6:03)

1. 以前 自作ソフト(Spotifyのミニプレーヤ Minisp)を新版(現行)のSpotifyアプリに対応させた時に手を抜いた。
   • 元々動いていたものがSpotifyの都合で動かなくなったので、そういう しょうもないことのためにSpotifyを使って居る訳ではないので、時間・手を掛けたくなかったのだ。
2. いくつかの問題(→ 問題A)が起こったが、暫定対処(手抜き)で しのいで居た。
   • 問題の内容は下の「経緯・詳細」を参照のこと。
3. その後見付かった別の問題(→ 問題B)を直すために試行錯誤した。
   • PCのスリープからの復帰後にMinispがハングすることがある。: これも手抜きが発端の可能性がある。
4. 問題Bについては不明なものの、問題Aは直せた。

Minispは結構前に作ったので、細かいことを忘れていて、なかなか苦労した。ただ、そのおかげで、作った当時の思い込み・誤解がクリアされて居て、再度考え・調査して作ったので「ちゃんと」できた。けれど、プログラム自体は ぐちゃぐちゃだ。綺麗にしたいが、やっぱり面倒だ。

また、以前書いたことで、現行のSpotifyアプリは旧版に比べてDbusの動作がおかしい(特に、再生開始や一時停止のイベントが来ない)というのは、僕のプログラムの問題による誤解で、若干の動作の変化はあるものの、Spotifyアプリに問題は なかった。

結局、現行版対応時の手抜き以外に、元からの問題(一部のDbusイベントを捨ててしまう)があり、それが現行版で顕著になったようだ。

経緯・詳細

Minispを現行のSpotifyアプリに対応させた時にDbus(正確にはMPRIS)の動作仕様が変わったと思い込んで以下の対処をしたが、正しくなかった。アプリの動作の変化以外に僕の誤り(Dbusイベントのフィルタがキツ過ぎたなど)があった。

• Dbusイベントのフォーマットが違う。 → △ デコード処理を変更し、情報が足りない場合はSpotifyのAPIで取るようにした。
  • → イベントのフィルタがキツ過ぎて落としていたのと、イベント書式がNuvola Player(以前のもの, 今は不明)に近いことが分かった(単に、イベント内の情報の順序が旧版と違っているだけかも)ので、その処理を改良・追加した。
  • Dbusのデータの解釈を ちゃんとすれば※ こういう問題は起こらないのだが、なかなか難しくて手を抜いたので、こういう羽目になっている。
    • ※Dbusのデータフォーマット(JSONに似ているが、違う)の解釈をするコマンドなどが ありそうだと思って検索したが、見付からなかった。
• 再生開始や一時停止のイベントが来ない。 → × 定期的(1.5秒)にSpotifyのAPIやDbus(修正初期)で状態を取得するようにした。
  • 新版で出なくなったと思い込んでいた。
  • → 実はイベントが出る(フィルタがキツ過ぎて落としていた)ので、それを利用することにして定期的に状態をチェックする必要が なくった。
  • APIを使っていた時(修正前)は、下のシークとともに数秒ごとに呼び出していたので、API呼び出し回数が激増した(この作業をするまで気付かなかった)。 (→ グラフ: 左側)
    • API呼び出しは無料だが(頻度の制限はある)、無駄に実行するのは良くない。
• シークがDbusでは取れない。 → × SpotifyのAPIを使って(無理やり)取るようにした。
  • → 実はイベントが出るので、取れるようになった(プロパティでも取れる)。今は、曲が変わる時だけAPI呼び出しをするようにできたので、回数は激減した。定期的な再生位置の較正はローカル(d-busだけ)で出来るようになった。

なお、誤りに気付く前はSpotifyアプリのログファイルからイベントを取ることも考えたが、不要になった。

ログを使うほうが簡単・確実ではあるが、書式が いつ変わるか分からないので、良くない。

それから、そもそもの問題(スリープからの復帰後にMinispがハングすることがある)の原因は分からないので直接の対処は していないものの、再発していない。※ ただ、おそらく、頻繁にAPI呼び出しをしていたため、たまたま呼び出し中にスリープした場合、復帰後しばらくは それが終わらないためではないかと推測している。

※2週間以上様子を見ているが、まだ問題が起こっていない。

効果・おまけ

上記修正前後のSpotify API実行回数の変化のグラフを示す。

修正前は、気付かずに再生状態の取得(player)を一日に3万回くらいも実行していた※のが、0になった。曲とアーティスト情報の取得(tracks, artists)は、修正・動作確認中は増えたものの、以降は元々と同様の妥当な回数(= 1日の曲の再生回数)に落ち着いている。

※こんなに頻繁アクセスして良くエラーにならなかったと逆に感心した。ただ、たまにアルバム画像や曲情報の表示が遅いことがあったのは、実行頻度制限のためだったかと推測している。

それから、現行のSpotifyアプリには謎がある。: 曲の再生開始後、数回シークイベントが来るが、その位置がふらつく(前後する)のだ。※ なぜ、再生しているだけなのにシークイベントが来るのかもも分からないが、再生処理の状態(通信も?)で較正しているのだろうか? その較正の結果でふらつくのかと推測している。

※現行と書いたものの、実際には旧版からあったのかも知れず、そのふらつき(少なくとも、連続して複数のイベントが出るのは分かっていた気がする)が嫌で、Minispではシークイベントを捨ててしまっていて、そのために必要なイベントも捨てたりユーザのシークが検出できずに苦労し、処理が複雑化したりAPI呼び出しが多くなっていた。

なぜ、こんなことに気付き気にしたかと言うと、Minispの再生位置のバー(→ 参照: ジャケット画像下の灰色の部分)の位置を決めるのにアプリからのシークイベントも使って居るため、そのふらつきでバーもふらつくからである。まあ、ふらつくと言っても1秒程度なので注視して居ない限り分からず、僕はそんな面倒なことは しないので、気分の問題である。

細かく書くと、バーは曲の再生開始後、Spotifyアプリとは独立に定期的に(約0.7秒ごと)動かしている。が、それだと時間が経つとアプリとズレる＊ので、時々(数十秒ごと)、アプリの再生位置を取得して較正している。 (→ 参照: 再生位置が合っている様子) その較正に アプリから来るシークイベントも使って居る。

＊ズレると言っても、アプリとMinispを同時に注視する(やっぱり、そんな面倒なことは しない)か、曲の最後でなければ分からないので、これも気分の問題である。

気分の問題と言えば、そもそも再生位置なんて分かる必要はないので、この動くバー自体が無用のものなのだが、技術的に おもしろそうなので付けた。

とはいえ、僕は「この曲が終わったら＊しよう」とかいうことが多く、その目安には使えるから、全くの無駄でもなさそうだ。

もう一個のおまけ: 本当に現行Spotifyアプリの問題: 曲によっては、アプリ内のリストでの長さと再生位置表示での長さが異なる。 (→ 参照: ピンクの下線部) 秒未満の部分の丸めの問題だと思う(Minispでも起こった)。まさに気分の問題で何の実害もないので、全然問題視していない。単に詰めが甘いと思っただけだ。

まとめ的なもの

結局、手抜きは良くないが、いつも正しくやっていたら時間や手間が掛かり過ぎるので、

「ちゃんとする価値・必要性のあるものか」、「テキトーにやって あとで問題が出た場合、どういう影響が出るか」、「問題が起こる頻度は どのくらいか」、「その対処にどのくらい苦労するか・手間が掛かるか」

(あるいは、天使の声と悪魔の声の どちらに従うかｗ)

のような判断は必要で、その判断を しないと・誤ると今回のようなことになる。だから、手抜き自体が悪いのでなく、テキトーに手抜きすることが問題なのだろう。

(と、いかにも もっともらしいことを書いたｗ)

先日も結構前にもあったのだが、何かの作業でサーバのアクセスログを見ると、不正アクセスや攻撃の試行が見付かって頭に来る。しばらくは対処するのだが、結局イタチごっこでキリがなくて諦めるのの繰り返しだ。

パケットフィルタでブロックした直後は不正アクセスは減るのだが、しばらくすると、敵は新しいアドレスで来て また増えるから、まるでゴキブリや鼠だ。。。

不正アクセスして来たアドレスを自動でブロックすることも考えるが、そのうちにフィルタ処理が重くなったり どこからもアクセスできなくなったりしそうなので、保留している。今は、毎月自動集計して回数が多いところをブロックするようにしている。

今回は、ブロックしても しつこくアクセスして来る企業(E𑀋panse (Palо Aｌtо Neｔwоrks)とІnｔernet-Mеaｓuremеnｔ.cоｍ ※)に、ストーカー的な気味悪さを感じた。それらは「スキャンを停めて欲しければ連絡しろ」などと書いているが＊、そんなことをしたらスパムが来るとか更に悪いことになるに決まっている＠。

※どちらの名前も いかにも公的とか研究機関風だが、そんなことはない。検索されて更に攻撃されたくないので、(今は効果がないかも知れないが)一部の文字を見た目が似ている別のものにした。以下も同じ。

＊そもそも無許可でスキャン・攻撃して居る癖に、なんでそんなに偉そうなのだ?

＠以前、別のプロバイダのabuseの連絡先に、そこのユーザからスパムメールが来るので対処して欲しいと連絡したら、返事すらなくて、逆にスパムが増えた気がする。

被害者から止めてくれるよう申請する建前のせいか、robots.txt(サーバのボットに対する許可・不許可設定)を無視する(そもそもアクセスしない)し、パケットフィルタでIPアドレス(範囲)をブロックしても、少しすると別のアドレスから来るからキリがない。更に、Іnｔernet-は高速「大量」スキャンツール(MASSCAN)を使っているし、一度の連続した攻撃(試行)の種類ごとにアドレスを変えて来る(それらにはUA(User Agent)は付いて居ない)※ので、とても悪質だと感じた。

※そのため、IPアドレスで集計すると数が少なく見えるし、UAで検索・集計・ブロックできない。

全世界の、客のものでないサーバまで、頼まれても居ないのにスキャンしてセキュリティホールを探して、一体どうするんだろうか? 日本の省庁か関連機関(名前は不明: デジタル庁? ICC-Crawlerではないようだ)のように、(内容が不充分にしても)教えてくれるなら分かるし納得行くが。

と訝しんで居たのだが、その後、とんでもないことが分かった。: 一部の企業(例: Shоｄаn※, Ⅽеnｓуs)はスキャンして見付けたサーバのポート公開状況やセキュリティホールを客(有料)や一般に公開している。犯罪の支援ではないか。

妙なのは、USの政府機関(CISA)が そういう企業のサービスを使ったセキュリティ向上を推奨していることだ。 (→ 参照＊) 矛と盾みたいなものか。武器も使いようだけど、これでは政府公認サービスみたいになってしまって、文句が言えなくなってしまう。

＊どうしても この資料がUS政府の本物と思えなかったので、機関の名前やドメイン名やSSL証明書を確認したが、本物のようだった・・・

※今まで見た中でShоｄаnは最悪だ。アクセスにUAは全く付いてないらしく(攻撃ツールで試行しているだけ?)、IPアドレス範囲が広いうえに変化が激しいようなので、特定できない。だから、僕のサーバに来たかどうかも不明で、出所が不明な攻撃として集計していた可能性が高い。

そういう企業にネットへのアクセスを提供するプロバイダ(例: Digіｔal 𑀞ｃeаn)も同罪だ。調べると、Digіｔal-社に文句を言っても禄に対処しないらしい。 (→ 参照)

まあ、上に書いたように、「政府のお墨付きがある、セキュリティ向上のためのチェックだから問題ない」というスタンスで逃げられたら、どうしようもない・・・

結局、根本的に対処しようがないのが頭に来る。全部消えて欲しい。

US系とC国系の そういう企業で戦って、両方とも消滅してくれると ありがたいが、戦争になってしまう?

補足 (5/19 21:20)

書き忘れて居た。: 連中(E𑀋panseとІnｔernet-Mеaｓuremеnｔ.cоｍ)や その他のボットを少しでも排除したくて、基本的なrobots.txt(サイト全体のもの)にブログのサイトマップの定義を追加してWPの仮想robots.txtにするようにした。※ が、結局、(本文に書いたように、)行儀の悪い奴らはrobots.txtを無視するので無駄だった。でも、あとで使えるかも知れない(少なくとも保守が楽になるし、方法が分かったので、別の定義の追加なども楽だ)。

※WPのフックrobots_txtにrobots.txtの内容を生成(置換)するフィルタ(関数)を設定した。

なお、今のrobots.txtはE𑀋panseとІnｔernet-への渾身の怒りを込めて書いた。それが他のボットや検索エンジンに読まれて誰かの目に留まれば、少しは溜飲が下がるか。

PS. なお、UAは容易に偽装・詐称できるので、別人が悪い企業を詐称したり、悪い企業がGoogleなどを詐称することが充分考えられるので、発信者はアクセスごとのIPアドレスで検索・判断するしかなく、手間が掛かる。

PS2. 当然ながら、近くのC国からも多くの不正アクセスが来るが、そもそも悪役だし上に比べれば まだ素朴なので、極悪のイメージは少ない。あと、本来のアクセスが期待できないので、どばっと広い範囲をブロックするのに躊躇する必要がないのも良い。

もしC国に真面目に読んで下さる方が居られたとしても、自国の悪い連中の行動は分かっているはずなので、上のように書かれても悪い気分にはならないだろうと、勝手に思っている。

PS3. 今のところだけかも知れないが、日本(のプロバイダ)からは ここまで悪質なものは ほとんどないので感心している。それに、日本の企業だったら、連絡すれば ちゃんと対処してくれそうだ(面倒なので、しないでブロックするが)。

このブログの公開期限切れの投稿を非表示にするのに、crontabのスクリプトでWordPressの機能を実行しているのだが、 なぜか、今月の頭辺りから以下のようなエラーが出るようになった。

AIOS_Helper::request_remote exception - cURL error 28: Operation timed out after 4001 milliseconds with 0 bytes received

どこから出るのかも原因も分からないので様子を見ていたら、エラーは次のものに変わった。※

AIOS_Helper::request_remote exception - cURL error 28: Failed to connect to api.ipify.org port 80: Connection timed out

※下に参照したフォーラムによれば、問い合わせを受けて修正したためにメッセージが変わったようだ。

(「あくしろ」手っ取り早く解決方法を知りたい方は、下の「解決方法」へ)

検索すると、エラーメッセージの"AIOS"というのはWPのプラグイン"All In One WP Security"のことで、それがapi.ipify.orgというサイトにアクセスして(自分(=サーバ)の)IPアドレスを取得しているのだが、その接続に失敗しているようだ。 (参照: WPのフォーラムの同様の問題の問い合わせ: cron job error)

この時は、「(前科者の)"All In One"が またやっちゃったかあ・・・」と溜息をついて居た。ただ、証拠はないものの、エラーが出るようになったのがAIOSの更新後だったかも知れず、であれば「前科者」は正しい。 (← 調べたら、「更新後にエラーが出る」という問い合わせがあるので正しい。)

どうしてIPアドレスを取得するのかというと、webサーバでなく スクリプトからWPを実行する場合、PHPの変数$_SERVER[REMOTE_ADDR]にIPアドレスが設定されていないためだ。

それらの変数は、webサーバが$REMOTE_ADDRなどの環境変数に設定したものをPHPが$_SERVERに格納する。

この辺りはPHPのドキュメントのコメントにあるように、なかなかセキュリティ面が危うい気がするが、今はヨシとする(どうにも しようがない)。。。

どうしてIPアドレスが要るかというと、AIOSがアクセス元を調べるからのようだ。それでブラックリストの判定をしていると想像していたけど、この場合は無意味だ。というのは、サーバからapi.ipify.orgなどにアクセスして分かるのはサーバのIPアドレスで、アクセス元のではないからだ。

きっと、AIOSの更新の時に思い付いて追加したのだろうけど、全く無駄だ。JavaScriptなどでクライアント(ブラウザ)にやらせても詐称されるから無駄だ。環境変数にアクセス元のIPアドレスが設定されていないなら、全部エラーにするかサーバとみなすかのどちらかにすべきなのだ。

百歩譲ってサーバの本当のアドレス(グローバルアドレス)を取るとすれば、外部サイトに依存しない方法にすべきなのだ。

それは環境変数$REMOTE_ADDRで設定されるようなので(この時には上に書いたことは分かっておらず、直感や誤解で そう思った)、試しに、スクリプトを起動する前にlocalhostのアドレス(127.0.0.1)を設定したのだが※、効果は なかった(エラーが出ないこともあったが、出ることもあった)。

実は、上のフォーラムの回答には、アドレスが127.0.0.1の場合にも外部サイト(例: api.ipify.org)でIPアドレスを取得するとあるのだが、最初は読み飛ばしていたために無意味なことをした。

※なぜlocalhostにしたかというと、変わりようがないから安定かつ安全だと思ったためだ。それで却って失敗した・・・

それで、実行する時間帯をずらしたり、実行前にapi.ipify.orgにpingするなどの試行錯誤したあとで(うまく行ったりそうでなかったりした)、$REMOTE_ADDRにサーバの本当のアドレスを設定したら、うまく行っているようだった。

その理由を知るためにプラグインのプログラムを調べたら、上に書いたように、IPアドレスが空または127.0.0.1の場合には外部サイトからアドレスを取得することが分かった。

毎回エラーになる訳でないのも不思議だったが、いくつかのサイトをランダムな順で使っているようなので、api.ipify.orgが使われた時だけエラーになったのではないか。

ただ、そもそもapi.ipify.orgへのアクセスがエラーになった原因は分からないが、たまたまNWやサーバが重かったとかだろうか。

書いたあとで調べたら、他の方でも起こっているようなので、(このサーバでなく、)api.ipify.orgにアクセスが集中して接続できない場合があるのではないか。だとすれば、正しい修正は、IPアドレス取得に使うサーバを選択できるようにすることだ。

だから、

(解決方法) 環境変数$REMOTE_ADDRにサーバの本当のアドレス(例: hostname -i や hostname -ihost -t A ホスト名 で取れる※)を設定すれば、エラーは起こらなくなることが分かった。

※今試して分かったが、hostname -iだと/etc/hostsの設定によっては127.0.0.1が返って来るので、host -t A ホスト名 などがいいかも知れない。

実際には以下のようにしている(the-WP-progがWPの処理を実行するスクリプト)。

export REMOTE_ADDR="`hostname -i`"; the-WP-prog

が、上述のようにhostname -iは今一つなので、(なんか冗長だけど)以下が良さそうだ(未確認)。

export REMOTE_ADDR="`host -t A \`hostname\`| cut -d " " -f 4`"; the-WP-prog

とりあえずエラーは出なくなったが、そもそも、スクリプトからWPを実行する場合はAIOSを無効にするほうが良さそうな気はする。が、それは結構大変(wp-load.phpなどの改造が必要で、逆に問題が起こる可能性が大きい)なので、これで良しとした。

まあ、問題は(サーバでない)スクリプトからWPを呼び出す場合だけで起こり、通常の使い方では起こらない。そのために手間を掛け・リスクを増やすこともないだろう。

PS. 本文で参照したフォーラムのやり取りを見ると、例によって「埒が明かない」感がある。: 質問の題"cron job error"が示すとおり、(webサーバからでない)スクリプトでIPアドレスが設定されないのが問題なのに、回答者が問題の原因を把握できず、適切な回答も修正もしていないので(2番目以降の質問者は)解決できていない。

当然ながら、$REMOTE_ADDRに本当のIPアドレスを設定してスクリプトを実行すれば良いことも書いてない。

不思議なのは、最初の質問者が「解決済み」にしているらしいことで、(しょうもない回答に呆れて)自力で解決できたのだろうか。あるいは 本当に解決していて、僕が曲解しているだけ??

本文に書いた内容や そういったことを投稿しようかと思ったが、ユーザー登録が必要なのと、この感じでは無駄になりそう(無視されそう)なので していない。

PS2. これを書き、そのあとで調べたりしたら、AIOSのアラが出て来て なんか信用ならない感じになって来た。が、以前調べたところでは これが一番良かったので、当面は頼るしかない。が、セキュリティのプラグインが そんなことでいいのか??

外でメモ(雑記やライフログ的なもの?)を記録するのに、自作のメモ・ノートシステム BNoteを使っている。それは、ブラウザのフォームでツイート風にメモを書き込むと、日ごとのノートに追記されてサーバに保存され、作成や更新があればPCにメールで通知が来て、それに書かれているパスでノートにアクセスできるようになっている。

要するに、(今は使っていない)Evernoteに手軽にノートを追記するアプリの代わりだ。: 実際の使い方としては、帰宅後にエディタで そのノートを開いて本来のノート(例: 「日記」: Zimで書いている)に転記(コピペ)・更新する。

なぜ、外でスマフォで直接本来のノートに書き込まないかというと、(Zimはスマフォでは動かないので、自動変換して)Joplinで見られるようにしているが、ノートが大きいとスマフォで開くのが遅くなり、また、大きくなくても編集は手軽でなく、思い付いたことを全く「パッ」と書けないからである。

Joplinなんかで書いていたら、開くたびに時間と手間が掛かってイライラして、書くことを忘れてしまう。そう言えば、Evernoteもそうだった。

もう一つの問題は、スマフォとPCの変更の競合だ。Evernoteでは度々競合が起こっていて、それでもイライラしていた。Joplinでも、同期のタイミングによっては競合が起こる。そんなんなら、自分で同期(上述の転記)したほうがずっとマシだ。

更に、仮にそれらの問題がなくても、メモを書いた時刻を手で付けるのは面倒だ。

そして、各メモの前には送信時刻を付けるとともに、(興味と実益を兼ねて)位置情報(緯度, 軽度, 高さ)※を追加するようにしている。

※ブラウザではJavaScript(例: navigator.geolocation.getCurrentPosition() → サンプルコード)で取れる。ただ、位置の取得に時間が掛からないようにするようなオプション(図: 下部の"opts:"以降を参照)を指定しているため、必ずしも正しい訳ではなく、最後に取れた位置になる。まあ、ないよりはマシな程度である。

ところが、先週くらいから、その位置情報が取れなくなってしまった(ブラウザはVivaldi)。: getCurrentPosition()がタイムアウトのエラー(code= 3)になる。オプションをいくら変えても直らなかったが、不思議なことに、OperaやFirefoxでは問題なく取れる。いろいろ調べると、昔からそういう問題が報告されている。(→ 例) いくつか解決策があった(例: watchPosition()を使う)が、僕の場合はどれもうまく行かなかった。更に、getCurrentPosition()のサンプルコードすら動かなかった(もちろん、Operaなどでは動く)。

「ないよりはマシ」なものだけど、今まで取れていたものが取れなくなったら やっぱり嫌だし、何かがおかしくなったかと心配になる。

更に試したら、Androidの設定の「位置情報の精度を改善」※をonにしたらVivaldiやChromeでも位置を取れるようになった(上のリンク先にも、GPSだけ(= 「位置情報の精度を改善」がoff)の場合は位置が取れないという情報がある)。

※これをonにするとGoogleに更に「いろいろな情報」が送られそうで嫌だし、そもそもGPSの位置を改善する必要性を感じていないので、offにしている。

そう言えば、offにしているとGoogleマップのアプリでも度々onにしろと催促されてイライラするのを思い出した。Off(= ダイアログの「使用しない」= 「位置情報の精度を改善しない」)でも ちゃんと使えるのに、なんでそんなに押し付けるのだろうか? きっと、Googleに さまざまなメリットがあるのだろう。

仮にChromeが突然仕様を変えたとしても※近頃の文句を見ないということは、ほとんどの人はonにしているのか。だから、今後は僕はChromeなどでは位置が取れなくなるのかも知れない。

※Chromeの変更履歴を少し調べたが、関係ありそうなものは見付からなかった。ただ、量が膨大で調べきれず、また、細かく書いてないものがあるので、実際のところは分からない。

まあ、BNoteに関しては、実際にはメモを書いた位置情報を調べることは ほとんどないから実害はないし、Operaを使えば現在位置が取れるので問題はない(今はOperaを使うようにしている※＊)。

※Firefoxでないのは、Firefoxだけ表示がおかしい(入力フォーム(textarea)が幅広になる)からである。

(11/1 13:01) 原因は良く分からないが、Firefoxのtextareaのデフォルトフォント(あるいは幅などの計算に使う文字)の幅が他(Chrome系)のブラウザより広いような感じだ。本来はフォントの平均(あるいは特定文字の)幅とディスプレイ(正確には表示領域)の幅からtextareaの幅(文字数, cols)を求めるべきだが、何とも煩雑だ。

そこで、textareaの幅を文字数では指定せず、 style= "width: 90%;" のようにディスプレイの幅の相対値で指定したら、ちゃんと収まるようになった。

ただ、これだと(実際には使うことはないが)PCでは広くなり過ぎるので、モバイルの時だけにしている。

＊今日になってOperaでも位置が取れなくなった。もしやと思って使用モジュールを調べたら、しっかりChromiumと書いてあった。。。今まで表示されていたのは、更新が遅かったためだろう。

だから、取れなくなった原因は、近頃Chromeの仕様が変わったための可能性が高い。

なお、Firefoxはまだ大丈夫だが、使用モジュール(ライブラリ)は余りにも表示が細かくて調べていない。とりあえずはFirefoxでしのぐ。 (10/31 19:48)

そういえば、以前も同じような問題があってOperaを使うようにしたが※、少し前にスマフォのブラウザをVivaldiに切り換えた時に そのことを忘れて、BNoteもVivaldiにしたのが悪かったのかも知れない。ただ、先週までは ちゃんと位置が取れていたように見えるから、近頃何か変わったのは確かなようだ。

良くあるGoogleの気まぐれなんだろうが、付き合わされるほうは たまったものではない。。。

そもそもweb(JavaScript)の規格では普通に出来るはずのものが、なぜか「位置情報の精度を改善」をonにしないと出来ないのは勝手な押し付けで、それまで出来ていたものが出来なくなったために、結構な手間と時間を掛けて(上記のように)調べる羽目になったのだ。

普通に使えるはずのものは 普通に使わせてもらいたい!

実際の化ける・詐欺メールで動作確認してから公開しようと思っていたが、どちらも いつ来るか分からないので(分かっているのは文字化けが今月末)、とりあえず公開する。誤りや修正があれば、その都度更新する。

文字化けの暫定対処

メーラーは(Thunderbirdに業を煮やしたため)Evolutionを使っていて、概ね問題なく使えている。が、ある会社から来るメールが文字化けすることがある。分かっている限り、化けるパターンは2つあって、以下である(文頭を抜粋)。

• 「㈱クレ」 → 「螢レ」
• 「コス」 → 「●(I:=」
  • 注: ●は(とIに重なっている。

最初はEvolutionの日本語対応が今一つなのかと思い、もしかして送信するメールも化けることがあるのかと思って、心配していた。が、近頃 やる気が出て詳細に調べたら、そうではなかった。上の2種類の問題は、元のメールのcharsetがISO-2022-JP(7ビットJIS)の時に起こり、化ける原因は以下だった。

• 「㈱」のような特殊な文字※がある場合(?)、なぜかその先頭と次の文字の最後の1バイトが抜ける。
  • 元のコード: 2d 6a 25 2f 25 6c : 「㈱クレ」 (下線のまとまりで それぞれ1文字。取り消し線の文字が抜けて化ける↓。)
  • 化けたコード: 6a 25 25 6c : 螢レ
  • ※「文字コード表 JISコード(ISO-2022-JP)」によれば、これはJIS X 0208 (1990) to Unicode変換表にない文字で、それらが駄目なようだ。
• 半角カナ(正確にはISO-2022-JP-MS)は非サポート(正しく表示できず、全角に変換も されない)。
  • 元のコード: 1b 28 49 3a 3d : 「ESC (Iコス」 (ESC ( IはISO-2022-JP-MSの開始を示すらしい。 (→ 参照) コスは半角カナ)
  • (化けた)コード: 1b 28 49 3a 3d (元の半角カナのISO-2022-JP-MSのコードがそのまま出る。 → ESCは●になり、そのあとの記号とカナはASCII文字と解釈される。)

元はと言えば、メールを送って来る会社が「ちゃんと」(特殊な文字や半角カナは使わない)すればいいのだが、そもそも、メールにそれらを使うことを禁止する規則はない(ないこともないが、強制力はない)ので、一般的なアプリ(例: Windowsやスマフォ)で ちゃんと出るようにしているなら文句は言えない。

その会社にしても、情報提供元からのテキストを勝手に変換して誤変換などでトラブルが起こるリスクを抱える気・価値はないだろうから、元のまま送るのが適当だろう。

それで、簡単な対処(ちゃんとやるには それなりの手間が掛かる)を試行錯誤したところ、nkfコマンドで何とかなることが分かった。下のようにすれば、ちゃんと表示できるようだ。 (注: 本物の化けるメールでは未確認)

• ヘッダのContent-TypeのcharsetがISO-2022-JPの場合は特殊な文字があるかも知れないので、本文をnkfに通す。(nkfが「うまく」やってくれるようだ)
• 上に加えてContent-Transfer-Encodingがquoted-printableの場合は半角カナがあるかも知れないので、本文をnkf -mQに通す。(上と同様にnkfが「うまく」やってくれる)
• 上のいずれかの結果をEvolutionに入れる(メールとして送る)。

そして、Evolutionのメッセージフィルタの機能でメールを外部コマンドにパイプで送ることができるので、上の処理をするスクリプトに送り、化けた可能性のあるメールを修正(nkfでコード変換)して自分(のデスクトップのローカルなアカウント)にメールで送るようにした(それを再度Evolutionが受信して、正しく表示される)。

処理を簡易にしているためと化けるメールがマルチパートなので、変換した本文の先頭にContent-Typeなどが入ってしまうが、まあ使えそうだ。

書いたあとに確認していて「ISO-2022-JPとISO-2022-JP-MS」というページを見付けて気付いたが、「㈱」の化けの原因もISO-2022-JP-MSなのかも知れない。「㈱」も変換表にないことから「環境依存文字」で、ISO-2022-JP-MSで追加された文字なのではないだろうか? そうであれば、メールを送る側がcharsetに"ISO-2022-JP"と書くのが良くないのだろう。

それなら、nkfで変換するのでなく、charsetを"ISO-2022-JP-MS"に置換すればうまく行くのかも知れないが、Evolutionが対応しているか不明なので、今は何とも言えない。

詐欺メールチェックの補助

それから、近頃Amazonを騙るメールが時々来るようになった。全部中国のドメインからなので、AliExpressか その店、または、そのあとで握力計を買った楽天の店(中国製品を扱っている)から漏れたのではないかと想像している。

そういうメールは、最初に詐欺と見抜いたらEvolutionのスパムフィルタに指示すれば、以後は自動で判別されて見えなくなるから、大きな手間やストレスではない。が、もう少し補助したくなった。

詐欺メールのヘッダを見ていたら、DKIM-Signatureがある場合があることに気付いた。その内容をdkimverifyコマンド(→ 参照1, 2)でチェックしたら※"ERROR:root:missing public key: default._domainkey.Xyz.co.jp."(ドメイン名は架空)のようなエラーになった。

※dkimverifyには-vを指定すること。

わざわざ、チェックしてエラーになるsignature(署名)を付けるのも間抜けだが、更に間抜けなアプリは騙せるのかも知れない。

そこで、上の文字コード変換と同じような段取りで受信メールのDKIM-Signatureをチェックするスクリプトを作り、Evolutionのメッセージフィルタは戻り値がエラーだったら「DKIM不正」のラベルを付けるようにした。

なお、Evolutionが文字コード変換をするのか、正常なメールでもbody hash(本文のハッシュ)が合わないというエラーが出るので、それは無視するようにした。それだと本文が改ざんされても分からないが、さすがに そこまで手の込んだものは少ないのではないだろうか。

↑ Evolutionの設定を見て気付いた。: Bogofilterのオプションの"Convert message text to Unicode"のせいでメール本文が変換されてハッシュが合わなくなっているかも知れないので、スパムフィルタを(変換する設定のない)SpamAssasinにしてみた。: 次のDKIMがあるメールで本文のハッシュが合うかで分かる。

→ SpamAssasinにしても合わなかったので、Convert message-は関係なかった。そもそも、BogofilterでもSpamAssasinでも、Evolutionから送られて来るメールはUnicodeではなくISO-2022-JP(-MS)だった。 (10/9 6:39)

Bogofilterのためにメール本文をUnicodeに変換しているのなら、文字化けもそれが原因かも知れない。EvolutionがISO-2022-JP-MSをそのまま(Unicode(UTF-8?)に変換せずに)表示できるなら、化けないのではないか?: 次の化けそうなメールで分かる。

→ 上述のとおり、Evolutionから送られて来るメールはUnicodeではなくISO-2022-JP(-MS)だったので、関係なかった。 (10/9 6:39)

また、想像や期待だが、SpamAssasinの"Include remote tests"を有効にすれば(しなくても?)、ひょっとしてDKIMのチェックもしてくれる気がしたので、有効にしてみた。: これも次の詐欺メールで分かるはずだ。

↑ Wikipediaによれば、SpamAssasinはSPFやDKIMにも対応しているようだ。

でも、今後は本文を改ざんするものが出るかも知れない。メールの中継サーバを乗っ取ればできるだろうか。

こうすれば、不正なDKIM署名を付けた間抜けな詐欺メールはメールのラベル(色)だけで分かるので、自分で判断する手間が省け、誤認する可能性が減りそうだ。 (注: 本物の詐欺メールでは未確認)

PS. Ama.を詐称するメールをAma.のそういう窓口に転送すれば何かしてくれるかと期待して数通送ったが、結局また来た。別のところから来ているのかも知れないが(確かに、今までのものは大きく2種類ある)、それも含めて意味がないと感じた。

不正アクセスと同様に、そういう組織を根絶やしにしない限り、ゴキブリのように次々と現れる。「来たら対処する」のような対症療法では駄目だ。

(10/8 6:53 いろいろ修正; 10/9 6:39 Bogofilterの"Convert message text to Unicode"を止めた結果(関係なし)を記載)