暗証語再設定機能も新生全知検索整備に戻る前に実装してしまうことにし,方針をまとめて終了。
これまで一緒に考えることが多かった暗証語再発行機能とは切り離す。また,同時に暗証語表示機能も実装することにした。
昨日,デラングで埋め込み記法の拡充をしているついでに TwEgaku 対応を思いつき,TwEgaku の手定めをした。その時,暗証語表示機能があるのを見たのがきっかけで,なんとなくデライトでの実装を考え始めた。
そして今日,再設定機能の早期実装を思いついたが,これは表示機能について考えていたことと関係がありそうだ。
必要性が高く実装コストの低い再設定機能実装をここまで遅らせてきたのは,デライトでは特に誤設定の危険性が高いからだ。十分に基礎実装の信頼性が高まり,再発行機能のような保険が無ければ,かえって深刻な問題を招きかねない。しかし,再発行機能実装は SMTP 関連の実装や設定の整理も必要で,なかなか時間対効果と優先順位を上げられなかった。
デライトの信頼性も再設定機能の必要性も十分に高まったこの時期に,誤設定の可能性を多少軽減する表示機能が背中を押してくれた気がする。暗証語の「見えない怖さ」がデライトでは思いのほか大きかったことにも気付かされた。
暗証語表示機能は,チェックボックスと「隠す」のラベル,下見ボタンにも使っている目玉のアイコンでイメージしているが,細かい部分で懸念もある。
type="text"
と type="password"
を切り替えるのが一般的な実装だが,舞覧はこれに基いて挙動を切り替えることがあるので,制危や用合い上の劣化につながらないかは特に気になる。最近なら autocomplete="new-password"
や autocomplete="current-password"
で十分なのだろうか。
もっとも,これだけ広く使われている実装に致命的な問題は無いはずなので,とりあえず試してみるしかない。
再設定時,新しい暗証語を2回入力するような用合いを考えていたが,現在の暗証語も制危上必要なことに気付いた。
スクリプト処理の脆弱性を利用して,勝手に録入り中用者の暗証語を変更する攻撃がありうる。
暗証語再発行機能に関しては,再発行用メールアドレスの登録だけ出来るようにしておいてもいいかもしれない。
CSS 変数(カスタムプロパティ)の導入と舞覧五年対応原則の採用を決めて終了。今後デライトでは,「5年以内に離立された版存の主要舞覧」を中心に対応していく。
希哲15年3月1日の開発から「デライト推奨動作環境」として同様の定義を考えてはいたが,当時は,古い舞覧対応の努力はするが推奨はしない程度の,もっと緩やかなものを想定していた。
希哲13年に ECMAScript 2015,HTML5,CSS3 と比較的新しいウェブ標準の導入を決めてからだいぶモダンにはなったが,まだデライトの舞覧対応方針には感覚的で保守的なところがあった。感覚的に,影響範囲の広い付徴は主要舞覧の対応から10年,影響範囲の狭い付徴は5年を目安に導入を考えていた。rem
ですら必要以上には使わなかった。
先日,前次記法実装でグリッド領当てを導入したが,これはちょうど主要舞覧で使えるようになってから5年ほど経つ機能だった。一記法の装体に過ぎなかったこともあり,ここまでは辛うじて良かったが,他にも色々応用したいことが出てきて舞覧対応方針見直しの必要を感じていた。
決め手は,デライトのダークテーマ対応も見据えて CSS 変数の導入を考え始めたことだった。CSS 変数も主要舞覧の対応から5年ほど経つが,本格的に導入するとなると影響範囲が広がり過ぎる。
Can I use で対応舞覧をよく調べるようになってから,「5年以内に離立された版存の主要舞覧」が意外に普及していることに気付いた。大体90%以上はある。
地域にもよるだろうが,確かに,今時古い舞覧を使い続ける方が難しいかもしれない。個人機なら5年は平均的な買い替え周期であり,スマートフォンなら古い部類だろう。自動更新も標準的になった。昔と違って,多数派の“普通の人”ほど新しい舞覧を使っている。
あえて古い舞覧を使い続ける場合というと,一昔前なら古い個人機の再利用というのがあったが,格安インターネット端末が普通に流通している今,新しい舞覧が使えないほど古い端末を使い続ける費用対効果は疑わしく,制危も考えれば推奨出来ることではない。
一番面倒なのが舞覧の更新が許されない企業内利用だが,そもそもそんな保守的な環境でデライトが利用出来るとは考えにくい。
こう考えていくと,デライトにとって古い舞覧への対応の重要性は極めて低いと言わざるをえない。
奇しくも,新生デライトの完成を目指している6月の15日に,IE11 のサポート終了がある。中途半端な気もする内容だが,いわゆるモダンではない舞覧最後の砦が崩壊する。新しいウェブ標準への社会的移行の象徴的な出来事にはなる。
ある程度古い舞覧への対応を考慮してきたのは,企業体力がついた将来,対応を拡充することを考えていたからだったが,これもよく考えると合理性が怪しい。
“技術的負債”は簡単に金で返せるものではない。大企業が肥大化した交度にいかに苦しめられているかを考えれば,合理的に古い舞覧への対応が出来る日が来るかどうかも分からない。むしろ,組織が大きくなった時にこそ見通しの良さが重要になる。
もっと根本的なことを言えば,デライトはウェブ標準という盤本の“キラーアプリ”になるべきものだ。新しいウェブ標準の普及を牽引していくくらいの考えがなくてはいけない。
その伝証の足掛かりがすでにこれだけ普及していれば十分過ぎるだろう。
舞覧五年対応原則の導入によって,ウェブの理想と現実における汚い現実の大部分だった古い舞覧を正しく切り捨てることが出来るようになり,前縁整備はもちろん,デライト文書整備でも大きな効率化がもたらされるだろう。文書整備では,対応舞覧についてどう説明していくかが一つの課題だった。ここまで絞り込めば説明もすっきりする。
デライト開発を劇的に合理化した描出公開原則とともに「デライト二大原則」と呼ぶべきかもしれない。思えば描出公開原則もデライト正式離立という大きな節目を目前にして生み出したものだった。
越化周りの客体表現化を考えるついでに文字参照の越化について再検討して終了。
HTML 越化仕様を決めた昨年5月20日12歩以来,越化目的で使う可能性がある文字参照のみを許容していたが,これは修正し,いったん全ての文字参照を許容することにした。
4日21歩でも再検討したが,越化記法同様,デラングにおける特殊文字を白表方式で管理するのは無理がある。損われる保守性に対して利点が乏しい。
当初は制危というより迷惑行為対策など運営上の都合で必要になるのではないかと思っていたが,Wikipedia はじめ大規模サイトで開放されている例も珍しくなく,少なくともデライトの言語仕様にするほど必要な制限とは言えない。文字参照で制危上致命的な問題があればそれは舞覧の問題だろう。迷惑行為対策としてもあまり本質的ではない。
何か問題があれば制限する,で十分なはずなので,実装都合で制限してもいいことにする。
文字参照には,表示や入力に難がある文字が記述しやすいという有用性も一応ある。
領下手定め環境でも Let's Encrypt 証明書を導入した。
希哲14年から HTTPS 統一の一環で領下では自己証明書を利用していた。初回握接時の舞覧の警告は,一つの舞覧なら大した問題ではないが,舞覧や端末を切り替えながらの手定めは煩雑だった(最近は dnsmasq の導入でその機会も増えていた)。また,開発者通類の梱装で制危関連の警告が多量に出力されたり,PWA など厳格な制危を要求される手定めが出来ないなどの問題があった。
更新と,なんとなく認証も面倒臭そうだと思っていたが,希哲12年から使っている via 迂回と DNS 認証の相性が良いことに気付いた。実際,いつもの DNS 認証であっさり取得出来た。まさか4年前の発明がこんなところに活きてくるとは思わなかった。更新の問題はあるが,警告などの煩わしさに比べればあってないような手間だ。