短期的なアウトプット(ブログなど)のための学習をやめた

何の話か

  • かつてインプットの目的が短期的なアウトプット(ブログなど)になっている部分があった
    • つまり、気になるテーマについて学習するのではなく、短期的なアウトプット(ブログなど)のためにインプットをする、みたいな癖がついてしまっていた
  • これをやめた

アウトプット is

  • ここではアウトプット=超狭義な意味でのアウトプットとする
  • 記事とかブログとかそういうの
  • 学びによって豊かになった人生そのもの、みたいのは対象外
    • 本質的にはここの問題

注意

  • アウトプットをやめろ、みたいな話ではない
  • 意味のあるアウトプットはコミュニティにとって素晴らしいし、書く人にとっても間違いなくメリットがあるはず

どういった問題があったか

なぜインプットするのか

  • 俺にとってインプットの目的は本来短期的なアウトプットではなかった
    • 記事とかブログとかそういうの
  • 俺は俺が知りたかったり、必要だったりすることを知るために学習している

アウトプットを意識しすぎる

  • コストパフォーマンスが良い方に行動を最適化してしまう
    • アウトプットを意識しすぎると、学習の目的そのものがアウトプットになってしまう
    • 本来は 俺は俺が知りたかったり、必要だったりすることを知るために学習しているはずなのに

すると?

  • 学習のテーマが「アウトプットのしやすさ」に左右される
    • 理解に時間がかからなくて、日本語の解説記事がない、みたいなものへのインプットが重視される
  • これは自身の美意識によるところもある
    • 誰かがすでに解説しているものを、ほとんどそのまんまコピーしたようなブログを書きたくない、みたいな
      • 他人がやる分にはどうでもいい、自分の話

結果?

  • 基本的な知識であったり、複雑で難しい話に正面から取り組もう、みたいな意識が薄れる
    • コスパが小さい(気がしてしまう)から
  • これは自分にとっては例えば CPU の仕組みであったり、暗号の基礎であったり、TLS の仕組みであったり、みたいな話だった
    • これらはめちゃくちゃ詳しい人がたくさん解説してくれているので自分に書けるような話は読書感想文みたいのを除くとほとんどない
      • ので、インプットに対するアウトプットが 0、という状態が簡単に起こり得る(広義のアウトプットは 0 ではない、のに)
        • 評価基準をアウトプット(ブログ)としてしまうと、このようなインプットはコスパが悪い、となる
  • でも自分にとってはそっち(アウトプットの効率が悪いインプット)のが楽しかったし、今後もそっちに注力したほうがもっと楽しいと思っている
    • 俺にとっては目新しい目の前のツールの使い方よりも、こういう学習のほうが楽しかった
      • ツールについて学ばない、というわけではない
        • 割合の話

だから?

  • 短期的なアウトプットを自分の中の評価基準に入れるのをやめた
  • とはいえインプットの過程でこれについて解説したら嬉しい人いるんじゃないかな、みたいのはなるべく書くようにしている
  • 「何か自分なりに説明する」という行為は知識の定着につながる
    • んだけど、「誰かがすでに解説しているものを、ほとんどそのまんまコピーしたような文章を公に向けて書きたくない」という感情は全然ある
      • 俺自身の美意識の問題
      • public にしないでノートを付けることにした
        • 別にこれでも定着するっぽい
          • フィードバックがない、という問題はある

まとめ

  • インプットの目的が短期的なアウトプット(ブログなど)になっていた
  • すると、インプットのテーマ選びに、「短期的なアウトプット」という目的への最適化がかかる
  • なんだけど「短期的なアウトプットのコスパがよいインプット=自分が本当に知りたいこと」ではなかった
  • ので、そういう考え方をやめた
  • 時間のかかるテーマに時間をかけて取り組むのは、それが短期的なアウトプットにつながらなくたって楽しい

もらったセキュリティキーが悪意のあるデバイスでないことを確認できるか

もらったセキュリティキーは絶対に危険だから使うなという話ではないです。

なんの話か

  • 先日の FIDO セミナー で Yubico のセキュリティキーを配ってたんですが、いざこのキーを使おうとしたときに「本当に信用していいんだっけ」と思った
  • 個人的には「Yubico のブースにいた、Yubico の服をきた人が配っていた」で信じていいんじゃないかと思っている
  • もらったセキュリティキーは検証してから使うべき、という話ではない(信用できる文脈でもらったかどうかのが大事だと思う)(この文章は、それはそうとして本当に検証しきれるのか?という話)
  • もう少し信用が落ちる場合はどうか
  • 大規模カンファレンスで「セキュリティキー・ガイ」を名乗るおじさんが、めちゃくちゃ配りまくってるセキュリティキーだったら?
  • セキュリティキーの文脈じゃなくてもわけわからんやつが配ってる謎の USB デバイスを使うな、という話ではあると思う

Yubikey Verification

YubiKey Verification

というのがあって、あなたが持ってるそれ、本当に YubiKey なの?を検証できる。 具体的にこのサイトが何をしてるかわかってないけど、安直に考えるとアテステーションを使って署名の検証をしている(= YubiKey にしか入っていない秘密鍵を持っていることの検証をしている)と思う。(違ったら教えてほしい)

これは YubiKey でなくても、FIDO certified なセキュリティキーやベンダーが公開鍵を公開していれば検証できる。(カジュアルにできるサイトがあるかどうかはわからん)(アテステーションの検証をしているサービスで使ってみれば良いはず)

本当の YubiKey を改造した悪意のあるセキュリティキーだったらどうか

こういうのを作れるんじゃないか?と思っている。

このハンドラーは、例えばリクエストの origin が「www.yubico.com」の場合リクエストを本物の YubiKey に送信し、レスポンスをそのまま返し、そうではない場合悪意のあるモジュール(秘密鍵を攻撃者が知っている、とか)にリクエストが送信されるようになっている。

そうすると、おそらく Yubikey Verification では Yubikey と判定される、悪意のあるセキュリティキーが存在できてしまうのでは?と思っている。

もうすこし詳しいユーザーはアテステーションを検証しているサービスでこのキーを利用して、本当に信用できるかどうかチェックするかもしれない。

その場合、 attestation=required なリクエストに対してだけ Yubikey のレスポンスが返せば、ユーザーはこのセキュリティキーが危険なものであることに気づけ無いので attestation=required でないサービス(= iOS16 に対応しているサービス)に対してだけ攻撃が成功する。

繰り返し

もらったセキュリティキーは絶対に危険だから使うなという話ではないです。

2022年11月にやったこと

IdP

引き続き IdP を書いている

github.com

Maven に publish したりドキュメントをもりもり書いていた かなり仕事感があった

プロフェッショナルSSL/TLS

datatracker.ietf.org

を読んでたらそもそも TLS の知識が怪しすぎる事に気づいたので読み始めた 160ページくらいまで読んだ 読んでると DNS の知識も足りないという気持ちになってくる

クッキーの話とか最近話題になってたやつと合わせて読めてよかった

これからやること

1Password を使っていれば MFA が達成できていると言えるのか

二要素認証(TOTP)のトークンをどこに保存するか問題 - @kyanny's blog

を見てておもったやつ

1Password、Chrome 拡張とかで使う分には

  • パスワードでの認証(知識)
  • 1Password 連携済みの端末(所有)

が必要なので、知識と所有の 2 要素が担保できている、という認識でいた このケースは新しい端末の同期がパスワードだけでは無理なので成立しているはず

もしくは拡張とかでなくふつうに 1Password にログインする場合

  • パスワードでの認証(知識)
  • シークレットキーでの認証(所有)

が必要で、後者はルックアップシークレットに該当して所有となる認識(参考 : NIST Special Publication 800-63B

なんだけど、Emergency Kit を使って復旧するケースは 1Password の資料を見ていると微妙なのかも

Emergency Kit について知る | 1Password

には

印刷した Emergency Kit の 1 枚以上のコピーにマスターパスワードを記入してください。

という記載があって、こうなってくると Emergency Kit さえ盗めれば突破できるのでマスターパスワードがあるから知識と所有の 2 要素だよね、とは言い難い気がする(セキュリティキー本体に PIN が印字されてるみたいな) ただじゃあ 1Password での TOTP シークレットの管理は Not MFA だよね、でいいのかというとそれもなんか微妙な気がしていて、それはこの資料にもあるように Emergency Kit はちゃんと保存してね、みたいな記載がある

コピーを印刷して貸金庫に入れておくか、パスポートや出生証明書などと一緒に保管してください。

ので、他の認証と同等に取り扱っていいのかというとなんとも言えない気がしており、なんとも言えない気持ちになった 自分ではあんま気にせず引き続き使うけども・・・

最近 AAL とか MFA かどうかとか、ユーザーの使い方によってはこうなるよね、みたいなものの取り扱いで悩むことが多い

2022年10月にやったこと

IdP

引き続き IdP を書いている

github.com

oidcc-basic-certification-test-plan はなんとなく通せる見通しがたったのでインターフェースを考えながらバグを潰したりしている

これからやること

2022年9月にやったこと

IdP

IdP を書くかという気持ちになったので書いていた

github.com

だいたいかけたかなと思って AppRunner にデプロイしてさっき conformance test 流したら Dynamic Client Registration/userinfo endpoint 周りを全然書いてなかったので本編に入れないという

これからやること