M1 バトル
  • 清水さん
    • ページ同士の情報の結合が意図されていないものをうまく結合したい
      • 例：GitHub 上のソースコードと、そこで利用されているライブラリのドキュメント
        • 📝 「github のソースコード」と書かれていた
    • 既存手法の問題点
      • Web スクレイピング
        • DOM 解析
        • ログイン
          • 拡張機能必要
          • ? Web ブラウザ内の情報をファイルシステムにマップすることの嬉しさは？
            • HTML に数多の属性が付いている場合、その情報は欠落しないのか
        • XPath
          • ? 指定の方法がいろいろあるのでは
            • どこまで許容？
    • 質疑
      • 過去は XHTML を XSLT で join
        • URL から得られる Web 上のファイルをマップにしていた
        • XSLT は XML で記述される。黒魔術（メタプログラミング）できるかも
      • 表だけサポートするなら SQLite につっこめればいい気がする
        • 必ずしも table であるとは限らない。DOM 要素単位で曖昧性を許容したい
  • 曽山さん
    • 背景
      • E commerce などで自分の個人情報、機密情報を入力することがある
        • これらの情報はコピーされうる
        • 第三者の元に向かう可能性がある
    • 目的
      • 利用を制限するためのポリシー（なんだろう）
      • 後から追跡できるように
    • 提案手法
      • 📝 ログサーバが複数個ある
        • 冗長性が強くなって可用性が上がる
          • 整合性を担保する仕組みはこれから考える
        • ログ閲覧時には情報提供者を認証
    • 脅威モデル
      • サービス側の都合により、管理プログラムやログサーバの実装は改竄されうる
        • 管理プログラムを名乗るものが個人情報やログサーバにアクセスできるのか？
          • できない。ログは暗号化されている。管理プログラムのみが情報を取得できる。
            • 通信相手が変であるか、を検証できる。
      • 各プログラムはいつでも止まる
      • 永続記憶のデータは改竄・書き戻しされうる
      • ネットワーク zero trust
    • 質疑
      • 赤色は見えづらい人が多め
        • bold, underline, italic などで強調するとよい
      • 量子耐性暗号
        • 理論物理をやっている鹿野先生が今度から cs で研究室をもつ
        • remote attestation やぶられたらどうしよう
      • マイナンバーカードで解決できていないもの
        • 住民票
        • 登記簿登録は誰でも取れる
          • 地番と登記簿登録のは違う
        • 弁護士などは戸籍を自由に見られる
          • ログが残らない
  • 木場迫さん
    • 背景
      • 実際の場所では、訪問前にその場所の詳細を調べる。住所など
      • Web サイトでも同様
        • アクセス先の信頼性
      • 現在
        • 利用者が自ら情報を収集し、集約する
          • 収集時点で危ない可能性すらある
          • 集約にも時間がかかる
          • ? 具体的にはどのような？
      • 提案手法
        • ある日本語で記述された情報のある Web にアクセスする以前に、そのサイトの信頼性を外部のデータベースを用いて判定する
          • ? 外部のデータベース
        • システム
          • キーワード推定
            • HTML 要素からキーワードの抽出。どのように
              • ? HTML と rendered の両者から抽出する理由
            • HTML, rendered 具体的には
              • ? トップページ
              • ? 非表示で ← headless ということ？
            • HTML 具体的には
              • ? <copy> タグってあるの？
              • ? どのようなタグから抽出？それはどのように決めた基準？
            • rendered 具体的には
              • OCR 使ってテキストとる
                • ? 赤い見出しなどはより強い意味を持つと考えて取ることもできそう。OCR の実装によっては textbox のサイズなど取れるならできるのかも？
            • aggregation
              • 多数決、LLM
                • ? rendered の部分を LLM にしてしまうこともできるのでは
          • 情報取得
            • 抽出したキーワードを用いて外部データベースから情報取得
              • 具体的には企業年鑑、whois、SNS profiles
        • 現状
          • テキスト抽出器できた
        • まとめ
    • 質疑
      • whois は偽装されうる。サイトを丸々コピーしようとしたとき、少しだけでも違っているところがあれば怪しいと思えることがある。それを検知したい。そのため、最初にキーワードを抽出するというアプローチを取った。
  • 石原さん 自己状態把握のための DNS クエリの分析手法
    • 背景
      • マルウェアに侵入した脅威を早期検知し、被害を最小限に抑える
        • ? DoH 気づけない気がする
    • 名前解決について
      • full-service resolver
    • 提案手法
      • full-service resolver でアクセスログを取得して、利用者の自己状態の変化を確認
        • 自己状態：利用者による普段通りの動作を定義できる
          • resolver の利用者は、いつも同じ IP addr を使っている前提
          • ? DNS パケットって言うのか
      • 過去の動作とその日の動作を比較する
        • ? 「その日の動作」を確定させてから通知するのか？それとも、即時？
          • 集計したい様子が見られた。一日数回とあるが、頻度は？
    • まとめ
      • 現状
        • 先行研究調査
    • 質疑
      • 一日何件ぐらいの query があるか？
        • わからず
      • スライド上の「自己状態」は、暗黙的に正常である方を refer しているので聴衆とのズレが生じる
      • パケットの入出を full-service resolver で見るのではなく、client の network interface で見たらいいのではないか
        • さすれば、client IP が同一であるという過程を置く必要がなく、client の egress だけ見ればよくなりそう
        • 単一の利用者を、他者の利用状況と比較したい
          • ある組織内での振る舞いを比較