月: 2020年4月

法人口座の開設完了通知が２つの銀行から届いた。これでようやく、会社設立の指南書にあるすべてのタスクが完了。

法人口座。なんかカッコいい！　というか、無いとカッコがつかない。この開設手続きが今回の一連のタスクの唯一で最大のヤマだと思っていた。実際、資本金を１円にしなかったのも、このウェブサイトを作ったのも、法人口座を得るために最低限のカタチは整える必要があるという指南に従ったからだ。

定款の認証や法人登記も一応審査的なものだが、要は記載事項に誤りが無いこと。あとは反社で無いことを確認されるだけだ。私は非社会的な面があるが反社会的では無い。公証人さんの認証証明書には「審査の結果」とあるが、認証文は「…は、設立される法人の実質的支配者となるべきものが何の某である旨及び同人が暴力団員等でない旨を申告した。…。よって、この定款を認証する。」というだけのもので、実際のところ口頭で申告したわけでもなく、尋問のようなものをしてくれるわけではなかった。単に暖かくおもてなしされた感じだった。認証料５万円也。

一方、銀行での法人口座は審査の結果断られることがあると聞いていた。それで、法人口座開設の審査のために求められる書類には、事業内容の説明を（とても真剣に）数行で書いたが、これは会社名を考えるのに次いで、脳みそを使った作業だった。しかし、そこに嘘八百はったりを書いたとしても「審査」で峻別できるものだろうか？とても不思議。まあおおおらか銀行だからこそのユルさなのだろう。

うちは信用力を必要とするような会社ではないので、どんな銀行でも構わないのだが、ここつくば、茨城といえば個人的に長く口座を持ってきた常陽銀行が心のふるさとだ。地域に根差した活動をする予定はないけど、あそこに法人口座を作れれば何だかうれしい。

お役所は選べないが、銀行は選べる。２つの銀行に同時に申し込んで比べられたのは面白かった。法人口座の場合、申し込み時の記入事項や提出物が結構ある。しかもケースにより要・不要がわかれる。一方の銀行の申し込み書類はやや混乱しており、他方はとてもわかりやすく洗練されていた。洗練銀行のほうは、イマドキ当たり前だがメールにもちゃんと電子署名がされていて、メールのあて名も「当社の正式名称＋さま」とあり好感を持った。他方の銀行は電子署名もされておらず、あて名は「カ）フリガナ様」と来た。まあある種、より実務的なのかも知れない。それぞれ個性があって面白い。

なんにしても当面、お金が出ていく口座でしかないけど。

2020-0424 sato@izmoh

Macに触れたのがきっかけで、つい昔の事を思い出してしまう。URLと言う表現形式の成長期に提案された dataと言うスキームもそのひとつ。

URLは http や ftp と言ったプロトコル名（つまりアクセス手段）と、//ホスト名/パス名、という「リソースのロケーション」つまりアクセス先のアドレスを表す表記法・手段（scheme）だ。その中のひとつとして、リソースのデータ自体をURLに表記する方法として提案されたのが「data」だった。似ていて対極にあるものに、抽象的にメールアドレスを表記する mailto （転送手段も規定していない）があり、現在広く使われている。

CPUの命令アドレスフィールドに即値（immediate value）を持たせられるのは当たり前だし、変数と定数とかポインタなど、その他の類想からも、コンピュータ分野で育てば当然考えられるべき事なのだが、当時はなるほど（膝をポン）と思った記憶がある。
一般的にも「名は体を表す」と言うが、体自体を名前にしてしまうジョークや商品名は昔からある。data scheme はまさにそれに相当する。

以下に具体例を示す。上がデータ（gifイメージ）のナマ表現で、下がそれをブラウザが解釈して表現した結果だ（画像は、data scheme 提案者のLarry Mainster 氏のポートレート）。

<IMG SRC="data:image/gif;base64,R0lGODdhMAAwAPAAAAAAAP///ywAAAAAMAAw AAAC8IyPqcvt3wCcDkiLc7C0qwyGHhSWpjQu5yqmCYsapyuvUUlvONmOZtfzgFz ByTB10QgxOR0TqBQejhRNzOfkVJ+5YiUqrXF5Y5lKh/DeuNcP5yLWGsEbtLiOSp a/TPg7JpJHxyendzWTBfX0cxOnKPjgBzi4diinWGdkF8kjdfnycQZXZeYGejmJl ZeGl9i2icVqaNVailT6F5iJ90m6mvuTS4OK05M0vDk0Q4XUtwvKOzrcd3iq9uis F81M1OIcR7lEewwcLp7tuNNkM3uNna3F2JQFo97Vriy/Xl4/f1cf5VWzXyym7PH hhx4dbgYKAAA7" ALT="Larry">

ここにはきっちりと、当時確立していたMIMEのデータ型名と、base64エンコーディングが、やはりWWWの初期に確立していたHTMLのタグIMG SRCの中に表現されている。だから、それら極めて基本的な標準仕様に準拠し、gifを表示できるブラウザなら、必ず表示できる表記だった（はずだったが、多くのブラウザの実装ではそうではなかった…）。

data scheme には実際、特に当時の未成熟なブラウザの状況もあり、色々な応用が期待された。data:表現が提案されたのは1997ねんで、翌1998年に正式にRFC2397となった。私はこれを使って、ブラウザによってサポートされていない文字や画像を埋め込む事を考えた。当時書いたデモ用のページが今も残っている（というか、動態保存している　笑）
URL: http://www.delegate.org/delegate/sample/data-url.shtml　↓

これは、ブラウザローカルに解釈できる事がメリットのはずの data:表現を実装していないブラウザのために、リモートの http:サーバでそれを補ってやろうという、分かってはいたが本末転倒の試みであった（実際、ウケなかった）。そして、data がきちんと実装されるより前に、ブラウザの多言語対応や各種イメージ型の表示能力が成熟し、当時私が考えた応用の目的は失われた。

その後の2014年の追記にあるように、やがてほとんどのブラウザがこれを実装した。ただ、私の偏見から来る記憶違いかもしれないが、MSのIEの対応は遅かったように思う。

以下は2020年4月現在の、５大メジャーブラウザでの data scheme の表示。いずれもちゃんと表示できている。

右下は昨今流行りのQRコードでこの data を表現したもの。残念ながら、iPhoneのカメラアプリは、これを認識してくれなかった（笑）

ここまで長く、これを書いたのは、data scheme という歴史に埋もれ忘れ去られた表記を、今も全ての主要ブラウザが解釈できるという事実に基づく、新しい応用があると考えているからだ。応用するのは、良い人かも知れないし、悪い人かも知れないが…

たとえば、文字にしてもUnicodeでは足りないケースも多いはずだ。そういうニッチは今後も完全に無くなる事は無い。ニッチをグローバルなインフラからサポートするのはコストに合わない。

インターネットは100倍早くなったかも知れないが、一方でユーザは100倍短気になった。それに、いくらネットワークの片道スループットが上がったとしても、往復レスポンスは光の速さを超えられない。途中の停車駅だってそうは減らせないだろう。実際、ギガビット・インターネットのRTTは当時の10倍程も高速化していない、今もミリ秒の単位のようだ。

ウェブには１ページを表示するのに数十回のHTTPリクエストが発生するのはざらにある。細々としたイメージデータを多数取得するためである場合が多い。それらは、転送時にdata:にして埋め込んでやれば、一発転送で終わる。（いや、それをDeleGateにやらしてもらう必要は無いけど 笑）。同じデータを繰り返し送るとい無駄は発生するが、データの素性を知っていれば自動的・機械的なトレードオフはできる。長期的に保管するにしても、埋め込み型が有用なケースも多いだろう。

data scheme を IMG SRC 以外でも使えたとしたら、何が（何か）起こるか。応用は、全てをひとつのHTMLファイルに押し込む手段としてだけでは無い。MIME multipart 型と同様、古びた骨董の中に新しい可能性が埋もれている可能性はある。普通に普及しているアーカイブ形式をファイルシステムとして解釈する手法との優劣かなと思う。形式的には格好良くは無い。XMLが、ASN.1 があると言う人もいるかも知れない。しかし実現上の強みは、すでに data scheme は（長い時間をかけて）実装普及が完了していて準備OKであり、シームレスな移行かトランスペアレントな高速化が可能な事だ。

…と、つい昔のエキサイティングな時代を思い出してエキサイトしてしまった…

インターネットに破れて死んだOSIが電子証明書の中に残して行った形見のような X.509 を思いつつ。

2020-0423 sato@izmoh

---

2020-0423 追記
Wikipedia に比較的最近（2018年）に更新された data scheme のページがあった。さすが、素晴らしい（個人的にWikipediaには献金しているが、会社で寄付したら控除してくれないかな 笑）。それによると、インラインイメージの埋め込みによって転送効率を上げられる、一方キャッシュの有効性は落ちる、と言う認識は元々共通のもののようだ。また元のRFCから指摘されているように、各種セキュリティ上の問題ははらんでいる。MSでの対応に関しては「IEとEdgeでは未実装の部分がある」ともあるので、私の偏見ではなかったようだ。

data:表現の用途としてはインラインイメージ（IMG SRC）以外にも、各種スクリプトのデータのソースとして利用する例が挙げられている。メールに画像を表示する利用例が挙げられているが、現状、サムネールなどを送るのに利用されていたりするのだろうか？

このWikiページを斜めに読んだが、次の言及に目が止まった「他にサポートされないであろうと思われる要素に、電子メールクライアントのマルチパート形式やmessage/rfc822などがある」ピクピク！

え？今日、電子メール（MIME)で添付ファイルを送るのには実際、マルチパート形式が使われているし、メール読み書きツールはそれを理解するから成り立っている。なので、これはウェブ用の閲覧ツール（ブラウザ）における状況を指摘しているのだろう。data scheme に関する記事の中での言及なのだから、data:multipart/mixed,--xxx... と言った表現の事を指しているのだろう…

ひとつ前の文から読み直すと「ブラウザなど、多くの処理環境ではメタデータ、データ圧縮、コンテントネゴシエーションのような複雑な処理はサポートしないであろう。他にサポートされないであろうと思われる要素に、電子メールクライアントのマルチパート形式やmessage/rfc822などがある。」となっていた。

HTTPサーバとクライアントのやりとりが無い環境での使用も想定されるので、ネゴシエーションは無いだろう。と言うかそれは、ブラウザがローカルなHTMLファイルを開く場合でも同じ事だ。編者が言いたいのは、HTTPネゴシエーションでクライアントが受け取りを拒否したデータ型のdata:を、サーバが削除して返すことはないだろう、と言う意味だろうか。

また、URLの長さの制約からして、その他に言及されている機能がdata:表現においてサポートされないのも仕方が無い。ただ、複数のdata:と言うかリソースを連結してひとつのデータとしてみなす、分割パートのような一般的な表現方法が規定されていれば、そうとは限らない。

あるいは連結とは逆に、一つのデータの中の一部を切り出す、たとえばあるデータの中での開始オフセットとサイズとか、HTMLやXMLの中の名前のついたエレメントを参照するとか。これがあれば、何もdata:に詰め込む必要はない。DeleGateのマニュアルはそれを試行したものだ。一つのHTMLファイルの部分部分を、単独のHTMLのようにも表示する事ができる。

つまり、ひとつのファイルに複数の（URLで識別可能な）リソースを詰め込む事による利点は実現出来ている。また、複数に分割してHTMLを書くよりも、一枚で書いて、色なビューで切り分けて眺められる方が便利だった。だが、この方法は、ウェブサーバがDeleGateで無いと、サポートされない X-)

要するに、URLで識別されるデータの論理的な単位と、実際のデータの物理表現が１対１になっている事が根元にあるように思う。それは、ひとつのURLのデータをGETする毎に、ひとつのTCPコネクションを貼っていた、Keep-Aliveが出来る前のHTTPを思い出させる。

そもそも、MIMEフォーマットがHTTPのメッセージ形式として採用された時には、マルチパート型がそのような役割を果たすのでは無いかと期待したが、そうはならなかった。その後この分野をフォローしていなかったので、現在そのような役割を果たす標準形式、何か別のマークアップ言語なりコンテントタイプなりで、そう言う機能が存在するのかも知れない。

さて。それでは、昨今のウェブブラウザは、URLとしてのdata:multipart ではなく、HTTPのメッセージボディとしては、Content-Type: multipart を処理してくれるのだろうか？と一瞬期待して、試してみた（↓）。メール（左上）のソースをGmailのメッセージダウンロードで .eml に吐いて、ドラッグ＆ドロップして各ブラウザに食わせた。結果は残念ながら、きちんと表示してくれるブラウザはなかった。無視または外部のブラウザ（メールツール）にまる投げするのが Firefox と Safari、一応マルチパートを解釈するがプレインテキストだけ表示するのがChrome, Opera, Edge だった。↓

それにしても、メールツールとウェブブラウザが一体化しなかったのは不可解だ。ウェブブラウザたる Mozilla から派生し、おそらくエンジンを共有しているであろうThunderbird が、なぜウェブブラウザも兼ねないのだろうか？

もし両者が統合した形で発展していたら、当然マルチパート形式をウェブブラウザは理解するだろうし、それによって開けるデータ転送性能向上や新しい応用があったと思う。

ウェブサーバで提供される「ウェブメール」にしても、ブラウザでローカルに見た目が同じものを作ることはできる。逆に、ウェブ上の各種のフォーラムやらこう言ったブログのようなものを、メールツールからメールと見做して、つまりメールと同じ操作で読み書きすることも出来るはずだ。新着メール検出にRSSを使うことも出来るだろう。

そのためにはもちろん、データの識別子とデータ形式の標準化が必要だ。それがないから、有象無象のウェブメールや、ブログ形式が作られていて、わけがわからない。 HTMLにスクリプトやらが加わった表現能力が高過ぎるのだろう。まあ、いろんな創造性が発揮されていると言う見方は出来る。

とは言え、今ではHTTPサーバがバックエンドにMySQLなどのデータベースを備えるのが普通らしい。であれば、データベースの検索の結果出てきたデータを、ウェブとして読むか、メールとして読み書きするか、選べると言うことで良いのかも知れない。

電子メールにはURLでは無いが、MessageーIDと言うユニークIDがある（ユニークだと言う保証は無いが。電子ニュースではそうだった）。メールの引用関係はハイパーテキストを構成している。メールの特長の一つは、確実な日付順に情報を並べて見れることだ。もしそれができなかったら役に立たない。Message-IDの形式を標準化して、日付を内包する形式を定めれば、データベースを検索した結果をメール的なビューに食わせる事が出来るだろう。もちろん、メールヘッダ（MIMEヘッダ）全体をキーにするのでも良い。

プライバシーの問題があるから、ひとりにひとつのデータベースにするか、暗号化してデータベースに格納する必要はあるだろう。ただ、ヘッダの検索だけでなく、本文まで全文検索をするには暗号化はよろしくないとは思う。と言うか、全文検索エンジンはいわゆるデータベースでは違うか。

色々書き散らしたので、的外れな事が多いとは思うが、一言で言えば、現状のウェブとメールの関係、ウェブサーバとメールサーバ、ウェブブラウザとメールツールの関係は、どうも納得できない。あちらでは出来る事が、こちらでは出来ない。不便に感じる、と私は言いたいのだろう。

2020-0423 sato@izmoh

---

会社を設立後に速攻で行うべきことは法人として社会保険に加入することで「設立後5日以内」に担当の役所（現在は年金事務所）に届け出すべしとなっています。被保険者となる社員・役員の側としても、健康保険証を携帯してないのは不安なものですから、これは大事です。（少額なら全額払って後で清算でも気になりませんが）

あれ？でも設立日（法務局への登記書類提出日）から登記が完了するまでの日数は不定だし、届け出書に記入を求められている法人番号は登記が完了してもらえるわけです。当社は4月1日に設立、登記完了が3日でした（これすら正式には法務局は教えてくれないのですが、別件でのちょっとした電話のやりとりの後、担当のお姉さまがこっそりもやっと…）。まあ、法人検索サイトで見ればわかるんですが、これにもちょっとタイムラグがある。検索して登記完了が確認できたのは夕方でした。

2020年4月3日は金曜日でしたから、土日をはさんで6日月曜が、登記から5日目にあたります。それが公式デッドライン。ですが、例えば登記が年末年始やゴールデンウィーク前日だったらどうなるんでしょう？規定には、5日間ルールにおいて役所の休日を除くとは書いてないのです。

ぱっと見にどうみてもおかしなルールです。それで、年金事務所に電話して聞いたところ、まあそういう杓子定規な事は無い、みたいななまぬるい回答を頂きました。大丈夫なのかなこの制度（笑）

それはともかく、一日も早く保険証が欲しかったので、ネットで検索して知ったとおり、届け出書類（保険新規適用届）を地元の年金事務所ではなく埼玉のセンターに郵便で直送。かつ、被保険者として私の申請も同封（これは知っててよかった。手間と所要時間の大幅節約）。自動振替え申請は銀行に行くのが面倒だったので（てかまだ法人口座無かったし）見送りでした（クレジットで払えるとよいのに…）

あとは保険証が届くのを待つのみですが、4月は新規の申請が集中するので、かなり時間がかかるとの事。次にお医者さんに行くまでに間に合うかしら？と心配していたのですが、その後本業に没頭しているうちに忘れていました。会社への適用通知（株式会社なので強制適用事務所です）については、4月13日付確認のものが届いていました。

そして今日、会社の郵便受けを見ると、協会けんぽからの封書が！
中にこれが入ってました↓

おお、これがその噂に聞いていた水色の保険証かあ。燦然と輝く「番号１」。すばらしい。でも、いつかは違う色のを持てるといなあ。 夢のITS健保組合 （＾－＾）。

というわけで、届け出（郵送）から10日間で交付され、保険証カードが手元に届いたのは2週間後。思ったよりスピーディでした。

あとは、なんといいますか、会社設立（にかかわる単純作業の分）の手引きやサービス等、ネットで検索して出てくる多くが、こけおどし、ひっかけ、我田引水、知らしむべからず依らしむべしだと感じました。わかりにくいのは、ルールのほうが変だからです （屋上屋九龍城状態時代錯誤） 。実際にはとてもカンタン（面倒だけど高次脳機能が不要という意味で）だったし、わからない事があれば担当部署に直接出向くか電話して聞く（電子メールという文明がまだ導入されてない、もしくは意図的に回避されているらしく）のが最も良い（おおむねが驚くほど親切。特に女性の方々は）と思いました。

登記においてひとつ失敗したなと思うのは、なにげにメニューを選ばされ電子公告のURLを某社のサイトにしてしまったことです。これを変更するのはちょっとまたひと手間ですが、まあそれも一つのエンタメかなと。

それはそうと、健康保険証も免許証も身分証も何もかも、スマホにデータとして入れて使えると良いですね。今で言えばQRコードをぴっとかざせばOK。 紛失や盗難で困ることもないし。 使用時に指紋認証か何かすれば良いから、現在よりもずっとセキュア。どこで使われたか立ちどころにわかりますしね。便利すぎるものはセキュリティ・プライバシーの落とし穴、という一般則はありますが。まあ遅かれ早かれそういう世界になるんじゃないですかねえ。

2020-0422 sato@izmoh

まがりなりにも株式会社たるもの、インターネット接続がメガ単位ではいかん。というような動機ではなく実際の必要性から、遅まきながら回線を1ギガにしました（これまで大家さんの100メガにまがりしてました…）

映像配信など趣味の世界ではもう当たり前の世界なのでしょう。おかげ様で、ギガビットのインターネットなんていうひと昔まえには夢のようだったものが、月数千円で使えるようになりました。

必要性、というのは、遠隔のネットワークドライブを使うためです。経営の方針から、わが社の中央コンピュータに内蔵するディスクは250GBのSSDのみとしています（10万円未満で買えたWin10 Pro入りのレノボ機（これって最高！）の仕様でした）。

実際のところ、わが社で頻繁に使うファイルの総量はその程度のもので、他は外付けポータブルでもリモートであっても構わないのです。クラウド上の各社ドライブは、月1000円位の本来サービスに、おまけで1TBついてくる時代になりました（MS365のおまけOneDriveとか）。もちろんクラッシュの心配もないので、自前のバックアップも不要です。

ただ心配なのがアクセス速度です。10数年前、ギガビットLANの到来とともに100MB/秒でのアクセスできるようになり、ローカルディスクと比べて大きなストレスも感じずに使えるNASがブレークしました。それは100Mbpsの時代には無理でした（まあふた昔前はディスクI/Oは10MB/秒という時代でしたので、ぜいたくな話ではあるのですが）

昔話はともかく、速度を図ってみました。まず100Mbpsネット。

なかなかのものです。看板に偽りなし。実際これを2年くらい使いましたが、ストレスを感じたことはほぼありませんでした。少なくとも前の職場のネットより快適で（＾－＾）ﾉｼ
そして、ギガビットネット。

おおー、立派立派。それにしてもこのfast.comって偉い。このユーザインタフェースは素晴らしい。しかし、いったいどういう経路になっているのでしょう？

$ tracert fast.com
Tracing route to fast.com [2600:1417:5d:280::24fe]
over a maximum of 30 hops:
1 <1 ms <1 ms <1 ms its-more [240b:11:cc01:0:0123:0123:abcd:abcd]
2 2 ms 2 ms 5 ms 240b:11:cc01::fffe
3 * * * Request timed out.
4 * * * Request timed out.
5 * * * Request timed out.
6 5 ms 4 ms 4 ms 2404:9200:225:1::1
7 5 ms * * 2001:268:fa00:29c::1
8 * * * Request timed out.
9 5 ms 5 ms 4 ms 2001:268:fc02:52::2
10 4 ms 4 ms 4 ms g2600-1417-005d-0280-0000-0000-0000-24fe.deploy.
static.akamaitechnologies.com [2600:1417:5d:280::24fe]
Trace complete.

どこまでもRTTが5msというのも、世の中が全部IPv6になっているのにも、今更ですが驚きです。Windowsにtracerouteがあるというのにも（＾－＾）Cygwinで見つからないのでどうしたのかと思いました。

とはいえ、基礎的な通信速度がいくらすごくても輻輳したりなんやかやで律速されて、実際のデータ転送速度は数メガバイト/秒程度（良くても50Mbps以下）がせいぜいというのはありがちな話です。それで、まずは Google Drive (File Stream) で測ってみました。

すると驚きの結果が！これこのような↓

まじで250Mbps出てるですけど…
（いやそもそもこの250って、手元のルータで律速されてやしまいか？）

送り込んでいるデータのサイズは1GBです。圧縮マジックにかからないように乱数を書きこんでいます。（openssl rand 1000000000 > xxx。なお、このCPUでの rand の生成速度は 500MB/秒以上です）。当然ローカルにキャッシュはしているでしょう。見た目に書き込みが終了してから実際に転送が始まるまでに10秒くらい何かしています。

もっとでかいデータを書いてみるとどうかな？とりあえず rand は 32ビット整数の縛りで 2GB しか生成できないみたいなので、生成したファイルを複数 cat して送ってみましたが、やはり回線の使用状況は同じようでした。あとは、ランダムアクセスに耐えるかというところですね。まあ、Stream って名前なので、過度の期待はしませんが…

ただいずれにしても、回線の速度をフルに使いきっているのがすごい感じ。UDPなの？

では他社はどうか？つぎは OneDrive。なんだか凸凹してる↓

いかにもMicrosoftらしく、何か余計な考え事をしているようです。

---

そしてDropbox。ほとんど200Mbpsに達せず、気合が足りない感じ↓

---

では複数並列にやったり、各社ドライブ間でやり取りするとどうなるでしょう？

★★★★★　瞬間最高400Gbps出ました　★★★★
疑ってごめんなさいルータさん。測定の誤差というレベルではないようです。

各種アプリや文書データだけなら、ローカルの256GB SSDに収まりそうなんですが、多数の仮想マシン用のディスクを収容するのは無理です。なにしろ推奨最小が20GBですから。そこでクラウドに置くことにすると、スナップショットを取るのにかかる時間はなんとかなりそうですが、仮想ディスクから実ディスクへのランダム読み書きがどの程度発生するのかが心配です。わが社のマシンは、上の画面にあるように、メモリも8GBしかないからそれはもうー

ディスクの sync 中に手元のPCがクラッシュしたりネットが落ちたりしたらどうなるんだろうかというのも心配というか、興味があるところです。上の画面のように、当社はVMwareユーザなのですが、VMwareの仮想マシンの仮想ディスクとか最近の版でもカンタンに壊れてしまうので、実マシンでのネットドライブに限ったことではないですが。Hyper-Vはどうなのかなとか。それが Windows Pro にした理由の一つでしたし。

ギガビット・インターネットは実用として重要ですが、とりあえずそれ自体がとってもエンタメです。というか、先週４種類試した、WebDavやSFTPをベースにした仮想ドライブソフト達ががあまりにもダメダメだったので、ネットワークドライブというものに疑念を持ってしまっていましたが、今日、大手のクラウドドライブの実力に頭が下がりました。

単なるファイル転送プロトコルとしてのFTPの役割は完全に終焉しました。各種バイナリの配布（特に isoファイルとか）にしても何にしても、リードオンリーなファイルはHTTPで配るとかでなく、クラウドのドライブにぽんとおいておけばよいのではないかと思われます。改ざんしたファイルと区別の付かないハッシュ値とかじゃなく、ちゃんと電子署名して。

2020-0422 sato@izmoh

---

その後いくつかの文書署名サービスをちょっとずつ試してみましたが、一言で言えば期待はずれでした。私が期待する使い勝手において致命的に感じるのは、まず署名の応答が遅い and/or こちらの手間がかかる。そして不安感。クラウドサービスとの連携型では、なにやらサインアップさせて他のサービスと抱き合わせてくるし、こちらのアカウントを握られたり機微なコンテンツへの全権アクセスをさせる事の不安感があります。

試したものの中では以下の好感度でした(※個人の感想です)

1位：1-2-3 Signature の Upload+Sign
　　- drag&drop のみ / 速い / 手軽 / 安心感
2位： 手元のAcrobatでの署名
　　- 使い易くて当然。問題はAcrobatの値段
3位：DocuSign + GoogleDocs
　　- 使い易い。ルック＆フィールはイマイチｗ
4位：Dropbox + Adobe Sign
　　- Adobe得意ののわけわからなさと面倒臭さ
5位：Dropbox + 1-2-3 Signature
　　- 感動するほど応答が遅い。署名に1時間？
6位：Dropbox + HelloSign
　　- 日本語対応してない模様。お豆腐製造機

なお、1-2-3 Signatureは OneDrive と GoogleDrive とも連携してますが、私の場合両者とも長らく大量の機微情報を置いて使ってきたので、怖いから試しませんでした。Dropbox は放置ごみ置き場だったから安心。だけど、何年かぶりに見たら、ユニークですごくいい使い勝手にはなってるようでした。

もちろん、クラウド系のサービスは単に一人の署名ではなく、稟議みたいなフローが定義できるところがミソなんでしょうけれど。ですが私が求めているのはそういうものではないし、世の中の需要も（電子署名の普及後は）一人の（パーソナルな）署名が大半じゃないかと思います。

クラウド系がほぼメールとの組み合わせなところにも、現状、メールが主要な認証基盤としての地位を保っていることを感じさせます。だがちょっと待てよ。署名するためのメール自身が署名付きでなくてよいのものか？(^"^)

2020-0414 sato@izmoh

---

以下はトライアルの過程の画面集です。少しデリケートな内容なので、弊社代表の証明書で暗号化してあります。

1993年は MIME メール (多目的インターネットメール拡張規格、Multipurpose Internet Mail extension）の第一版（ RFC1341, RFC1342）が出された年でもあり、一方（ほどなくMIMEを転送メッセージ形式とすることとなる）WWW（ウェブ、World Wide Web）、HTTP（Hyper Text Transfer Protocol）が勃興した年でもありました。

それらは世の中を変えました。 とっても便利に、同時にひどく危険に。

端末制御コードを細工した無邪気ないたずらメールやファイルは、はるか昔からありました。しかし MIME によるメールのマルチメディア化（特に添付ファイル）とウェブサイトとの連携を悪用して生まれた狂暴な危険・危機は笑いごとでは無く、今日も未だ収まることがありません。

しかし、そのような危機が顕在化した頃には既に、解決策も存在し、広く使われていました。それは公開鍵暗号を使った電子署名であり、そのデータ（たとえばメールやファイル）を誰が作ったものかを証明する技術です。主に使われていたツールは PGP（Pretty Good Privacy）でした。

メッセージやファイル、あるいはさらにその構成要素毎に署名をしてやり、信頼できる署名の無いものは利用（受け取りや開封など）しないようにすれば、全ては解決するだろうし、枯れた技術だからすぐに広まって、この危機は早晩終焉するだろう、と当時は素朴に考えていたものです。なのにあれからもう四半世紀が過ぎても、状況はそれほど改善しておらず、アンチウィルス業が盛んです。

これってマッチポンプなんじゃないの？と思うこともあります（笑）

ウェブやメールを代表とするアプリケーションの通信の世界では、通信路の暗号化や、サーバやクライアントの電子署名（認証）は早くに実現しました。特に SSL (Secure Sockets Layer) のお陰ですね。一方でコンテンツに対する電子署名は遅れていました。

プロフェッショナルが作るものについては、電子署名や暗号化の技術利用が進みました。一方、メールの大半は、素人エンドユーザが書くものです。素人の世界では、自分の書いたメールや資料に電子署名をして送ったり公開したりするためのインフラの普及が遅れていました。結果的に、受け取るほうも、電子署名を利用できない状態でした。

ですが、少しずつ状況は進歩し、インフラは整いつつあります。特にPDFに電子署名を行う技術はかなり普及しました。（領収書も電子署名されていると良いのに…）メールに署名する技術（特にS/MIME）も、多くのツールに実装されています。あとは、いつ大多数のエンドユーザがそれを使うようになるか、ですね。現状、電子署名用のデータをツールにインストールする作業は超カンタンではなく、素人には少し敷居が高いレベルですが、これも早晩こなれて解決するでしょう。

ラストワンマイルは、ユーザ各人が自分の証明書を手に入れるところだと思います。気になる費用ですが、個人の証明書は一年あたり５千円くらいが昨今の最安値のようです。

などと書いている私も最近まで前職にあった頃は、結構センシティブな情報をやり取りするのに、通常メールやファイルの署名は…。相手方も…でしたから。そもそも組織の人間としての業務には、組織の発行する公式な職員証たる証明書を使うべきですし。
ですが今回、自分の仕事環境をまっさらから作るのを機に、電子署名の環境を整えることにしました。それで、キャンペーンにもつられて少しだけ安く、個人証明書を購入しました。（いや、ハンコを押すのも新鮮に感じられていいんですけどね…）

この費用をどう感じるかですね。また、素人（非営利個人）の場合にはあまり問題になりませんが、そのデータを「いつ」作ったのかが、「だれ」が作ったかと同時に重要になります。特に知的財産の保護のために。それを実現しているのが「タイムスタンプサービス」で、ある時点には既にそれが存在していいたことを証明します。これは署名＋時刻に対するさらなる署名で、ネットワーク経由の自動署名で精度は１秒程度のようです。ですが、これも結構お高い。安いところでも一件あたり10円くらいするようです。

自動生成した部品データにも署名したいと考えている、個人的な法人（笑）の私としては、ちょっと10円は厳しいかなと感じます。

自然ななりゆきとして、ウェブ（HTTP）のメッセージにもS/MIMEが使われるようになるのか？に興味がありますが、そういう話は盛り上がっていないようです。そもそも、ページの中のこの部分は誰が書いたもの、たとえば許可を受けた引用部分とかを峻別するためには、MIME/HTTPではなく、コンテンツ（HTMLなど）に署名を仕込む必要があります。MIMEにもマルチパートというデータ型があって、それを使えば入れ子のS/MIMEもできるのですから、やればできるとは思いますが、HTMLでメディアの埋め込みができるようになって、今ではすっかり、マルチパート（特にmixed）は廃れてしまった模様です。

2020-0413 sato@izmoh

---

そんな中、上記の個人証明書値引きキャンペーン打っている会社では並行して、無償で手軽にタイムスタンプを押してくれるサービスを提供しています。それがキャンペーンに乗った決め手でした。たとえばこの書き物のPDF版に対する署名は、以下のファイルの右肩に表示しています。PDFのリーダで開けば、その署名が本物か確認できますが、そのためにはご自身のPDFリーダに署名者の証明書をインストールする必要があります。自動化する方法もあるようですが、一件だけなら手動でも簡単です。 めっちゃメジャーな証明書業者から買えば、Adobeが証明書をプレインストールしてくれてて、その手間もいらないのかな？高そうだけど。ちなみに、Adobe自身が提供しているタイムスタンプサービスは、とても高価です。

以下が上記PDFの原本です。暗号してますごめんなさい。ヒントは：
"2020/04/13 18:54:20 +09'00'"

いわゆる電子定款には、公証役場の公証人さんが電子署名します。たとえば、弊社の定款PDFをAcrobatで開くと、以下のように表示されます（この場合には、署名をPDF上に重ねていません）。発行者は Registrar of Tokyo Legal Affairs Bureau, Mnistry of Justice（法務省法務局）です。わが社は東京法務局ではないですけどね。

Googleさんはどうしてるかなと思ったら、DocuSignという、クラウド上で署名してくれるサービスと連携してますね。やはりそう来ましたか。零細企業向けプランだと$25/月だそうな。かなりリーズナブルだけど、うーん、むずがゆいところ。富士ゼロックスさんも最近DocuSignと連携してペーパレス化(^-^)始めたみたいだし（一件あたり387円～ってまじか？）。複合機で紙をスキャンすると署名付きでPDFに落ちたりして。
いずれにしても電子署名化は、時代の潮流みたいですね。

とまあ、こういうふうに、まずはウェブページを題材に、ページの魚拓をとって電子署名して、同じページに挿入したりドライブに保存したりメールするフローを自動化・ワンクリック化したい、というのが、いまこれを試行している動機なんです。技術的には単純。このWordPressでもできるんじゃまいか。

最大のネックはタイムスタンプ代。技術的には応答時間…まあ、数秒なら我慢できます。任意のデータに署名するには？例えばS/MIMEをエンベロープにするとか。これをWebDavマウント（仮想ドライブ）と組み合わせれば…

現状、各社のサービスは「大事な文書に人間が大事に署名する」ことを想定しているし、クラウドサービスと抱き合わせです。一方わが社の構想は、「今見ているもの（いろいろ）」の上でワンクリック、特にエクスプローラの上のアイコンで右クリックとか、スマホで拇印押して指紋認証で捺印とか、さらに「機械的に生成したデータに自動的に署名する」というものです。私が証明書を購入した会社さんのコンセプトはそれに合っています。いずれ実現したいものです。
まあ、うちがやらなくても誰かがやる（やってる）でしょうけど…

と、ここまで書いてまた魚拓しました（DocuSign試用版使用）。

学生時代にユニークID（一意識別子, unique identifier, UID）という言葉を知った時、世の中の森羅万象にグローバルでユニークな識別子が付けられると面白いのに、と思ったものだ。 最近、余裕が出来たので（笑）これを再考してみる。

モノを識別する（見分ける、区別する）のは、情報処理の出発点だ。人間の思考においても、コンピュータによる処理においても。思いつくままに書いてくけど、最後には UUID（Universal Unique Identifier）に辿りつきたい。学生さんのレポートみたいな感じだけど、及第点に達するだろうか…

そういえば学生の頃は DEC PDP-11の Unibus とベル研の Unix がめちゃ好きだった。言葉の由来は違うけど。なお、UNIQLO はあまり好きではない。

身近なユニークID

分野や業界の中でのみユニーク（一意）なID（番号）は様々に存在する。

そういう、一意性の通用する範囲を、コンピュータ（プログラミング）の業界では「局所スコープ（視野）」と呼ぶ。ローカル／グローバル、プライベート／パブリック、イントラ／インターという表現もある。

ネットユーザとして身近なものには、固定長ならIPアドレス（32ビット/IPv4, 128ビット/IPv6）やMACアドレス（48ビット）、可変長（1）ならドメイン名（2）やメールアドレス、あるいはURLがある（3）。最近はあまり表に出ないけど、メールのMessage-IDもある。

（1）可変長とは言え、実装から来る制限はあり、最大長は決められている。
（2）今ではユニークID（絶対アドレス）として当たり前に使われているドメイン名も、それほど歴史は古くない。30年くらい前は、相対アドレス（到達経路パス）だった…
（3）World Wide Webが果たした最大のブレークスルーは、HTTPでもHTMLでもなくURL（Universal/Uniform Resource Locator）だと思っている。ハイパーテキストは古くからあったけど、ハイパーリンク（つまりResource Locator）の表現がグローバルにユニークでは無かった。IPアドレスはグローバルにユニークだったけど、識別できる対象の数が少なすぎた。私自身はMessage-IDを使って同じようなことにトライしていたので、URLにはヤラレタ感があった。

消費者としては書籍番号（ISBN, 13桁）、商品番号（JANコード, 13桁)を良く目にする。日本では比較的最近、個人番号（12桁）や法人番号（13桁）が導入され、これも身近なユニークIDになった。電話番号は10桁か11桁。これらはもちろん、十進表記であり、ふつうの人にとって可読性が良く、記憶もできる。

そもそも住所（番地, アドレス）というものはグローバルにユニークなIDとして最古のもののはずだが、可変長であり、簡単に作れず、識別できる対象の粒が荒すぎるという問題がある。

ヒトにやさしいユニークID

よく、人間が短期記憶できるのは7つまでと言われているが、年寄りには長期記憶だって怪しい。ただ、桁ごとの意味を分解して知っていれば、実際に覚えなければならない桁（塊り, chunk）は少ない。例えば192.168.1.32というプライベートIPアドレスで覚えとかないといけないのは、192.168（つまりプライベート）および１という塊りと32という値の3塊だけになる。

また、IP (v4) では32ビットのアドレスを8ビット（バイト）単位で区切って、たとえば16進表記で 0xC0A880A4 のところを、192.168.128.164 のように10進表記して来た。これで上記のように、身近な生活でなじみの深い12桁の10進表記になる。これは、ヒトが誤らずに認識したり書き写したり伝達したりできる限界に関係するのかも知れない。よくあるライセンスキーの多くはこれを超えており、間違わずに入力するのにひどく疲れる。

十進の13桁（10の13乗）は2の44乗（二進44ビット）で表現できる（10,000,000,000,000 == 0x9184E72A000）。これは10テラであり、10,0000,0000,0000 つまり十兆だ。現代の一般人が現実感をもって語れる最大値のように思う。さらにペタ、エクサを耳にすることはあるが、その上がゼタ、ヨタというのを知らなかった。1991年に制定されたばかりそうだし。こんなヨタ話を書き綴るのにふさわしいか（笑）。ヨタは10の24乗、92ビットで表現できる。

コンピュータの世界では32ビット（4バイト）が、長らく数値データやアドレス値の単位「ワード」としての地位にあった。32ビットは約4ギガなので、メモリやファイルのサイズがこれをまたぐようになった過渡期に「64ビット対応」騒動があった。あれは空騒ぎで済んだ2000年問題に前後して顕れた。次に2038年問題が控えているが、私も見届けたいものだ（笑）

全体の桁数とは違うが、視認性も非常に重要だ。12桁をベタに書かれたら認識しにくいが、3桁ずつ4つに分ければ、即記憶はできないにしろ、認識し伝えやすい。その意味を知らず192168128164 を見て手作業で書き写すのは難しい。

ここではとりあえず、ヒトにやさしいユニークIDは８桁程度の数字、という結論にしておこう。そうしよう。

こういう人間工学（エルゴノミクス）的な話は、とっくに出尽くしていると思うので、この辺で自前の考察は停止しよう。とはいえ、そういう事が踏まえられてないような事例もまだ身の回りにあったような…まあ、パスワードとかかな。最近は短いPINとかパスコードが使われる事が多くなったけど。

今回、各種の届出書や申請書に、法人番号を手作業で書き写し間違えて懲りた。ので、その後はPDFを編集するようになった…

コンピュータにやさしいユニークID

ユニークIDには（その良し悪しには）人間向けの側面（短期・長期に記憶できる、間違えずに伝え書き写せる、とか）と、機械での処理向けの側面（入出力、転送時間、記憶容量、とか）がある。いずれにしても、固定長にしろ可変長にしろ、長さには制限がある。

コンピュータにとってやさしい（易しい）ユニークIDって何だろう。

ユニークIDをユニークにするために、その生成（採番あるいは命名）の方法が課題になる。集中管理を行うものと、あらかじめ桁（あるいは階層）ごとの意味を決めておいて（つまりスコープを局所化して）分散管理ができるものに分かれる。

分散してローカルに採番（あるいは命名）した場合には、それをグローバルに公知するシステムが必要になる。ドメイン名においては、DNSだ。DNSのネットワークがおかしくなると、世の中は大混乱に陥ってしまう。

どちらにしても、あまりコンピュータにやさしくない。それと、識別される側に相談せずに勝手に作られたIDは、IDが識別している（指し示している）先のモノが何であるか（個性とか）を、何も表明（証明）していない。そこで登場するのがハッシュ値（ダイジェスト値）だ。

おなかがすいたのでこのへんにしよう。そうしよう。UUIDまではまだ遠い。

2020-0409 sato@izmoh

DeleGateの再始動に向けてウェブサイトを整理していたところ、佐藤が過去に作成したプレゼン資料が埋もれているのを発見しました。

そんな中で、昔にやりかけて遂げられなかったいくつかの仕事を思い出しました。その一つが、1991年頃に考えていた「viabus」です。以下は、2004年頃に行ったDeleGateのプレゼン・スライドの中の一枚です。

viabusは「アプリケーション層のバス」です。複数のアプリケーションプログラム（のモジュール）同士を、多対多の通信で接続するもので、プログラムの並列化・部品化と動的結合がテーマでした。今でいう「プラグイン」的な機能モジュールの動的追加能力も、考えていたと思います。

当時の技術の中での発想は「リモートプロシージャコール」の多対多版であり、Ethernet上に柔軟に接続できる「Unixワークステーション」間と同様な関係を、アプリケーションプログラムの部品間で実現しようとするものだったと思います。（Ethernetの黄色いケーブルにブスっと針で刺して繋ぐイメージ、今なら仮想ネットワークですけどね）

また、その当時佐藤は電総研の「ポストマスタ」として電子ニュースシステム（inewsとかcnewsとか、uucpとか…）の管理をやっていたため、NNTPプロトコルの ihave/sendme コマンドの影響も受けていました。

固定的なアドレスでは無く、動的に生成されるIDやメッセージの内容でマッチングして接続、通信することを考えていました。そのような接続に使用できる言語・処理系として、当時「Linda」がありました。しかしLindaの処理系が100万円もして、研究費で購入できず悲しかった記憶があります。

プログラムの動的並列化と接続を記述するために、π（パイまたはピー）言語のインタプリタを作ったりとか、自分の実力に見合わない無謀な試みもしました。

このviabusの上に複数の仮想的なディスプレイと仮想放送局を接続して、静止画を流すというようなデモを、当時の新人研修で新人さんに行ったのを覚えています。そのデモ風景の写真は「電総研ニュース」のある号の表紙に使われました。この冊子は国会図書館にもアーカイブされているようですが、なんだか閲覧できません。

それより新しい年代の言葉で言うと、実装上のviabusはいわゆる「リフレクタ」サーバであったと思います。DeleGateで試作した「VSAP（Virtual Socket Association Protocol）」プロトコルは実際、そのようなものであったと思います。

今再考すると、その考え方自体は間違っていない。しかし当時はそれを実現する能力も環境も足りなかった。それに、通信プロトコルというのは使われてナンボのものです。さもなくば、既存の標準プロトコルと互換であることです。佐藤はその後、標準プロトコルに巻かれる方向に流れました。

viabusを作り直すとすれば、現在でもHTTPの中継に使われる「プロキシ設定」や、やはりHTTPプロキシを中継器とする「SSLトンネル」の形で、仮想的なホスト名によってサーバと接続する、メッセージ形式はMIME、というものに落ち着くように思います。

その当時よりは自身のシステム開発能力は落ちたと思いますが、使える言語も環境も飛躍的に向上しており、物事をよりシンプルに実現できる可能性はあります。何にしても Unix v6 の K&R C の時代から40年使い続けたC言語とも、そろそろお別れする時期かと思います。老後は、go言語かな…

2020-0408 sato@izmoh

あちらではああなのに、こちらではこうなのは何故だ？

自身が優位になるアンバランスを作り出そうとする、一方で劣位にあるものが対抗し解消しようとする、それはヒトにとって大きなモチベーションや発想の源の一つであろう。アンフェアでないなら、これは望ましい。「バランスのとれた発展」は実際には発展を阻害し悪平等を招きやすい。

ただ、製品（プロダクト）におけるアンバランスは提供者側の勝手な争いによるものも多く、無意味な多様性によって空間、時間、思考的に分断される利用者側は被害者である。

文明・文化は多様化と統一を繰り返して成長する。現時点は全般に多様化のフェーズにあるように見える。長期的にはそういう繰り返しなんだと納得しつつ、自分がその激流の中に居るのは疲れる。でも反面、面白い。各レイヤが本質的に多様であるべきものであるなら、選択肢があることは良いことだ。

我々は今、最終的（？）に生き残るIT技術を選別するための実験に参加しているのだと思う。トシを取るとそれについていけなくなるのだろうか。しかしシニアは、クダラナイものが流行っては消えて行くのを見て来た。あれらもやがて消えていくのだろうか。それとも自分が消えるのが先だろうか。

2020-0408 sato@izmoh