webUSBやwebSerialの苦労話


半年ほど前、アンドロイドタブレット専用のポケットCO2センサーの開発機に触れる機会があり使ってみたのだけど、パソコンにでもぶっさせて使えたらいいのになーと思っていた。そんなある日、100円ショップでUSB-typeA to Micro-Bの変換ケーブルを売っているのを見かけて、「あ、接続できるならできるんじゃね」と思ったのが艱難辛苦の始まりだった。

結論から書くと、Google ChromeブラウザのwebSerial APIを使うことで、パソコンなどに接続したUSB機器の読み書きが行えるようになる。USBメモリであったり、USBで接続しているキーボードやマウスであったりするのだが、それがブラウザ、つまりJavascriptでのちょっとした実装だけでブラウザにデータ取得できるしそのままデータをサーバー側で集計することもできのである。

いまのところ、うちのお店でも取り扱っている二酸化炭素センサーにおまけとしてURLを案内している。用途が用途だし、ボランティアで気まぐれに実装したものなので、うち以外から買ってもらった人も使ってもらってもかまわないので、ご自由につかってくださいって開発元(?の大学のセンセイ)にお渡ししたので、もしかしたらそのうち公式でも使えるようになるかもしれない。

二酸化炭素センサーはどうせならうちが扱っているやつをご購入いただけると、センサー精度的にもデータ・ストレージ拡張性とかもあるのでおすすめ。というかおすすめだから紅茶屋がわざわざ扱っているんだけど。

二酸化炭素ポケットCO2センサー Lite

item.rakuten.co.jp/hagurachaya/co2lite-627/

store.shopping.yahoo.co.jp/hagurachaya2/co2lite-627.html

USBがブラウザから操作できるというのは、組織のシステム管理者からすると悪夢のような話しではあるが、セキュリティと利便性はバーターであると考えると、その応用性の高さについては、技術者なら一考するべきなのではないかとおもう。Androidやraspberry pi、micro:bitのようなもの、はたまた今回のようなチップを積んだ二酸化炭素センサー、IOTをブラウザからあれこれ操作できるのは純粋にいろいろ便利。

webUSBを初めて知ったのはHTML5が勧告されたころであったろうか。とんでもない仕様が出てきたなとおもったが使う機会も予定もなかったためスルーしていた。

ミュージックハッカソンなるものがお気に入りで年1ぐらい参加していたのだが、3年めぐらいのときだろうか、あるときウェブミュージックハッカソンなるものに参加した。たしか会場は六本木のGoogleさんだったとおもう。4~5年ぐらい前だろうか?その時の即席チームで作ったのは、webカメラで捉えた映像からステップ・シーケンサー的にタイルを読み取ってMIDI楽器から音を鳴らそうというものだった。

WEBカメラから取得した動画をキャプチャして色調で階調化しモザイクタイル化し、それを音階と音調にするところまでは自分が担当して作ったのだけど、音をどうやってならすん?ってなったときに、チームメンバーがMIDI楽器をつなげて制御してくれるのを作ってくれた。そのとき使われた技術がweb USBの兄弟、web MIDIなるもので、そんな変態的なAPIがあるんかいな!?と顎が抜けたのを覚えている。USBでつないだローカルのMIDI楽器をブラウザ経由で操作できるのだ・・・。実際それで音がなったのでびっくりしたもんだ。
ミュージックハッカソンではヤマハのネットデュエットみたいなセッションをするためにどんだけ通信ディレイをなくせるかみたいなところに注力されがちだったけど、webRTCとかでブラウザ間通信で付属の楽器まで遠隔で操作できたら確かにそんな未来もあるかもしれない。って、まだそんな未来は来てないけどな。

まあ、そんなこんなで、webUSBの存在は知っていたので、データ取れたらラッキー程度の心持ちで、ケーブルを買って夜な夜な取り組みだしたわけである。

web USB
wicg.github.io/webusb/

で、あれこれ試したのだが、マウスやキーボードはwebUSBの環境をつくってやればコネクトできたのだが肝心の二酸化炭素センサーが見えない。

Micro-B to Type-Aのケーブルでパソコンと繋げても、ディバイスマネージャーからもなぜか接続が確認できない。ガジェット側のLEDランプはついているので接続はできているはずなのにと苦悶した。

Windows側、Microsoftの公式アドオンアプリに「usbview.exe」なるものがあると知り、いれてみる。みれない。mac air M1はtype-cなので、system_profiler SPUSBDataTypeやらls -l /dev/tty.* やらをやって・・・。あれ、見れる??はて?なんでTYPE-Aだと見れないんだと、ふと、ケーブルが入っていた袋をみる。

なんと、バッテリーデリバリー専用のケーブルでした・・・!!?
世の中こんな恐ろしいものがあるんですね。正直一連のあれで一番苦労したのはこれでした。

今更だけどtype-Aとかtype-b Micro-B、type-Cとかの基礎をお勉強した。

micro-B to Type-Aのケーブルなんて、考えたらモバイルバッテリー用とか他にも何本ももってたのによりにもよって新しく100円ショップで買ってきたケーブルでやり始めたのが大きな不運だった。
だが、これのおかげで完全に意地になった。

web USBでやろうとしたのだけど、windowsの汎用デバイスドライバが先に掴んでしまっていて、ドライバの書き換えなしには難しそうであったのでWeb Serial Apiに切り替えた。そしてWeb Serialの沼に落ちるのである。

Web Serial API
wicg.github.io/serial/

Web SerialはChrome version 80以上しか実装していないうえ、ごくごく最近まで手をいれられ続けているものなので、目下開発中な感じのApiだ。ちょっと検索しただけで死屍累々、スタックオーバーフロー四暗刻(何か技術的検索をしてstackoverflowの質問が検索結果上位4つ以上を埋めること)であった。

まず、つまずくのが

chrome://flags/
#enable-experimental-web-platform-features

とか

chrome://device-log

とか、見たことない画面への遭遇である。いや、まあここらへんはwebUSBでも必要だっけか。

そして、次につまづくのは、公式サンプルコードすら動かないというところだ。
ふふふ。笑える。

何故か?
port.open()のoptionの値が間違っているからだ。
そりゃスタックフロー四暗刻になるわと思いながら、正直、まあ、ここまでやろうと環境をつくれてる人は突破できるであろう程度の壁でしかない。リファレンスを読めばわかるので、もしかしたら、ScriptKiddy封じのためわざとそうしているのかもしれないので、ここでは詳細には触れずにキャメルやないかい!とだけ言っておく。

で、それで動くかっちゅうと、まだ動かんのですよ。
そもそも使えないブラックリストがあるとかってんで確認したりなんだり。まあ自分の場合、javascriptをよくわかっていないので、asyncやらawaitとかここらへんどうすんだべと悩んだり、名前空間つかえるのか!と実装しようとしてconstの名前空間はどうしたらいいんだろうとか、そういういらんことでつまづいたりしりした。vue.jsに手を出そうとしてこれがやりたいわけじゃねぇやとjQueryに戻ってきたりなんだり。

寄り道はしたけど、実際openしてデータストリームを受け取れるようになった後も、一行でほしいデータセットが3回ぐらいにわかれて送られてきたり、数行分おくられてきたりして、行終端がわからなかったりして、これbaudrateか??とか、javascript側からみると終端に\rしかいなくて、なんで???となったり、あれやこれや。

最近だとLite版とPro版でコマンドの実装がちょいと違って、wiresharkのお世話になった。
そう、wireshark、今USBの通信もキャプチャできるようになったんだって。便利だね。

まあ、そんなわけで、できるってわかればあっさりできちゃうこともあるよね。

他にも登ろうとした山

Androidの開発環境つくりかけてた

PCで正常系の環境再現したいなと素人ながらに考えて、何故かAndroid studioを入れた。
というのもGooglePlayからアプリを入れられるAndroid筐体で自由になるものが手元になく、仮想環境でつくろうと浅はかな知恵をしぼったのだ。だが、これもAMD系のCPUだと仮想環境が動かんのでなにやらBIOSから触らなきゃいけない嫌な感じであった。

そして、これがすこしできるようになってきたところで、登ろうとしている山の高さに気が付き、あれ、おれなにやってるんだろうと、くじける。

Android OTG デバイス給電

ひとにあったりするごとにAndroidの実機を借りて動かしてみたのだけど、最近のスマフォはUSB type-cになっていて、OTGの仕様が機種多様に山程あることにすこし躓いた。・・・これ普通のひと切り替えられないんじゃ説。

USB シリアル接続

触らさせてもらっていた実証実験用の実験機はUSBシリアルで設定をせねばならず、windowsやmacから行う必要があるものだった。まあ、黒い画面をひらいてシリアル通信ができるひとならできるだろうけど、ふつうの人には難しいとおもう。正直、商店街のおじさん達には無理なので自分で協力店を探して設定してまわったのだが、これがwindows exeになったからといって、キャリブレーションとかの意味をサポートなしでわかるひとどれくらいいるんだろうかと不安になったりしている。

流通している二酸化炭素センサー

なんかコロナ禍前は二酸化炭素がらみのセンサーを探すのに苦労してたのに、この数ヶ月で意味のわからん商品だらけになってて怖いです。

スタイリッシュなのが売れ行き好調なようです。まあモニタついていて安いしね。うちのは検索にひっかかりもしません。

とある製品を購入しました。人間の吐き出す吐息は2~3万ppmあるわけです。息を吹きかけても値がほとんど動かんので、ろうそくが消えるまで密閉空間にぶっこんでみたんですよ・・・。他のセンサーが2万とかを刻んでるところ、こわい結果になったのもあったりしました。おっかないですね。
国産って書かれてるのもあるけど、なんか、一年前はシンガポールから送られてきてたやつやないかい?というような気がしてるのもあったりします・・・、まあ、いろいろもやもや。おっかないですね。

他、webSerialの迷えるこひつじのためのURL

github.com/google/web-serial-polyfill/blob/master/demo.html
glitch.com/edit/#!/remix/web-serial-codelab-start


Gmailのメール送信エラー


もう一週間も前の話しだけど、Gmailで受信エラーがおきて、数日したら送信エラーにもなっちゃったのでしかたなく対応したときのメモがでてきたので、あげておきます。そんときゃググっても情報でてこなかったので。いまさらだけど。

gmailで独自ドメインのメールを送受信してたんですが、4/8にTLSまわりでセキュリティ強化があったらしくどうもそれに巻き込まれたようです。

最近、chromeでもhttpsで証明書が有効なのにエラーになってるサイトとかあって、なんだろうなとおもってたんだけど、SSLまわりの強化強めてるみたいですね。こういうご時世だからしょうがないか。多分段階的にあちこちあがってくるとおもうので、順次という感じでしょう。

かれこれ10年ぐらいGmailを使っていて、その前は自分の仕事用のメールとかはBeckyとかをつかってました。ファイヤーバードだっけ?な時期もありましたが。で、ドメインメールは、Gmail側でメールサーバーに問い合わせして定期的に取得するようにしていました。転送にしないのは会社の返信メールとかで自分のgmailアカウントとかが載るのが嫌だからです。

結果としてやはりSSL周りの強化で、popとsmtpの設定を変えることで対応しました。

それまでの構成

独自ドメイン(お名前.com)のメールをシェアードサーバー(さくらインターネット)経由でGoogleのGmailで取得
構成はもうずいぶん長いこといじってない。
何もしてないのに壊れたー!! 状態なんですが、何もしてないから壊れたパターン。

受診時に発生するようになったエラー

サーバーから返されたエラー: "SSL error: ok Hostname "mail.自分のドメイン.com" doesn't match any SANs: "*.sakura.ne.jp", "*.180r.com", "*.2-d.jp", "*.achoo.jp", "*.amaretto.jp", "*.bona.jp", "*.chew.jp", "*.crap.jp", "*.daynight.jp", "*.deko8.jp", "*.dojin.com", "*.eek.jp", "*.flop.jp", "*.from.tv", "*.fubuki.info", "*.gokujou.biz", "*.grats.jp", "*.grrr.jp", "*.halfmoon.jp", "*.ivory.ne.jp", "*.jeez.jp", "*.jpn.org", "*.kirara.st", "*.kokage.cc", "*.mail-box.ne.jp", "*.matrix.jp", "*.mimoza.jp", "*.mints.ne.jp", "*.mokuren.ne.jp", "*.nazo.cc", "*.netgamers.jp", "*.noob.jp", "*.nyanta.jp", "*.o0o0.jp", "*.opal.ne.jp", "*.rash.jp", "*.razor.jp", "*.rdy.jp", "*.rgr.jp", "*.rojo.jp", "*.rossa.cc", "*.rulez.jp", "*.rusk.to", "*.saikyou.biz", "*.sakura.tv", "*.sakuratan.com", "*.sakuraweb.com", "*.saloon.jp", "*.silk.to", "*.skr.jp", "*.spawn.jp", "*.squares.net", "*.sumomo.ne.jp", "*.tank.jp", "*.thyme.jp", "*.topaz.ne.jp", "*.uh-oh.jp", "*.undo.jp", "*.websozai.jp", "*.whoa.jp", "*.x0.com", "*.x0.to", "*.xii.jp""

送信時に発生するようになったエラー

“TLS Negotiation failed, the certificate doesn’t match the host.”
サーバーから返されたエラー「SSL error: unable to verify the first certificate」

対応

年間1000円ぐらいのSSLに契約しているのですが、多分これがサブドメインに対応してないんですね。
ググったけど出てこなかったんで、昔の設定方法かもしれないんですが、popとsmtpの設定を

mail.独自ドメイン.com
smtp.独自ドメイン.com

で、アクセスさせにいっていました。
昔はサブドメインでサーバー設定されていたのですが今はされてないのでしょうか?? 設定マニュアルからもいつのまにか消えていました。

昔の設定のままの人のためにポートなどはサクラ側で残しておいてくれてたのかもしれません。
SSLがなかった時代はこれでエイリアスがあったからよかったのでしょうが、厳密にSSL経由でのみアクセスさせようとすればエラーになるのもわかりますね。
サブドメインのワイルドカードまで使えるSSLは高いのでケチった結果とも言えます。

なので、送受信については共有SSLをつかうことにしました。

サーバーアカウント.sakura.ne.jp

Googleにもたせていたメールアカウントのパスワードとかは忘れてしまっていたので再発番。 なんかそれでアクセスできる設定になってるなら、popもsmtpも独自ドメイン.comだけにすりゃ自前SSLだけでアクセスできるような気もするのだけど、サクラのマニュアルに書いてなかったのでやりなおすのもめんどくさいので、別にメールは共有SSLでいいやーとなった次第であります。

さんこう

デフォルトの TLS およびその他の新機能を使って Gmail のメール セキュリティを強化する
2020年4月8日水曜日
gsuiteupdates-ja.googleblog.com/2020/04/tls-gmail.html


coinhive公開意見書の事前公開


coinhiveについて意見書なるものが求められてると聞き、ちょろりと書こうと思ったのだが、技術者と呼ぶにはロートルなので公開する。それは変じゃねってあったらコメントつけてください。・・・ロートル。英語かとおもったら老頭児、中国語なんだね。らぉとぅ儿か。びっくりだ。

私は誰か

2000年初頭、新卒から技術職が50~100名程度のちいさなソフトウエア開発会社にプログラマー技術職として勤めていた。スペシャリストや部長職などを経て、子会社の役員CTOなどもやったが、ご多分に漏れずSIerと呼ばれるシステム開発業界隈から身を遠ざけ、緩く喫茶や小売業をまったりやる個人起業をし十数年になる。

技術職であった期間より、もはや商店街で部長をやっている期間のほうが長くなり、プログラマーとしては疑問符がつくようになってしまったが、おかげさまでICT界隈の技術には理解がない人達へ説明をする能力は得ることができた。

自分で手を動かし、ある程度のソフトウエアは設計から実装まで仕上げることができたが、前線からは離れているので先端技術者としてのスペシャリティはない。だが、プログラマーが集まるコミュニティの運営をしているので技術者の声は今でも聞くし、三鷹市界隈のICT事業者をあつめた協会の理事もやっているので経営者の声も聞く。ついでに言うと三鷹市の情報推進の委員などもしているので行政の意見も聞く機会があり広範囲に情報は得ているほうだと思う。

そのような観点からcoinhive騒動についての意見を申し上げたい。
なお、これからの意見は会社や組織を代表するものではなく、あくまで個人の意見である。おさだまり文言。

論点項目

・行為の主体
・刑法としての解釈
・coinhiveの評価と程度の問題

行為の主体

商店主にプログラミング言語を説明しようとしたら、ぴ~ひょろろというFAXが発する音のようなものを発声するのだと言う人が居たが、これを読まれる方は、そのような層よりはパソコンなどの操作について馴染みがあるものとして話しをすすめる。

プログラミングとは、簡単に言えばコンピューターが動作するにあたり、どのように挙動するかの指示を列挙した指示書のようなものである。

指示の中で別の指示書を呼び出したりするのが最近のプログラムでは常なので、そのため連鎖反応のように自動で実行されているように見えるものもあるが、あくまで実行の主体者は辿れば最初にそれを実行した者に行き着く。

正常系であれば実行者が居て、それを実行可能な環境が揃うことで実行結果を得ることができる。
異常系であれば機械などハードウエアの異常が不随意に発生したもの、または製作者も意図していなかった挙動、実行者の意図を欺いて実行されるものなどが考えられる。

多くの人が無自覚におこなっているホームページ閲覧という仕組みの正常系を技術的に考えてみると、閲覧者はまずホームページを保管しているサーバーへ閲覧したいという要望(リクエスト)を投げる。サーバー側はそれを許可し閲覧者にアクセスさせる。閲覧者はそれを自身のパソコンなどに持ち帰り自身のマシンで指示書を翻訳し実行し、閲覧を行う。

ホームページの提供者は閲覧者がいつ来てもよいように、家(サーバー)の鍵(ポート)をあけて待機状態(リッスン)にしておき、ときにはそのリクエストに応じてサーバー側で演算して実行結果として渡してあげる必要がある。最初に問い合わせをし閲覧許可の要望を投げるのも、それを実行するのも行為の主体は閲覧者である。閲覧者の指示を契機にしておこなわれる。

刑法としての解釈

いわゆるコンピュータ・ウイルスに関する罪(不正指令電磁的記録作成等)についてであるが、coinhiveはこの定義からは外れるものと考える。実行形態を見ても実行結果をみてもそもそもコンピューターウイルスの定義に当てはまらない。

coinhiveなどを利用し、ホームページ提供者でもない第三者が他者のホームページを書き換えマイニングスクリプトを設置したり、閲覧者がリクエストもしてないのに保存させたり実行させたり、なにかを騙り詐謀しユーザーにマイニングをさせるマルウエアやウイルスは存在する。しかし、それらのものと今回のWEBデザイナーがWEBサイトの部品としてcoinhiveを設置したものは手続き的にも技術的にも明確に区別できる。

今回の場合、ホームページ提供者が設置したものを閲覧者がリクエストして、それに応じてファイルへのアクセスを許可したものであり、またそれを実行したのも閲覧者である。

閲覧者はそのホームページのURLにアクセスすることで構成する索引(インデックスファイル)を取得し、その索引から閲覧するために個々のファイルを取得する。閲覧者の意図はホームページ全体を完全な形で閲覧することを前提としており、その意図に添った動作を行っているといえる。

プログラムや提供されるホームページを著者の著作物だと考えれば、著作者人格権うち同一性保持権は適応されて然るべきであろう。公衆送信権をサーバーに委譲しているに過ぎない。

もし、閲覧者の意図がホームページの完全な状態の実行ではなく、作者が意図しない形で閲覧をしたいのであれば、その閲覧者の意図に沿ってHTTPリクエストを逐次段階的に処理していく必要がある。TCP/IPのプロトコル(決まりごと)はそれを可能にしているが、手順が煩雑になるために、閲覧実行時(ブラウジング)に実行権限を委譲することでブラウザーがリクエストと応答をまとめて代理処理されている。

一般的なホームページ閲覧ソフト(ブラウザー)はjavascriptの実行を許可しない設定に切り替えることができるし、httpプロトコルをブラウザ任せにしなければ、その取捨選択をおこなう機会は失われていない。
インターネットを構築する技術仕様はRFCで公開されており、それに則ったやりとりの範囲でおこなわれる。しかも今回の件は、ブラウザが許可した範囲内でしか動けないJavaScriptの話しである。ページを立ち去れば終了するのだ。

仕様上そのようにはなっていないので、閲覧者側に気がつく機会は提供されなかったものとは言うことはできない。その機会をブラウザに権限委譲することで煩わしさから逃れているのだ。現代において一般的なホームページ上でも数えられぬほどのJavaScriptが動いている。もし、chormeブラウザを使っているならF12ボタンを押せば、現在どのようなファイルを取得して実行していて、ネットワークの状態などを検証することは容易に確認することができるだろう。確認してみるといい。そのうちいくつが閲覧者の意図に沿ったものだろうか?ホームページ設置者すら意図していないものもあるかもしれない。

coinhiveの実行はホームページの閲覧には不必要な挙動であり、正当な理由のないものとの意見、解釈もあるだろう。だが、ホームページ提供者の意図を閲覧者が定義することはできない。製作者が意図する完全な状態はcoinhiveを含むものとする著作者意図を閲覧者側の閲覧したいものの意図に沿わないから不正な電磁的記録であるとしてしまう危険性を今一度考慮する必要がある。

著作物と閲覧者が異なる人物である場合、閲覧者の意図を過不足なく斟酌して、著作者が著作物を用意することはできない。閲覧者の意図によって、その内容が不正指令電磁的記録になるのであれば、その影響範囲は現行のインターネット上の仕組みの根幹にも影響する。

インターネット初期の頃、ホームページを開くと自動で音楽が流れるようなサイトも多くあった。現在の流行りはサイトを閲覧するために動画広告を強制的に視聴させるようなホームページも多い。
これらの動画を流すために、見えないところで広告をより効率的に見せるためのトラッカー、アクセス解析などが動いている。情報を取得しユーザー上のマシンリソースを使用している。coinhiveと、広告などとの違いを社会的コンセンサスという不確かな定義のものの上に置いてしまうと、技術的にはそれらを区別することはできなくなるだろう。 欧州のGDPRのおかげでcookieなどはオプトイン形式になり可視化されつつあるが、 認識されていないだけで見えていない広告関連の仕組みは実に多い。ユーザーには一見認識することができない非常に多くの構造体が目に見える仕組みを支えている。

ホームページ提供者が閲覧者のマシン演算力をより多く必要とする部品を設置することにマナーとしては諸説紛々あるやもしれないが、これをもってコンピュータウイルスの定義を当てはめるのは定義を拡大しすぎである。

coinhiveの評価と程度の問題

ホームページの維持管理のためには、閲覧者が24時間いつきてもいいように電気をつけて待っている必要がある。経済的利益の確保はホームページ更新の動機になるばかりでなく必要な経費であり正当な理由の範囲内として考えることができる。 というより設置者が得られる利益も、閲覧者に見込まれる不利益もはたして公の議論にあたいするほど影響があるほどボリュームがあるものとは考えられない。いったいいくらの経済被害がこれによって生じうるのか。捜査や公判維持にいくらの経費をかけているのか。

coinhiveが問題となったのは、おそらくは、ホームページ改ざんなどで他人のホームページにそれらを埋め込むウイルスが流行ったことによりウイルス対策プログラムのパターンファイルに登録されたことをきっかけにウイルスと誤認されたことをきっかけにしているにすぎないように思う。また、仮想通貨のマイニングといういかがわしさが拍車をかけているのだろう。

だが、いちWEBデザイナーがホームページの部品として設置できる程度のものに、刑法犯に問うべきような過失や未必の故意がありえるだろうか?

いったい閲覧者に幾らの経済的損失を与え、幾らの不当な利益を得たというのだろうか? ホームページ閲覧中の滞在時間、javascriptがブラウザ上の割り当てたメモリ内とCPUの優先順序で動ける範囲で消費できる電気料金?数円、よくって数十円、どんなにがんばっても数百円もいかないだろう。見込める利益も予見の範囲、たかが知れている。

coinhiveで逮捕されたと話題になった当時、評価のため、オーストラリアのユニセフが設置したcoinhiveにアクセスしたり、通常のサイトと閲覧比較をしてCPU利用率などを比べてみたことがある。

下記は、量販品のメーカー製パソコンでCPU50%でcoinhiveを回したときのCPU可動遷移率だ。

次の画像は動画が再生される毎日新聞社のニュースページのCPU可動遷移率。

CPU稼働率の上限を制御できる分、coinhiveのほうがまだ閲覧者のPCには優しい。 電気泥棒だなどと非難する声もあるが、動画広告は閲覧者の時間泥棒である。通信帯域も食うことから、中継機の電気も食うし、その後のハードディスクの保存量も食う。 個人的にはホームページ閲覧の滞在時間なども勘案すればCPU利用率を2-30%ぐらいに絞ってくれるのならば動画広告より歓迎すべき未来のようにも思える。

画面のはじっこでチラチラ変な動画がぴょこぴょこしていたり、得ようとしている情報とは関係ないPR情報が記事に割り込んでくるのは苦痛なので、こういう収益化手段の遷移は歓迎したい。

たしかに仮想通貨マイニングはうさんくさい。coinhiveも終了した。だが、分散コンピューティングは将来は公益に資する可能性が大きくある。

いま人類を悩ませている新型コロナウイルス(COVID-19)。この解析に分散コンピューティングのFolding@homeプロジェクトが動きはじめている。
だがどうだろう、もし誰かが、これらをブラウザ上でも動くようにするプログラムを書いて、ホームページ上に置くことでこれらの解析に貢献できるものを作ったら? 日本では設置した人も、設置できるコードを書いた人も刑事罰の対象として逮捕されてしまうのだろうか。もしされないのであればその違いはなんであろうか。罪刑は法律が規定する範囲で運用されるべきもので、刑法犯については特に慎重に検討願いたい。

その他引用とか参考とか

BOINC is used by many volunteer computing projects.
boinc.berkeley.edu/projects.php

【寄稿】コインハイブ事件 意見書ご協力のお願い
www.hacker.or.jp/coinhiveopinion/

違法マイニングとされたcoinhiveの法と技術のはなし
kuippa.com/blog/%e9%81%95%e6%b3%95%e3%83%9e%e3%82%a4%e3%83%8b%e3%83%b3%e3%82%b0%e3%81%a8%e3%81%95%e3%82%8c%e3%81%9fcoinhive%e3%81%ae%e6%b3%95%e3%81%a8%e6%8a%80%e8%a1%93%e3%81%ae%e3%81%af%e3%81%aa%e3%81%97/

新型コロナウイルスの解析、分散コンピューティングで誰でも参加できるように 「Folding@home」が対応
www.itmedia.co.jp/news/articles/2003/15/news015.html