「星宝転生ジュエルセイバー」の素材を利用する場合について考えてみた

「星宝転生ジュエルセイバー」というスマートフォン向けのゲームがあって、そのサービス終了時に利用規約にあるような条件で、 二次利用ができることになっている。 とは言っても、jewel-s.jpというドメインは、既に元の所有者である株式会社ブリリアントサービスの所有ではないようだし、株式会社ブリリアントサービスは Cognizantに買収されて、現在はコグニザントジャパンというCognizantの日本法人になっているようで、brilliantservice.co.jpのドメインも他の人に取得されている。

二次利用できるコンテンツはjewel-s-free101j.zipというファイルに含まれている内容であり、利用規約を読む限りでは、このZIPファイルの再配布に制限はなさそうだ。 開発に関与した有川光太さんという方の「noteはじめました」という記事でも、このZIPファイルの再配布に制限は ないと書いているし、まあ普通に読めば再配布には問題ないと理解できる文章であると思って良いように思われる。 その中のreadme.txtにある内容は、項番4以外は簡単に満足させられる。 項番4は以下のようになっている。

4.事後の報告を欠いた利用
「フリーコンテンツ」を利用した作品の公開から4週間以内の報告が必要となります。専用報告フォーム （https://docs.google.com/a/brilliantservice.co.jp/forms/d/1N4xCA6lY_5d_pNC0TSLJMg-GqJyY2jDhmOvegN1QRjU/viewform）への事後報告をしてください。

簡単に満足させられないというのは、この「専用報告フォーム」が、2021年8月10日時点、既に存在しないという点である。

「星宝転生ジュエルセイバー」には公式Twitterアカウントがあって、当然、既に更新などされていないのだが、それを見てみると、 https://twitter.com/jewelsavior/status/636487745360162816というtweetがある。 これによると、@jewelsaviorにメンションして、ゲーム名とその運営者が分かるユーザー名を連絡すれば良いとの記述がある。 元々は、公開で利用の許諾を得ていることを宣言するためのものだったようだが、今はこれしかないので、これで報告するのが項番4を満足させる唯一の方法であるように思われる。 実際、結構な数のメンションがこのtweetに連なっている。

web.archive.orgでjewel-s.jpを見てみると、以下のようにQ&Aが書かれている。

どんな形で報告すれば良いでしょうか？
「書籍に利用」「ゲームアプリに利用」「イベントフライヤーに利用」などの簡素な報告で問題ありません。 ただし、作品が公に発表される類のものである場合は作品を確認するための情報を添えて下さい。 Web上に作品を紹介したり販売するためのページがある場合はURLを、Webでの確認が難しい場合は販売・発表の場所や販売元等の情報をお願いします（個人間やクローズドな組織内での利用等、公にはしない類のものであれば不要です）。

これに従ってメンションするので良いと考えて良さそうだ。 これで、どこかで発表する資料でこの素材を使うことはできそうだ。

本当は、コグニザントジャパンに問い合わせて項番4を取り消してもらえれば良いのだろうが…。

HTTP_PROXY環境変数に記号を含めたい場合

RubyのURI.parseでプロキシーサーバーを設定する際にパスワードとして使えない文字と言う記事で、 ユーザー認証付きのプロキシーサーバーの認証情報付きのURIをWindowsのHTTP_PROXY環境変数に指定する際の条件について書いていた。

いまいちescaped = % hex hexの場合がどうなるのか分からないが…。

と書いていたが、使えない文字(記号など)は普通にURLエンコードすればパスワードとして使用できるようだ。 元記事はJRubyの場合で、今はJRubyの環境ではチェックできなかったが、Go言語で書かれたプログラムでは、URLエンコードされたものは利用できた。

ただ、URLエンコードしない場合にGo言語で書かれたプログラムがどうなるかはチェックしなかった。その環境でチェックできるのはしばらく先になりそうだが、確認しておきたい。

NetBSD上のPuTTYでUnix domain socket経由でsshアクセスしてみる

PuTTY 0.75の変更点によると、 PuTTYのツールでUnix domain socketが接続先等に指定できるようになっている。

The Unix tools can now connect directly to a Unix-domain socket.

OpenSSHのsshコマンドはUnix domain socketに接続はできないようだし、sshdもUnix domain socketで接続を待ち受けることは できないようだが、sshコマンドでport forwardingでUnix domain socketを転送の元としても先としても利用できるようだ。

以下のようにすることで、remotehostホストで起動するsshdが22番portで待ち受ける接続を、 /tmp/test.sockからアクセス可能にする。 -o StreamLocalBindUnlink=yesは、/tmp/test.sockが既に接続済みである場合に上書きして作成するように指示している。

$ ssh -o StreamLocalBindUnlink=yes -NL /tmp/test.sock:remotehost:22 localhost

以下が接続した場合の例である。

$ plink -ssh /tmp/test.sock
WARNING - POTENTIAL SECURITY BREACH!
The server's host key does not match the one PuTTY has
cached. This means that either the server administrator
has changed the host key, or you have actually connected
to another computer pretending to be the server.
The new ssh-ed25519 key fingerprint is:
ssh-ed25519 255 SHA256:xxxx
If you were expecting this change and trust the new key,
enter "y" to update PuTTY's cache and continue connecting.
If you want to carry on connecting but without updating
the cache, enter "n".
If you want to abandon the connection completely, press
Return to cancel. Pressing Return is the ONLY guaranteed
safe choice.
Update cached key? (y/n, Return cancels connection, i for more info) y
Using username "username".
Access granted. Press Return to begin session.
Last login: Sat Jul 24 01:10:29 2021 from xxxx
NetBSD 9.1_STABLE (XEN3_DOMU) #2: Wed Jan  6 15:28:26 JST 2021

$

OpenSSHでsockなHTTPプロキシーサーバーを実現する

IPアドレスでアクセスして来た利用者の地理的な位置を認識するウェブサービスというのはいろいろとあって、 その制限を回避してまでそういうサービスを利用しようとは思わないのだが、明確に制限されているということが分からないような 表示になっている場合があって、そういう場合には他の地理的場所のIPアドレスからアクセスしたい場合がある。

これまでは、U.S.にあるVPSを借りているので、そこにsshでログインしてw3mでアクセスしていたが、 JavaScriptどころかCSSでさえもサポートされていないので、目的を達成できないことも多かった。

良く考えるとOpenSSHのport forwardingでSockサーバーくらい実現できるような気がしたので調べてみると、 UbuntuのページにあるDynamic Port Forwardingを 解説しているページを見つけた。

sshコマンドを実行するホストと同じホストでブラウザーを動かすのであれば、以下のように実行すれば良い。 この場合、sshはlocalhostからしか接続できない。

$ ssh -D 1080 -N remotehostnameinus

sshコマンドを実行するホストとは違うホストでブラウザーを動かしているのであれば、どのホストからもアクセスできるように、以下のように実行すれば良い。

$ ssh -g -D 1080 -N remotehostnameinus

これをFirefoxで、プロキシー設定のホスト欄にsshを実行しているホストのホスト名かIPアドレスを設定し、 ポート番号欄には1080を指定すれば良い。 FirefoxであればSOCK v5でもSOCK v4でもどちらでも良いようだ。

NetBSDでホスト名にアンダースコア(_)が入っていても不正なホスト名と認識されないようにする

Bloggerのpreviewは、アンダースコア(_)が入っているホスト名を利用している。 NetBSDは、かつてはアンダースコア入りのホスト名は許されていなくて、libc resolver library does not resolve host names with underscores ("_")でデフォルトで許容するようになっていた。 最近の議論を追えていないのだが、2021年4月30日に 戻されて、/etc/resolv.confでno-check-namesオプションを指定しないと、アンダースコアが含まれているホスト名は許容されないようになっていた。 Bloggerで書いている以上、アンダースコアを含んだホスト名を許容しない訳にはいかないので、/etc/resolv.confにno-check-namesオプションを含めておかなくてはいけない。 だが、/etc/resolv.confはdhcpcd(8)を実行する度に内容が書き変わってしまうので、手で/etc/resolv.confで書き換えても永続化はできない。 /etc/resolvconf.confで設定して、/etc/resolv.confを再生成する度に、no-check-namesオプションを含めておくようにすれば良い。

$ cat /etc/resolvconf.conf
resolv_conf_options=no-check-names

こうしておくと、以下のようにoptions no-check-namesを含んだ/etc/resolv.confが生成される。

$ cat /etc/resolv.conf
# Generated by resolvconf
domain mylocalnetworkdomain
nameserver xxx.xxx.xxx.xxx
options no-check-names

JPEG形式の写真のEXIFデータを削除する

ディジタルカメラでJPEG形式で撮影した画像には、カメラや撮影条件の情報がEXIFデータとして含められている。 場合によっては、このEXIFデータを削除したい場合がある。 調べてみると、ImageMagickの-stripオプションを付けたmogrifyコマンドで 簡単に削除できた。 以下のように実行すれば良い。

$ mogrify -strip *.JPG

Toshiba dynabook R731/16BでCloudReadyを使い、Chromium OSマシンとして使ってみる

東芝dynabook R731/16Bというラップトップを持っている。 Microsoft Windows 10も動くのだが、CPUはIntel Core i3-2310Mだし、メインメモリーも2GBなので、あまり快適ではない。 かといって、NetBSD/amd64をインストールしても、開発するには非力過ぎる。

最近はChromebookのシェアが伸びていると聞いて、そういえば何年か前はChromium OSを独自ビルドして配布している人がいたのを思い出して探してみた。 最近は放送大学のテレビ・ラジオの講義のインターネット配信がWidevine CDMを使っているので、これが視聴できれば便利である。 ちなみに、Chromebookとして販売されているラップトップでは、正常に視聴できると分かっている。

そこでChromium OSの独自ビルドを探してみると、2021年も熱心に安定版をビルドして配布している人はあまりいないようだ。 その中で、Googleに買収されたNeverwareという会社のCloudReadyの Homeエディションが無料で使えることが分かった。 ただ、安定版はChromium OS 89ベースだった。Chromium OS自体の最新安定版は91である。最新のDev channelとして提供されるのも90.1であるようだ。

インストールは、USBスティックにダウンロードしたイメージファイルを書き込んで、そこから起動させ、メニューのInstall OSから実行すれば、内蔵HDDにインストールできる。

当初の目的であったWidevine CDMを使ったビデオ配信は、問題なく視聴できた。 ちなみに、Androidアプリのインストールはサポートされていないし、サポートする予定もないとのことだ。 Linuxバイナリーの実行はメニューにはあったので有効化できそうだ。