Insert New
Slide
​
Roboto
A
Slide Break Defaults…
​
Cell Actions
Window Options
Start Presentation
▼

Slide
1
of
43
​
​

自己説明的実行可能ドキュメント(認知症のための「杖」：その後)

Katsunobu IMAI, Hiroshima Univ.
Feb. 3, 2020 @ CiNet
「記憶のないものは、ここへ入ってくることができない、
蛇たちは通さない、といっています。」はてしない物語

Slide
2
of
43
​
​

Sorry, these slides are written in Japanese.


  • It is essential for this talk.

    • The machine translated English version of these slides:

    https://www.wolframcloud.com/obj/imai/Published/20200203-cane-CiNet-en.nb
    TranslateNotebook[nb_]:=NotebookPutNotebookGet[nb]/.GraphicsBox[g__]GraphicsBox[g],​​ o_StringIfLanguageIdentify[o]===
    Japanese
    LANGUAGE
    ,TextTranslation[o,"Japanese""English"],o,nb​​TranslateThisNotebook[]:=TranslateNotebook[InputNotebook[]]​​​​(* TranslateThisNotebook[]; *)
    
    Slide
    3
    of
    43
    ​
    ​

    昨年は3か所でこの発表をしてみたにもかかわらず

    
    Slide
    4
    of
    43
    ​
    ​

    いると信じている「導師」を探す手がかりすら得られなかった

    
    Slide
    5
    of
    43
    ​
    ​

    「君の言うようなシステムは不可能だ！」

    聴き手の主な反応は以下の三種類:
    1
    .
    認知症患者の支援者の支援しか想定していない
    「不可能だ！」「認知症患者に判断力なんてない」
    2
    .
    可能だとは考えていなかったが必要性は認識していた
    「それこそ介護の現場で必要なことです、実現できるのでしょうか」
    3
    .
    (多分)考えていなかったが、やれば可能なのは当然だと思う
    「そりゃ、できるでしょうね」
    「そりゃ可能でしょう」と答えた人たちの中に「わたしもそういう問題を考えた」という人がいて思わず「導師！」と叫びそうになったが、実はその人は「考えて」いなかったか、少なくとも私の考えている問題とは違った。「忘れた状態を認識する」のが人にとってとても難しいことが少しずつわたしにもわかってきたが、実は、分かっている状態もまた認識するのが難しいのかもしれない。
    
    Slide
    6
    of
    43
    ​
    ​
    
  • 一人称視点の欠如
    • 「実現できるのでしょうか」「そりゃ、できるでしょうね」
    
    Slide
    7
    of
    43
    ​
    ​
    
    Slide
    8
    of
    43
    ​
    ​
    他人のことはさておき、わたしにとって「ドキュメント」と付随する「スクリプト」を認知能力の低下があっても持続的に取り扱えることは本質的である。
    
  • 自己説明的実行可能ドキュメント
    • 
  • 今 x歳なら90-x年後にもドキュメントが理解可能かつ実行可能(生きているドキュメント)
    • 
  • 今、当然であることと90-x年後に当然であることは異なる
    • 
    Slide
    9
    of
    43
    ​
    ​
    学生時代の卒論・修論に関連するファイル類で今でも理解可能かつ実行可能なものは...
    
  • Microsoft Excel、Adobe Postscriptファイルと適切にコメントと実行事例とをちりばめたいくつかのCommon Lispファイルのみである
    • 
  • 種々のアプリケーションの独自ファイルは全滅した(開けない)
    • 
  • データ類は関連テキストファイルも含め全滅した(適切なドキュメンテーションがなく何のどういう設定のデータかわからず、それを回復するための作業量が得られる利得に引き合わない)
    • 
  • 将来を想定したメモを残すことの困難さ
    • 
  • 「一件書類」の重要性
    • 
  • 処理されるべきデータとスクリプトの関係性
    • 
  • しかし一件書類を的確に仕上げる統合能力が真っ先に失われていく
    • 
    Slide
    10
    of
    43
    ​
    ​
    
  • 「見当識障害」などはあらゆる(ミクロ、マクロな)レベルで起きうる
    • 
  • e.g. 簡単に対処できていたバグをなかなかfixできなくなる
    • 
  • バグの起きるレベルとは？
    • 
  • 認知レベルの差によって利用しやすいツールが変化する
    • 
  • データ記述量を適度に短く隠ぺいできる Mathematica で表計算処理は可能だったにもかかわらず、 同じデータを扱う1ページの Excel ファイルの中で「迷子」になってしまった (見当識を保てない)
    • (Excelはむしろ「データオリエンテッドすぎ」てスクリプトが視野から隠蔽され、双方を同時に 把握し続けるだけの短期記憶があてにできなくなるときつい。
    cf. 解像度や着目点の異なる地図、 案内図とそのレイヤー表現）
    今まで理解できていたことが理解できなくなるとは?
    
    Slide
    11
    of
    43
    ​
    ​
    
    Slide
    12
    of
    43
    ​
    ​
    そもそもわたしたちはどういう状態を理解、実行可能と称しているのか?
    
  • 自己説明的実行可能ドキュメントが理解可能
    • 
  • 自己説明的実行可能ドキュメントが実行可能
    • 
  • 自己説明的実行可能ドキュメントが作成可能
    • わたしにとって“ideal”な自己説明的実行可能性とはどういうことか?
    
  • わたしがドキュメントを理解し実行することができる
    • 
  • ∃他者にドキュメントを示し理解、実行の手助けを依頼できる
    • 
  • ∀他者がわたしとは独立にドキュメントを理解、実行できる
    • e.g. すべてのソースとその実行系を含むシステムは ∀x, self-contained for x だが、もちろん ∀x,self-describing for x ではない。
    
    Slide
    13
    of
    43
    ​
    ​
    （記憶と外部資料の双方、またはどちらかに頼ることができるだけの短期記憶を失う時点を想定すると）言語仕様がそのドキュメンテーションと実行環境の仕様を包含していることは必要条件だろうか?
    
  • Xerox Smalltalk (VisualWorks) 1972-
    • 
  • (DEC-10)/Prolog 1972-
    • 
  • Xerox Star Development Environment/Mesa(, Interlisp) 1976-1981
    • 
  • UNIX/C 1977-
    • 
  • Emacs/Emacs Lisp (EINE and ZWEI/Lisp Machine Lisp)1978-
    • (Literate programming 1984)
    
  • FrameMaker+SGML/MML 1981-
    • 
  • Interleaf/Interleaf Lisp (QuickSilver) 1981-
    • 
  • Symbolics Genera/Zeta Lisp (Symbolics Document Examiner) 1983-2005
    • 
  • Adobe PostScript (& PDF) 1984-
    • 
  • ICOT PSI/ESP, KL1 1985-1992
    • 
  • Microsoft Excel/VisualBasic 1985-
    • 
  • NTT ELIS/TAO 1986-1993
    • 
  • Canon Cat/Forth 1987-1987
    • 
  • Apple HyperCard/HyperTalk 1987-2004
    • 
  • Mathematica Notebook/Wolfram Language 1988-
    • 
  • Macromind Director/Lingo 1989-2017
    • 
  • Fujitsu TownsGear/GearBASIC 1990-1997
    • 
  • Apple Soup/NewtonScript 1993-1998
    • 
  • WWW HTML+CSS/Javascript 1995-
    • 
  • Google Drive/Google Apps Script 2009-
    • 
  • Jupiter notebook/Julia, Python and R 2015-
    • 
  • ...
    • 
    Slide
    14
    of
    43
    ​
    ​
    言語仕様がそのドキュメンテーションと実行環境の仕様を包含していることは必要条件だろうか？
    
  • Xerox Star Development Environment/Mesa(, Interlisp) 1976-1981　終わりました
    • 
  • UNIX/C 1977- UNIX全体を融合したドキュメントとその実行ベースと認識でき、かつ認知症発症後もシステム全体を掌握して使える自信のある人なら...
    • (Literate programming 1984)
    
  • Interleaf/Interleaf Lisp (QuickSilver) 1981-　高いしどこにもない
    • 
  • Adobe PostScript (& PDF) 1984-　scriptとしての汎用度が高ければ...それはダメですね。望まれているものではないです。PDFに望まれていることは100年後にも開いて読めることで、むしろ「生きた化石」としての存在です。
    • 
  • Microsoft Excel/VisualBasic 1985-　ネ申Excel fileを鑑みれば...
    • 
  • ...
    • 
    Slide
    15
    of
    43
    ​
    ​
    
    Slide
    16
    of
    43
    ​
    ​

    “Procrastination” and Larry Tesler

    先延ばし, PCN症候群: するべき行動を遅らせることで事態が悪くなると予想される場合ですら、合理的理由無く意図して遅らせる態度、振る舞い。うつ病やADHD（注意欠陥多動性障害）のような精神疾患や発達障害の症状や原因の一つでもある。(Wikipedia)
    
  • Larry Tesler was a thoughtful critic who helped shape the MFU(Midpeninsula Free University); held a variety of offices; wrote poetry, articles and reviews for The Free You; and taught classes with titles like People Heaps, How to End the IBM Monopoly, Computers Now, and Procrastination. (http://midpeninsulafreeu.com/)
    • 
  • Tesler worked at Xerox PARC, where some of his main projects were the Gypsy word processor and Smalltalk. Copy and paste was first implemented in 1973-1976 by Tesler and Tim Mott.
    • http://www.nomodes.com/Larry_Tesler_Consulting/Articles.html
    https://guidebookgallery.org/articles/designingthestaruserinterface
    
  • Tesler worked with Niklaus Wirth on adding object-oriented language extensions to the Pascal programming language, calling the new language Object Pascal. He was also involved in the development of the MacApp.
    • 
  • Tesler led the efforts of developing the Apple Newton.
    • (Wikipedia)
    ※認知的ハンディキャップに関する知識をも前提にした開発者が開発している計算機言語システムは今ありますか?
    
    Slide
    17
    of
    43
    ​
    ​
    
  • UNIX/C 1977- UNIX全体を融合したドキュメントとその実行ベースと認識でき、かつ認知症発症後もシステム全体を掌握して使える自信のある人なら...
    • 認知機能低下時に利用する場合の最大の問題点:
    
  • 個別のファイルシステム全域に環境依存
    • 
  • 「一件書類」概念が欠如
    • 
  • 多分、望まれているものは自分の認知変動(環境)に合わせて必要な「解像度」が変化する多重解像度の自己説明的実行可能 一件書類を作ることを心がけ、それが作成されていない場合でも自らの作業履歴データベースから生成、提示すること
    • 
  • たとえ、本体のデータがハイパーテキスト化していても、一件書類として提示する（ハイパーテキストではないようにふるまう）という意味で、従来のハイパーテキスト概念とは対極
    • 
    Slide
    18
    of
    43
    ​
    ​
    「ずっと Lisp 使ってますから。でも素の Lisp 使うのにも耐えられなくなって、 Mathematica ばかり使うようになってますけど。」
    「Mathematica って Lisp なんですか?」
    「そうです(キッパリ」
    「でもLispだって書いてありませんよね。」
    「そりゃそうですよ、今時 Lisp って書いても、売り上げが落ちることはあっても上がることはありませんから」
    Lisperは「よく知らない人間の直観」というものを あまり信用していない気がします。
    https://practical-scheme.net/wiliki/wiliki.cgi?Lisp%3AS式の理由
    
    Slide
    19
    of
    43
    ​
    ​
    「Mathematica って Lisp なんですか?」
    「そうです(キッパリ」
    「でもS-式じゃないですよね。 Lisp はすべてがS-式でなければ」
    「S-式とはちょっと違うけど、 Mathematica はすべてがSu-式ですよ」
    このノートブックももちろん数式であり、SelectedNotebook[] + 1 って書いても怒られないし、実際この演算に機能を定義できる。
    
    Slide
    20
    of
    43
    ​
    ​
    
  • 問題点しかない！(永続的にドキュメントを支えるという観点では)
    • 
  • Wolframがリタイアしたら詰む(しなくても前途はすでに不透明)
    • 
  • バグが多い
    • 
  • Notebookの構造が複雑なのに、読み込みが文法エラーに脆弱
    • (cf. エラーまみれのHTMLをとにかく読み込む汎用webブラウザ)
    
  • セキュリティに関してほぼ何も考えられてない
    • 
  • ファイルや名前空間のセキュリティだけでなく、その単一実行環境がセキュリティ的に厳しい。しかもカーネルが落ちるとすべてが落ちる。
    • (Mathematica におけるセキュリティは計算の正しさを保証するために必要なそれ (もちろんとても重要) を指し、いわゆる「セキュリティ」ではない。シンボル空間をコンテキストで分離は可能だが (Protect 宣言以上の) 保護はできない。同じ Lisp 環境でも、 マルチユーザマルチプロセス下におけるシンボル空間と セル空間の保護機構は既に NTT ELIS にもあった。)
    
  • Notebookでの日本語の扱いに難がある(その一端はこのスライドを見れば明らか)
    • (FrameMaker や PDF などと比較しての話。そもそも文字コードの扱い方すら仕様で統一されていない他の言語環境などは論外)。
    
  • 言語仕様自体が今となっては古風
    • ※ 数式処理システムとしてみた場合の問題点もそれはそれでまた別問題として多々ある
    
    Slide
    21
    of
    43
    ​
    ​
    
  • 言語仕様がそのドキュメンテーションの仕様と実行環境のそれを確かに包含している
    • 
  • 30年間を「生きた化石」化せずに存在し続けている数少ない「高級言語」のひとつ
    • (同じ “Lisp” でも Common Lisp は「高級言語」化にむけた民主主義的な仕様策定の　「成功」によって　「生きた化石化」した。 Cは「高級言語」化を拒み続けることによって　「生きた化石化」の回避に今のところ成功している。 Python は 30年後どうなっているだろうか。)
    
  • 他者との関係における言語とその記述の積の複雑さ
    • 1. わたしがファイルを理解し実行することができる
    2. 他者にドキュメントを示し理解、実行の手助けを依頼できる
    3. 他者がわたしとは独立にドキュメントを理解、実行できる
    
    Slide
    22
    of
    43
    ​
    ​
    
  • いつの日か日本語をそのまま実行可能スクリプトとみなすシステムができるはずであり、それは抽象化された数学的記述も含めて実行できる可能性が高い
    • その日に備えて素性の良い(機械意味解釈可能な)文章を書くトレーニングが有効かも
    しれないが、それは実行可能ドキュメントと関係なく今でも重要な素養である
    
  • 普遍的数学的記述に頼って、ドキュメントが自己説明的に振る舞うことで、十数年後、認知能力が低下した自分が理解できる文書とすることと、他者の支援を得る道を探りたい。
    • 
  • 「90-x年後」に Fortran は失われていても、数式で記述された数学の基本的な体系は 失われないのでは? とすれば、 可能な限りはブートストラップで より抽象度を高めた 数学的記述に 変換していくべきだろうし、 現状でそれが Mathematica ならそれを使うべき ではなかろうか?
    • 「Mathematicaが詰むならMapleを使えばいいじゃない?」
    
    Slide
    23
    of
    43
    ​
    ​
    
    Slide
    24
    of
    43
    ​
    ​
    
  • 少なくとも当初から「こんなハンディキャップを背負っているのだと絶望」するような言語は却下
    • 
  • 本来、ネイティブな言語(日本語)でダイレクトに書くことを目指すべきである
    • 
  • 英語ベースの計算機言語環境はすべてのオブジェクトをダブルポインタ参照しているようなもの。
    • 本来「貧乏性」なプログラマはダブルポインタ参照コストを気にすることが多いのに、英語というダブルポインタ参照コストをなぜ気にしないのだろうか？
    
    Slide
    25
    of
    43
    ​
    ​
    わたしにとっての距離感:
    日本語 < 数式 < Lisp(Mathematica, CommonLisp) < 英語, C
    
  • 誤解を承知で単純化したたとえを挙げれば... subtract two from six...という英文が「読めなくなる」時点のほうが 数式“6 - 2”の意味がわからなくなるより早い予感がある(個人の感想です)。
    • 
  • Lispはどうか?
    • 
  • S-式の各アトムの近傍の結合をどれだけ認識し続けられるか?
    • 
  • わたしにとって機械翻訳後の文章の認識可能性が英語の原著を上回る時点はいつか?（すでに上回りつつあるが...）
    • 
  • 翻訳前後の文章を対比して提示すると現時点では可読性性が上がる場合が多い。しかし認知能力の低下で、対比された文章の配置が遠すぎて相互に突き合わせて理解することができなくなる可能性がある。
    • 
    Slide
    26
    of
    43
    ​
    ​
    原則は日本語と数式を用いて記述する
    まずは出発点↓から
    
    Slide
    27
    of
    43
    ​
    ​
    (ここまで消去法的、消極的な理由しか挙げてこなかった)
    Mathematicaを選択する「積極」的な理由はあるか?
    
  • システムは次の二点を満たしていなければならない
    • 
  • システムの設計者が一人称視点で設計している
    • 
  • その設計者の目的がわたしの目的とできる限り近い
    • 
  • MathematicaはStephenの知識欲をみたすために彼の一人称視点でデザインされ、機能が追加されつづけていている。
    • 
    Slide
    28
    of
    43
    ​
    ​
    
  • その設計者の目的がわたしの目的とできる限り近い
    • どうやら Mathematica Notebook は自分の作業過程を記録したい人がデザインしたらしい (Theodore Gray or Stephen Wolfram himself?)
    
    Slide
    29
    of
    43
    ​
    ​
    
  • 過去に何度もデータを失ってきた経験からこれは重要なポイント
    • 
  • まずは最低限の非常口を確認しておかねばならない
    • 
  • Wolfram Research に貢ぐことが経済的にできなくなった場合でもファイルの再生実行だけは無償でできる。
    • 
  • ノートブックの利用を停止する必要がある場合:
    • フォルダのノートブックを根こそぎPDFに変換するには:
    
  • 自己説明性の高さをできる限り保証しやすい実行可能ドキュメントを意識していられる 限りはExportされたデータにそれなりの意味は見いだせるだろう。(※ 90-x問題)
    • さて、この「共通実行可能ドキュメント基盤」上で、「わたしとその近傍」に来るべき 認知低下にまつわる「備え」の可否を議論していこう。
    
    Slide
    30
    of
    43
    ​
    ​
    
    Slide
    31
    of
    43
    ​
    ​
    タグ付けが半自動化されるならなお良い
    
    Slide
    32
    of
    43
    ​
    ​
    認知症対策、見当識障害対策として、不要な暗号化を避けることができるなら避けた方が良いのは明らか
    (今どきのプライバシー遵守の風潮はあらゆるシーンで認知症フレンドリーではない)
    
  • 適切に部分的に暗号化されたドキュメントでハードディスク全体の暗号化を避けることはできるだろうか？
    • 
  • セキュリティー対策、改竄対策のために電子署名やブロックチェーンによる保護は必要だろうが、可能な限り平文で保持したい。
    • 
  • もちろん現実に立ち向かうには複雑な状況を考慮する必要がある: 参考PDF参照
    • 
    Slide
    33
    of
    43
    ​
    ​
    ましてファイルシステム全体が丸ごと暗号化される必然性もないはず
    
    Slide
    34
    of
    43
    ​
    ​
    
    Slide
    35
    of
    43
    ​
    ​
    認知能力の変動を考慮した多重レベルのセキュリティ管理が必須
    
    Slide
    36
    of
    43
    ​
    ​
    
  • スマートコントラクト Szabo 1977
    • 
    Slide
    37
    of
    43
    ​
    ​
    
  • ∃他者にドキュメントを示し理解、実行の手助けを依頼できる
    • 
  • マスタ鍵をどうやって保管するか?
    • 
  • 90-x 年後まで使える生体認証鍵とその実装はどこに?
    • 
  • 増井さんがbitに書いていた忘却に対して冗長なパスワード
    • 現状では、自ら自己説明的実行可能ドキュメントとして準備するしかなさそう
    
    Slide
    38
    of
    43
    ​
    ​
    
    Slide
    39
    of
    43
    ​
    ​
    あるいは遺言の遺し方
    IDベース暗号では、認証局がそのマスタ秘密鍵を各自のIDをベースに各自の秘密鍵を発行できることをあてにして、まだシステムを利用していない(鍵を発行してもらっていない)人に対してもそのIDを使って暗号化データを作成しておくことができる。しかし、(任意の個人を認証してしてくれる)認証局が存在しない場合に、まだシステムを利用していない人に対して暗号化したデータを残す場合にはどういう手立てを講じる必要があるか？
    1
    .
    秘密共有したい人とのみ共有していると考えられる質問とその答えにより上述の冗長パスワード保護を用いる（本当に復号できるかどうかを保証できないリスクがある）
    2
    .
    複数のシステム利用者による秘密分散共有をあてにする（完全に秘匿されつづけることを保証するのが難しい）。
    本来「情報銀行」の役割はマイカード番号にせよ、住基コードにせよ、IDに基づいて個人を認証する認証局としての役割が重要なのだと思うが、例によって今ないものを当てにして始めることはできないので、1,2の合わせ技が現実解だろうか(これから10年の間に状況が変われば臨機応変に修正すればよい)
    3
    .
    何人かのシステム利用者が認証した「推薦状」と１の当事者が確実に知っているであろう質問の答えとを組み合わせて、復号の可否を決定する。そのときのセキュリティポリシーをあらかじめ決めておく。
    「推薦状」発行者がそのノートブックに推薦状を「添付」すると推薦者のIDは残り、匿名で推薦することができず、かつ、推薦状の必要枚数がセキュリティポリシーで確定していれば漏洩リスクを多少は低減できるだろう。
    
    Slide
    40
    of
    43
    ​
    ​
    
  • 既に現時点の認知能力でも、現況のファイル管理ではデータセキュリティを支えきれない
    • 
  • 認知能力の変動を考慮した多重レベルのセキュリティ管理が必須
    • 
  • 認知変動を吸収できる自己説明的ドキュメント
    • 
  • セキュリティレベルだけでなく認知変動に合わせたハイパーテキストやバックエンドのデーターベースからの必要な関連データの一件書類化作業の(半)自動化
    • 
  • 多重解像度の実行可能ドキュメントとは?
    • 
  • 認知変動レベルに応じた遅延評価ベースのスケジューリングを行う
    • 
  • 他者の支援を必要とする部分を(半)自動的にアウトソースできる
    • 
  • 他者は、支援者に限らず、認知変動で認知能力回復時の自分も包含する
    • 
    Slide
    41
    of
    43
    ​
    ​
    
  • 非力なハードウエアで驚異的な速度で動作する HyperCard, ダムターミナルしかない現状からは想像できない「生きたターミナル」が OS 標準だった Genera, ... の存在はもはやオーパーツレベルである。
    • 
  • 「Mathematica が詰むなら Maple を使えばいいじゃない?」が可能であるためにはMathematica のような数式処理実行環境の進化を切望する科学者、数学者、趣味人 (とても重要) の要求が強固かつ普遍的であること、が必要である。それを仮定し依存することは妥当だろうか?
    • cf. http://axiom-developer.org/axiom-website/bookvol1.pdf
    
  • もし、この仮定が偽であるか、真であってもその強さが経済的、その他の理由をのりこえるには不十分で当該実行環境とその他選択肢が失われたとする。そういう社会の「短期記憶の喪失に社会の「長期記憶」としての「数学知識」から、その「短期記憶」の一時的喪失を回復できるのだろうか? その回復過程を早めるすべはあるだろうか?
    • アシモフのファウンデーションですなぁ。
    さすがに、この問題をさらに深堀して心配する (Mathematica からの脱出口を確保する以上の) 必要性は多分わたしにはないと信じたい。
    cf. https://www.amazon.co.jp/dp/4409040286
    「それはまた別の話」でしょうね。
    
    Slide
    42
    of
    43
    ​
    ​
    
  • Logの過去履歴の中に平文（または低いプライバシーレベルの暗号化）で書かれていることを秘匿すべきだと判断した場合、そのセクションを暗号化(レベルを変更）する、すなわちプライバシーレベルが変更可能でなければならない。
    • 
  • Logの履歴に開示してはいけないデータが平文で存在していることと判断した本人、家族知人等関係者、他人がそれを暗号化して保護する事案の場合分けとそれぞれの方策。また、本人の状態と本人のプライバシーポリシーもその方策を実行する関数の引数になっているはず。
    • 
  • プライバシーレベルを上げることは下げるより一般にたやすい。しかし、念のために暗号化するというようなプライバシーレベルを上げることが、たとえば公開されている宣伝をライバルが非公開に設定して営業妨害するような事案を誘発しても困る。さらに本人の認知能力が落ちている場合、秘匿すべきことを他者が秘匿してくれた行為を本人が正しいと認識できるとは限らない。
    • 
  • 将来的にはバイオメトリクス認証の進歩で、脳の信号から本人の意思にまつわる状態も含めて認証のとその必要性とを判定して鍵として利用できるようになるかもしれないが、とりあえず現状では増井さんが昔bitに書いていた「超安全パスワード」ようなものをでっちあげて、自分の世代ごとの質問と答えの組をある閾値以上正解するとマスターキーなどがとりだせるドキュメントを準備しておく必要はあるだろう。
    • 
  • プライバシーポリシー自体も開示されている部分と暗号化されている部分があってもよいはず。あるパートに関しては開示が必須なものもあるだろうが、項目によっては記述されているか否か自体を秘匿しないといけない場合もあるだろう。そういう多様な設定項目に関するポリシー実行をゼロ知識証明的な枠組みで実装する必要があるだろう。
    • 
    Slide
    43
    of
    43
    ​
    ​
    https://www.wolframcloud.com/obj/imai/Published/20200203-cane-CiNet.nb
    参考PDF類: https://home.hiroshima-u.ac.jp/imai/