Conformance declaration

browserhive:capture は、そのパッケージが満たすと主張する本仕様の版の URL を 値とする conformsTo という member を持たなければならない。

"browserhive:capture": {
  "conformsTo": "https://uraitakahito.github.io/browserhive-specs/wacz-profile/1.12.0/"
}

宣言をここに置き、datapackage.json の profile member に置かないのは、 そちらがこの用途に使えないためです。

読み手は browserhive:capture が存在するというだけで適合を推定しては ならない。conformsTo が無ければ、そのパッケージが どの版に向けて書かれたかは不明です。

build

browserhive:capture は、パッケージを作ったソフトウェアを機械可読な形で 識別する build member を持たなければならない。

"build": {
  "version": "3.4.0",
  "revision": "0776cae",
  "buildTime": "2026-08-21T04:04:09.000Z"
}

version の書式は定めません。リリースそのものから作られた build は "3.4.0" のような値を持ちますが、リリースとリリースの間で作られた build は "3.4.0-12-gabc1234" のように、直近のリリースからの距離を含んだ値になり 得ます。どちらも「どの build か」を言うという点では同じで、読み手はこれを版数として 解釈するのではなく、同じ値なら同じ build であるという識別子として 扱うべきです。

[[WACZ]] は既に software を定めています。あちらは散文で、書き方が producer ごとに違うため誰も解析しません。build があるのは、同じ事実を形式を推測せずに 機械が読めるようにするためです。

browser

browserhive:capture は、取り込みを行った browser を記述する browser member を持たなければならない。値が string である product member を持たなければならない。

"browser": {
  "product": "Chrome/151.0.7922.137"
}

綴りは定めません。値は browser 自身が名乗るものなので、別のエンジンが作った パッケージは別の形を運びます。読み手は 2 つの値が等しいかどうかを比べられますが、 書式を仮定することはできません。

値は代用のものであってはならない。これを取得できない producer は、 適合するパッケージを作ってはならない。記録した browser が不明な アーカイブはこのプロファイルの外にあり、member を省くことはそれを表明する手段では ありません。

settings

browserhive:capture は、この取り込みに効いていた設定を記録する settings member を持たなければならない。

値は解決後の値でなければならない。要求が指定した値ではありません。 何も指定しない要求も何らかの設定の下で走っており、アーカイブが報告すべきなのはその設定です。

"settings": {
  "signature": "none",
  "viewport": { "width": 1280, "height": 800 },
  "devicePixelRatios": [1],
  "session": "isolated",
  "behaviors": [
    { "id": "autoscroll", "origin": "builtin" },
    { "id": "autofetch", "origin": "builtin" }
  ],
  "limits": {
    "maxResponseBytes": 20971520,
    "maxTaskBytes": 209715200
  },
  "urlPolicies": [
    { "pattern": "*://*.example-analytics.com/*", "action": "deny" }
  ],
  "contentTypePolicies": []
}

この例の session は、取り込みがそれ自身の context で走ったことを 表しています。devicePixelRatios の要素が 1 つなのは、ページを 1 回だけ読み込んだという意味です。behaviors に並ぶ 2 つは実際に走った behavior です —— 有効化されていた ものの一覧ではありません。acceptLanguage は、この取り込みが設定しなかった ので在りません。値そのものは producer が決めるもので、ここに挙げた綴りを このプロファイルが定めているわけではありません。

例外は origin です。behavior の id はそれを提供した側が 決めた名前で、本仕様はその綴りについて何も述べません。しかし origin が答えるのは behavior についての問いではなく パッケージについての問い —— そのコードは producer から来たのか、 リクエストから来たのか —— なので、この 3 値はここで定めます。

devicePixelRatios が数値ではなくリストなのは、取り込みがページを 2 回以上 読み込むことがあるためです。単一の値で記録すると、在る描画が無いと読み手に 伝えてしまいます。

値は読み込んだ順序で並んでいなければならない。読み手が 「どの版がアーカイブに在るか」だけでなく「どの版が最後に描かれたか」を言えるように するためです —— ページの見た目を伴う成果物は、最後の読み込みが残した状態に従います。

2 回読み込む取り込みでは、読み込んだ数だけ値が並びます。要求が acceptLanguage を指定した場合は、それもここに現れます:

"settings": {
  "signature": "required",
  "viewport": { "width": 1280, "height": 800 },
  "devicePixelRatios": [1, 2],
  "session": "isolated",
  "behaviors": [
    { "id": "autoscroll", "origin": "builtin" },
    { "id": "example.com:gallery", "origin": "custom" }
  ],
  "acceptLanguage": "ja,en;q=0.9",
  "limits": {
    "maxResponseBytes": 20971520,
    "maxTaskBytes": 209715200
  },
  "urlPolicies": [],
  "contentTypePolicies": [{ "prefix": "video/", "action": "no-body" }]
}

2 つは測る対象が違います。maxResponseBytes は レスポンス 1 件の本文に掛かり、maxTaskBytes はこのパッケージへ書いた 本文の累計に掛かります。

この違いは読み手にとって実際的です。maxResponseBytes は 1 件ずつを量るので、 それを下回るレスポンスは何件でも入り、パッケージ全体の大きさはこの値からは 分かりません。maxTaskBytes は積み上げた総量を見るので、線を越えた 後は大きさに関わらず本文が落ちます —— 落ちた中に小さなレスポンスが 混じっていても、それは矛盾ではありません。

本文が 1 つも落とされなかった場合でも limits は存在し なければならない。切り詰めがどの線を超えたのかを アーカイブが言える場所は、ここだけです —— 切り詰めの記録は落とした事実と実際の 大きさを運びますが、その大きさが多すぎたかどうかは線と並べて初めて分かります。

completeness の truncatedUrls は、この 2 つのどちらを超えて落ちたのかを 区別しません。 対処が違う (前者は 1 件が大きすぎ、後者はページ全体が重い) にもかかわらずです。 区別が要る読み手は、パッケージの外 —— 取り込みが出した報告 —— を見ることになります。

completeness

browserhive:capture は、そのパッケージが保持していない本文についての 自身の申告である completeness member を持たなければならない。

"completeness": {
  "bodylessUrls": [],
  "truncatedUrls": [],
  "complete": true
}

何も欠けなかった取り込みはこの形になります。complete は両方の配列から 導かれるので、空の配列 2 つと false という組み合わせは現れません。

次は、両方の理由で本文を欠いた取り込みです:

"completeness": {
  "bodylessUrls": [
    "https://example.com/assets/app.css"
  ],
  "truncatedUrls": [
    "https://example.com/media/hero.mp4",
    "https://example.com/media/poster.png"
  ],
  "complete": false
}

この取り込みでは、CSS が 304 としてしか現れませんでした —— 本文が wire を 渡っていないので、アーカイブは持ちようがありません。動画とポスター画像は上限に当たって 落ちたものです。同じ URL が 2 回落ちても、配列には 1 度だけ現れます。

同じページの 2 つの取り込みを比較できるよう、両方の配列は整列されて いなければならない。

2 つが別の member なのは、求められる対応が違うからです。304 はオリジン側の 事情でここからは回復できませんが、上限で落とした本文はこちら側の事情で、上限を上げれば 戻ります。

正当に本文を持たないレスポンスを列挙してはならない —— redirect、204、および要求者が設定した方針で省かれた本文 (urlPolicies の no-body、または contentTypePolicies の項目)。 方針で省いたものを報告しても、読み手が既に決めたこと以上を何も伝えません。

これは省いた本文の大きさに関係なく成り立ちます。方針で省いた本文は 取り込みがそもそも取りに行かなかったもので、上限で落とされたはずがありません。 maxResponseBytes より大きくても、累計が maxTaskBytes に達した後に 届いても、truncatedUrls に載せてはならない（MUST NOT）。 そこに載せれば、要求者が保存しないよう頼んだ本文を、上限を上げれば取り戻せると 読み手に伝えることになります。

coverage

browserhive:capture は、取り込みがページのどこまで下れたかを記述する coverage member を持ってもよい。

"coverage": {
  "scrollExhausted": true,
  "scrollSteps": 40,
  "scrolledPx": 32000
}

3 つの値は互いを読み合うためのものです。scrolledPx は scrollSteps に settings が記録した viewport の高さを 掛けたもの —— ここでは 40 × 800 —— なので、読み手は一方を他方で検算できます。 そして scrollExhausted が true である以上、 この 32,000 ピクセルは取り込みが止まった地点であって、ページが 終わった地点ではありません。その下にあったものは一度も要求されておらず、 したがってパッケージの他のどこにも痕跡を残していません。

スクロールの behavior が何も報告しなかった場合、coverage は存在しては ならない。既定値を入れて書いてはならない —— scrollExhausted: false はページを覆えたという主張であり、一度もスクロール しなかった取り込みはその主張を得ていません。

settle

browserhive:capture は、読み込み後の待ちがどう終わったか —— ページが静まって終わったのか、まだ動いているうちに期限で終わったのか —— を述べる settle member を持たなければならない。

"settle": {
  "strategy": "fully-loaded",
  "endedBy": "quiet",
  "waitedMs": 2310,
  "devicePixelRatio": 1,
  "limits": { "minMs": 1000, "maxMs": 3000, "quietMs": 1000, "networkConcurrency": 0 },
  "load": { "atMs": 210 },
  "network": { "quietAtMs": 2205 },
  "cpu": { "quietAtMs": 2104 },
  "dom": { "quietAtMs": 2004 }
}

時刻はすべて navigation が返ってからのミリ秒で、waitedMs と同じ時計で測る。 producer が自分の操作の間に差し込んだ間は、この時計に含まない。

合図の時刻は、合図が満ちたときは数値、先に期限が来たときは null である。 時刻は null であっても書かなければならない。 書かずに省くと「この合図は見ていなかった」と読まれ、それは別の事実です。

endedBy は 4 つの時刻から導かれる。producer は、どれかが null で あるのに "quiet" を書いてはならず、どれも null でないのに "deadline" を書いてもならない。

期限が先に来たページ:

"settle": {
  "strategy": "fully-loaded",
  "endedBy": "deadline",
  "waitedMs": 3116,
  "devicePixelRatio": 1,
  "limits": { "minMs": 1000, "maxMs": 3000, "quietMs": 1000, "networkConcurrency": 0 },
  "load": { "atMs": 188 },
  "network": { "quietAtMs": 2011 },
  "cpu": { "quietAtMs": 2108 },
  "dom": { "quietAtMs": null }
}

ここではページが文字を書き換え続けていた —— たとえば時計 —— ので、DOM は 1 秒と 静かにならず、取り込みは 3 秒の期限で先へ進みました。網と CPU は静まっており、 静まらなかったのは DOM だけです。

endedBy: "deadline" は取り込みの失敗を意味しません。パッケージは、その時点までに ページがなったものを保持しています。記録しているのはページが静まっていなかったことで、 それはパッケージを証拠として読む人が知る必要があり、しかもパッケージの他のどこからも 取り戻せないものです。

静止の合図はそれぞれ「limits.quietMs の間ページが動かなかったか」を問うもので、 「この先も動かないか」を問うものではありません。窓より長く黙ってから変わるページは、 変わる前に静まったと読まれます。

dismissal

browserhive:capture は、取り込みが記録の前にページから何を取り除いたか、 そして何を探したかを記録する dismissal member を持ってもよい。

同意バナーを取り除いた取り込みは、そのあと保存する文書そのものを変えています。 それを述べるものは他にありません —— 取り除かれた要素は WARC にも索引にも 描画後のスナップショットにも痕跡を残さず、読み手はもともとバナーの無いページと 区別できません。

"dismissal": {
  "selectors": [
    { "framework": "OneTrust", "selector": "#onetrust-banner-sdk" },
    { "framework": "Cookiebot", "selector": "#CybotCookiebotDialog" }
  ],
  "heuristic": { "enabled": true, "minViewportCoverageRatio": 0.3, "minZIndex": 1000 },
  "framework": "OneTrust",
  "removedSelectors": ["#onetrust-banner-sdk"],
  "unusableSelectors": [],
  "removedOverlays": 0,
  "devicePixelRatio": 1
}

除去を試みなかった場合、dismissal は存在しては ならない。したがって不在は「配信されたままのページを 保存した」を意味します。「何も見つからなかった」ではありません。

dismissal が在るとき、何も取り除かなかった場合でも selectors と heuristic は在らなければならない。 結果を検証可能にしているのはこの 2 つです —— 20 件の項目の隣に在る空の removedSelectors は「そのどれもが名指しするバナーをページは持たなかった」 と述べますが、項目が 1 件も無い隣の同じ空リストは「何も探さなかった」としか 述べません。1 件も濾さなかった取り込みにも urlPolicies を必須にしているのと 同じ理屈です。

パッケージは unreadable を framework・ removedSelectors・unusableSelectors・ removedOverlays と並べて持ってはならない。 遂行できなかった除去は何も観測しておらず、その隣に空の結果を書くことは 「ページはバナーを持たなかった」という主張になります。

スクロールもまた取り込みが見るものを変えますが、それが何をしたかは既に coverage —— ページのどこまで下れたかを述べるもの —— が記録しています。 同じ行為の 2 つ目の申告をここに置けばそれは写しであり、いずれ片方が 古いほうになります。

ページを 2 回以上読み込む取り込みは、読み込みごとに要素を取り除きます —— 除去は同意ではないので、同意フレームワークは次の読み込みで再び描画されます。 removedSelectors は読み込みをまたいだ和ではなく、ある瞬間の 1 つの文書に対する観測であり、それをどの読み込みのものかに結び付けるのが devicePixelRatio です。

document

browserhive:capture は、ページ由来の記録をどの文書から読んだかを名乗り、 それらを伏せたかどうかを述べる document member を持たなければなりません （MUST）。

ページ由来の記録とは、pages/pages.jsonl にある取り込みの エントリの text と title、datapackage.json の title、そして accessibility/axtree.jsonl です。これらは ネットワークからではなく描画されたページから読むので、WARC の本文はそれらを縛りません —— 方針が文書の本文を archive に入れなくても、それだけではその文書の文字は 締め出されません。

"document": {
  "url": "https://example.com/next",
  "withheld": "url-policy"
}

文書とは、ページ由来の記録を読んだ時点で主フレームにあった文書です。 要求した URL の文書とは限りません。サーバのリダイレクトや、ページが自分で行う遷移は 文書を置き換え、記録は置き換わった後のものを記述します。url は、そうした リダイレクトや遷移の後に browser が確定させた、その文書の URL です。

deny の項目が主フレームの遷移を止めたとき（urlPolicies を参照）、 前の文書を置き換える文書はありません。browser はその場所に誤りのページを表示しますが、 それは取り込みの文書ではありません。このとき文書は遷移が向かっていた先のもので、 url はリクエストを断った URL です。

withheld は、置くなら次のどれかでなければなりません （MUST）。はじめの 4 つは、文書を、あるいはその本文を archive に 入れなかった方針を名指します（ を参照）。

• "url-policy" —— 文書の URL に最初に当たる urlPolicies の項目の action が no-body。
• "content-type" —— 文書の URL に当たる urlPolicies の項目が無く、 contentTypePolicies の項目がその media type に当たる。
• "no-archive" —— 文書の URL に最初に当たる urlPolicies の項目の action が no-archive。パッケージはその文書の記録を一切持たない。
• "deny" —— 文書の URL に最初に当たる urlPolicies の項目の action が deny。その文書は一度も要求されていない。その時点で読んだ ページ由来の記録は、文書ではなく browser の誤りのページを記述することになる。
• "unattributed" —— どの文書から記録を読んだかを producer が言えない。 たとえば、読んでいる間に主フレームが遷移した。

producer は、その方針が文書に当たったとき、そしてそのときに限り、 withheld を "url-policy"・"content-type"・ "no-archive"・"deny" にしなければなりません （MUST）。 この決まりは両向きに働きます。リダイレクトの中継だけ、あるいは ページが遷移して離れた文書だけに当たった方針は、何も伏せません。文書に当たった方針は、 要求した URL に当たっていなくても、その記録を伏せます。

withheld を置くとき、パッケージはページ由来の記録を持ってはなりません （MUST NOT）。pages/pages.jsonl にある取り込みの エントリは text と title を持ってはならず （MUST NOT）、datapackage.json の title はページから読んではならず（MUST NOT）、 パッケージは accessibility/axtree.jsonl を含んではなりません （MUST NOT）。エントリは理由を textWithheld として 持ってもよく（MAY）、持つなら値は withheld と 等しくなければなりません（MUST）。

大きさの上限で落とした本文は、ページ由来の記録を伏せません。上限は取り込みの側の ものであって要求者のものではなく、本文が archive に収まらなかったページこそ、 文字が最も役に立ちます。

tls

browserhive:capture は、各 HTTPS 接続について browser が見たものを記録する tls member を持ってもよい。存在する場合、 hosts と chains を持たなければならない。

tls.hosts

host を鍵とするオブジェクト。各値は以下の member を持つオブジェクトか、null。

HTTPS で到達したが接続が何も明かさなかった host は、値 null として記録され なければならない。鍵ごと省くと「この host は素の HTTP だった」と 読めてしまいますが、それは別の事実です。

host 名の照合に使われるのは subject ではなく san です。 subject が記録するのは common name であり、現在の読み手はこれを照合に 用いません —— subject の値をもって「その host 名で通用した」と読んでは ならない。

chainRef が無いことを「この host は証明書を提示しなかった」と読んでは ならない。チェーンの取得は host と無関係な理由でも失敗します。

tls.chains

鍵が chainRef の値であり、値が base64 符号化された DER 証明書の配列である オブジェクト。各配列はリーフを先頭として並んでいなければならない。

チェーンを共有する host は 1 つの項目を共有すべきである。 1 ページの host 間で証明書が再利用されることは多く、host ごとに複製を持つとパッケージが 何の利得もなく膨らみます。

チェーンは参照ではなく保存します。Certificate Transparency が同じバイト列を持っては いますが、第三者のサービスが到達可能であり続けることに依存する証拠は、その分だけ弱く なります —— そして検討する価値のある事例である私設 CA のチェーンは、そもそもそこに 記録されたことがありません。

"tls": {
  "hosts": {
    "example.com": {
      "protocol": "TLS 1.3",
      "cipher": "AES_128_GCM",
      "subject": "example.com",
      "san": ["example.com", "www.example.com"],
      "issuer": "Example Issuing CA",
      "validFrom": "2026-06-30T20:37:58.000Z",
      "validTo": "2026-09-28T21:37:55.000Z",
      "chainRef": "9a57318f8c89976c"
    },
    "cdn.example.net": {
      "protocol": "QUIC",
      "cipher": "AES_128_GCM",
      "subject": "*.example.net",
      "san": ["*.example.net", "example.net"],
      "issuer": "Example Issuing CA",
      "validFrom": "2026-08-05T20:42:14.000Z",
      "validTo": "2026-10-28T20:42:13.000Z",
      "chainRef": "c52653c92800f6fd"
    },
    "img.example.net": {
      "protocol": "TLS 1.3",
      "cipher": "AES_128_GCM",
      "subject": "*.example.net",
      "san": ["*.example.net", "example.net"],
      "issuer": "Example Issuing CA",
      "validFrom": "2026-08-05T20:42:14.000Z",
      "validTo": "2026-10-28T20:42:13.000Z",
      "chainRef": "c52653c92800f6fd"
    },
    "api.example.org": {
      "protocol": "TLS 1.3",
      "cipher": "AES_256_GCM",
      "subject": "api.example.org",
      "san": ["api.example.org"],
      "issuer": "Example Issuing CA",
      "validFrom": "2026-05-14T09:03:11.000Z",
      "validTo": "2026-08-12T09:03:10.000Z"
    },
    "beacon.example.org": null
  },
  "chains": {
    "9a57318f8c89976c": [
      "MIIDbzCCAxSgAwIBAgIRALaMq73qMP3mE30B…",
      "MIICjDCCAhKgAwIBAgIQf5wJDMcM1Y2ZBpFB…"
    ],
    "c52653c92800f6fd": [
      "MIIIUDCCBzigAwIBAgIQHnJSlrCYIdkSw8c/…",
      "MIIFCzCCAvOgAwIBAgIQVJ5xIVMKmZ0sNHxs…"
    ]
  }
}

この例は 5 つの host を記録しています。上の規定がそれぞれどう現れるかを見てください。

• cdn.example.net と img.example.net は同じ chainRef を指しています —— 同じ証明書を提示したので、チェーンは chains に 1 度だけ保存されています。
• api.example.org には chainRef がありません。 証明書は提示されており (subject 以下がその証拠です)、取れなかったのは チェーンだけです。
• beacon.example.org は null です。HTTPS で到達しましたが、 接続は何も明かしませんでした。鍵ごと省いていないのは、省くと「この host は素の HTTP だった」と読めてしまうためです。
• cdn.example.net の protocol は "QUIC" です。 この member は browser が報告した文字列であり、TLS の版とは限りません。

chains の値は base64 符号化された DER です。例では読みやすさのため途中で 切ってありますが、実際には 1 通あたり 1–2 KB 程度の文字列になります。

urlPolicies

urlPolicies は順序付きの配列です。各項目は 2 つの member を持つ オブジェクト:

pattern は、リクエストの URL 全体に当てます。* は 0 字を含む 任意の文字の並びに当たり、ほかの文字は ? も含めてその字だけに当たり、 大文字と小文字は区別します。そのため、パターンは query を見込んで書く必要があります —— *://example.com/a.js は https://example.com/a.js?v=2 に 当たりません。

deny の項目は、ページのどの部分が起こしたかに関わらず、取り込みが起こす すべてのリクエストに働きます。主フレームの遷移（サーバのリダイレクトの先と、script が 始めた遷移を含む）、フレーム（別サイトのフレームを含む）、そして dedicated worker と service worker です。これらのリクエストの 1 つでも取り込みを行う機械から出した producer は、その項目を守っていません。取り込みの間、ページはウィンドウを開きません （ を参照）。項目が届くべきウィンドウはありません。

最初の遷移に deny の項目が当たった取り込みは、パッケージを作っては なりません（MUST NOT）。何も読み込まれていないので、 settle の報告は走らなかった待ちを記述することになります。ページを読み込んだ後に 遷移を断られた取り込みは、パッケージを作ってもよく（MAY）、 その document は withheld: "deny" を持ちます。

WebSocket の handshake は、ほかのリクエストのようには止められません。URL に deny の項目が当たる WebSocket を開いた取り込みは、パッケージを作っては なりません（MUST NOT）。リクエストは送られており、 パッケージはそうでないと主張することになるからです。

この配列は空のときでも存在して MUST、 空の配列は「効いていた policy が無い」という意味で MUST。この規則が無いと読み手は、 特別なものを何も要求しなかったページと、要求されたものを記録しないことにした 取り込みとを区別できません。同じパッケージについての、別の主張です。

順序は取り込みがパターンを評価した順であり、取り込みは 一致した最初の項目を適用して MUST。 順序を記録することが、複数のパターンが当たりうる URL について 「どの policy が適用されたのか」に読み手が答えられる根拠になります。

"urlPolicies": [
  { "pattern": "*://cdn.example.com/tracker.js", "action": "deny" },
  { "pattern": "*://cdn.example.com/*",          "action": "no-body" }
]

この例では tracker.js へのリクエストは一度も送られず、 同じホストの他のものは取得されて本文なしで記録されます。2 つを入れ替えると 取り込みがしたことが変わります —— 広いほうのパターンが先に当たり、 tracker は取得されます。

contentTypePolicies

contentTypePolicies は、prefix （応答のメディア型に当てる）と action を持つ項目の配列です。 この版が定める action は no-body のみ —— メディア型は応答が届いてからしか分からないので、deny は 適用できません。

この配列も、空のときでも存在して MUST。 理由は urlPolicies と同じです。

"contentTypePolicies": [
  { "prefix": "video/", "action": "no-body" }
]

Records of withheld requests

deny または no-archive の policy が適用された リクエストのそれぞれについて、パッケージは WARC の metadata レコード —— 以下 withheld request のレコード —— を MUST 含みます。その WARC-Target-URI はリクエストの URL で MUST、application/warc-fields の 本文は次を MUST 含みます:

WARC/1.1
WARC-Type: metadata
WARC-Target-URI: https://www.example-analytics.com/collect?v=2
WARC-Date: 2026-09-06T02:14:31.882Z
Content-Type: application/warc-fields
Content-Length: 112

action: deny
pattern: *://*.example-analytics.com/*
method: POST
resourceType: XHR

deny は取り込みが起こすすべてのリクエストに届くので、そのレコードは、 ページのどの部分がリクエストを出したかに関わらず書かなければなりません （MUST）。producer がほかには記録しない部分のリクエストも 含みます。

withheld request のレコードはレスポンスも本文も持ちません。主張しているのは、 ページがその URL を要求したこと、そしてこのプロファイルの producer が それについて何をするか決めたこと —— リクエストが失敗したという意味でも、 オリジンが何も返さなかったという意味でもありません。オリジンに到達 できなかった取り込みは、これをこの形で報告しては MUST NOT。

no-body の policy はこの種のレコードを生みません。 request / response のレコードは通常どおり書かれ、欠けている本文は 方針で省いたものとして報告されます —— 上限で落としたものとしては報告されません (completeness を参照)。

withheld request のレコードは、パッケージの CDXJ 索引に現れることを 要求されません。これを探す読み手は WARC を読みます。

Members

storage は profile、stage、 valuesRecorded、origins を 持たなければならない（MUST）。

• profile —— この member が従う規則。本仕様のこの版では値は "browserhive:storage/2" でなければならない（MUST）。 記録する内容や digest の計算方法を変えた producer は、この値を 変えなければならない（MUST）。
• stage —— 取り込みのどの時点で storage を読んだか。この版では値は "after-behaviors" でなければならない（MUST）。 stage が規範なのは、内容が変わるからです —— ページは動作しながら storage に書き込むので、behavior が走る前に読んだものと 後に読んだものは、別の状態を表します。
• valuesRecorded —— このパッケージが、下で定義するディレクトリに 保存されていた値も併せて運んでいるかどうか。これは「値を求められた」ことを 述べるのであって、「すべての origin の値が在る」ことではありません —— valuesOversize と印の付いた origin の値は在りません。 を参照。
• origins —— 取り込みが観測できた origin ごとに 1 つの項目を持つ配列。

Origin entries

各項目は origin を持たなければならない（MUST） —— 値は [[WACZ]] の enclosing document と同じ直列化形式、すなわち scheme・host、 および既定でない場合の port です。

web storage は origin ごとに区切られており、ページは日常的に自分以外の origin の 文書を埋め込みます —— 広告、計測のフレーム、埋め込みのプレイヤー。それらは それぞれ自分の storage を持ち、ページ自身の origin からは見えません。 したがってこれは「そのページの storage」の記録ではありません —— 取り込みが観測できた origin ごとに 1 項目であり、 第三者の origin の項目が在ることは異常ではなく想定どおりです。

そもそも storage を持てない origin —— about:blank の文書や data: URL のような opaque origin —— は記録するものが無いので 現れません。

各項目は、local と session の両方を持つか、あるいは unreadable という単一の member を値 true で持つかの いずれかでなければならない（MUST）。後者は「その origin の storage を 取り込みが読めなかった」という意味です。これは storage が空だった origin —— "keys": 0 の area として書かれる —— とは別です。 同じ形で記録すると、この member が取り除こうとしている曖昧さが戻ってきます。

ここの項目と storage/origins.jsonl の行は、1 つの記録の 2 つの半分です。項目はその origin の storage が どう見えたかを述べ —— 鍵がいくつ、何バイト、digest は何 —— 常に在ります。行は何が入っていたかを述べ、値を求められたときにだけ 在ります。どちらをパッケージが持っているかは valuesRecorded が 述べます。値を求められてもなお行を持たない origin は 2 通りあります —— 行に入れるものが無かった（unreadable として記録）か、 行に入れるものが大きすぎた（valuesOversize として記録）か。 その 2 つを区別するのが項目で、だからこそ項目のほうが常に書かれます。

local と session はそれぞれ以下を 持たなければならない（MUST）。

• keys —— その area が保持していた鍵の数。
• bytes —— その area の合計の大きさ。すべての鍵と値の UTF-8 表現で数えます。browser 自身の quota 会計が使う UTF-16 コード単位ではありません。
• digest —— "sha256:" に続けて、その area の SHA-256 を 小文字の 16 進で。計算は、鍵をコードポイント順に並べ、各要素が key U+0000 value U+0000 を UTF-8 で寄与する形で行います。 並べ方と区切りは規範です —— これを決めないと同じ内容が別の digest になり、 取り込みをまたいで比較するという digest の目的が失われます。

digest を値へのコミットメントとして扱ってはならない（MUST NOT）。 値はしばしばエントロピーが低く —— フラグ、テーマ名、時刻 —— そのような digest は推測で容易に逆算できます。

項目は valuesOversize を値 true で 持ってもよい（MAY）。これは「この origin の保存値は 大きすぎたため運ばれなかった」こと、したがって「この項目がその origin について パッケージが持つすべてである」ことを述べます。 unreadable と並べてはならず（MUST NOT） —— 読めなかった storage には、超えるべき大きさがありません —— valuesRecorded が false のときにも 置いてはならない（MUST NOT）。そこではどの origin の値も もともと運ばれる予定が無く、この member は誰も下していない判断を 報告することになります。

valuesOversize を持つ項目は、それでも local と session を持たなければならない（MUST）。 ここが unreadable との違いで、意図的なものです —— 取り込みはこの origin を読めています。鍵がいくつあり、 どれだけ大きかったかを知っています。その数字が member の隣に在れば、 読み手は「値が欠けていること」と「どれだけ欠けているか」の両方を知り、 上限を上げて撮り直すかどうかを判断できます。area を落として項目を書くのは、 すでに手元にある計測を捨てることです。

{
  "origin": "https://heavy.example",
  "local": { "keys": 1, "bytes": 2129905, "digest": "sha256:1aeb74b512b17f6fc43ade8575d452df142ade5d1515a4afcaf05dd199688c38" },
  "session": { "keys": 0, "bytes": 0, "digest": "sha256:e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855" },
  "valuesOversize": true
}
    

Snapshot members

各行は profile・url・takenAt・ stage・tree を含まなければなりません （MUST）。

• profile —— その行が従う刈り込み規則。本仕様のこの版では、値は "browserhive:axtree/1" でなければなりません （MUST）。刈り込み規則を変える producer は、この値も 変えなければなりません（MUST）—— 読み手が、何が 捨てられたのかを言えるようにするためです。
• url —— そのスナップショットを読んだ文書の URL。document の url と等しくなければなりません（MUST）。
• takenAt —— 撮った時刻。[[RFC3339]] のタイムスタンプ。
• stage —— 取り込みのどの時点で撮ったか。この版では値は "after-behaviors" でなければなりません （MUST）。時点が規範的なのは、木が変わる からです。 autoscroll は lazy load を発火させるので、behavior の 前に撮った木と後に撮った木は、別のページを記述しています。
• tree —— ノードの配列。次節を参照。

各行はさらに devicePixelRatio・viewport・ nodes を持つべきです（SHOULD）—— 順に、そのスナップショットがどのパスのものか、効いていた viewport、そして 刈り込む前のノード数。最後の 1 つによって、読み手はどれだけ 捨てられたのかを見ることができます。

{
  "profile": "browserhive:axtree/1",
  "url": "https://www.iana.org/",
  "takenAt": "2026-08-22T02:55:56.759Z",
  "stage": "after-behaviors",
  "devicePixelRatio": 1,
  "viewport": { "width": 1280, "height": 800 },
  "nodes": 255,
  "tree": [
    {
      "role": "RootWebArea",
      "name": "Internet Assigned Numbers Authority",
      "children": [
        { "role": "heading", "name": "Domain Names", "level": 2 },
        { "role": "image", "name": "logo",
          "url": "https://www.iana.org/_img/iana-logo-header.svg" }
      ]
    }
  ]
}
    

読みやすさのため複数行で示しています。ファイル中では、各スナップショットは ちょうど 1 行を占めます。

Node shape

すべてのノードは role を持たなければなりません （MUST）。ノードは role・ name・level・url・checked・ expanded・disabled・required・ value・children 以外の member を持ってはなりません （MUST NOT）。

このうち 2 つは、他より重い意味を持ちます:

• level —— 見出しの深さ。これが無いと heading の ノードを互いに区別できず、この木が記録するために在る文書構造そのものが 失われます。
• url —— 画像やリンクが指す先。ノードと archive/ に 記録されたレスポンスを結ぶのはこれで、「ここに図があった」から「その図の バイト列」へ辿れるようになります。

値が無い・空・false の member は書いてはなりません （MUST NOT）。全ノードに既定値を書くと、それが囲んでいる 中身より嵩が大きくなります。

Pruning

browser が ignored と印を付けたノードは tree に現れてはなりません （MUST NOT）。その子は残し、最も近い残されたノードの 下に付けなければなりません（MUST）。

これが、隠されたテキストを記録に持ち込まないための仕掛けです。 aria-hidden や display: none で外された部分木は ignored なノードなので、そもそもこのファイルに届きません。したがって読み手は、 この木を「見えていたもの」の記述として扱えます —— WARC の 本文だけからは支えられない、より強い主張です。

role が generic・none・InlineTextBox の ノードも tree に現れてはならず（MUST NOT）、 その子は同じように残さなければなりません（MUST）。 これらの role はそれ自体では意味を持たず、残すと木の深さが倍になるだけで、 読み手が使えるものは何も増えません。

viewport の外にあることを理由にノードを落としてはなりません （MUST NOT）。エージェントにとっては妥当な判断です —— 見えないものは操作できないので。しかし、誰もスクロールしなかった部分を捨てた アーカイブは、そのページの記録ではありません。

Runtime

適合するパッケージは behaviors/runtime.js というエントリを 持ってもよい（MAY）。存在する場合、それは producer が ページの中で評価したソースを、バイト単位でそのまま 持たなければなりません（MUST）。

producer がそのようなソースを評価したときは在らなければならず （MUST）、そうでなければ在ってはなりません（MUST NOT）。 したがってその存在は「ページ上でコードが走った」ことを述べます —— その後どの behavior が何かをしたかどうかとは無関係に。

要求しているのは「バイト単位でそのまま」であって、読みやすさではありません。 runtime を minify する producer は minify された形を記録します —— それがページの受け取ったものだからです。人が読める形が要る読み手には build があり、それがパッケージを作ったソフトウェアを名指しします。

Request-supplied behaviors

適合するパッケージは behaviors/custom.jsonl というエントリを 持ってもよい（MAY）。存在する場合、それは JSON Lines で なければなりません（MUST） —— 1 行に 1 つの JSON オブジェクトで、各オブジェクトは取り込みのリクエストと共に 届いた behavior を 1 つ記録します。

{
  "profile": "browserhive:behaviors/1",
  "id": "example.com:gallery",
  "source": "class { static id = \"example.com:gallery\"; … }"
}
    

各行は profile・id・source を 持たなければなりません（MUST）。

• profile — その行が従う規則。本仕様のこの版では値は "browserhive:behaviors/1" で なければなりません（MUST）。
• id — その behavior が登録された名前。 settings.behaviors のうち origin が "custom" である項目は、すべてここに行を 持たなければなりません（MUST）。 逆は成り立ちません —— 対応する項目を持たない行が 在ってもよい（MAY）。behavior はページに置かれた うえで、何もしないことを選べるためです。
• source — 届いたままのコード。バイト単位でそのまま。

producer がリクエスト由来の behavior をページに置いたときは 在らなければならず（MUST）、そうでなければ 在ってはなりません（MUST NOT）。したがってその不在は 「このパッケージはリクエストから来たコードを持たない」ことを述べます。

条件は「置いたか」であって「走ったか」ではありません —— runtime と同じ条件です。ページに置かれた コードは、そのあと何を決めたにせよ、そこで走っています。作用したコードだけを 記録するアーカイブは、実行されたコードを取りこぼします。

behavior の名前は、それを提供した側が決めるもので、何の制約もありません —— 現に使われている名前には : も / も含まれます。 それをエントリのパスに使うと、名前がパッケージの中の置き場所を 決めてしまいます。ファイル 1 つ・behavior 1 つにつき 1 行という形は、 名前を経路ではなく値のままに保ちます。

Reading these entries

読み手は behaviors の中身を実行してはなりません （MUST NOT）。あれは producer が何を走らせたかの記録であって、保存されたページの 一部ではありません。パッケージを replay するのに、それらを再び走らせることを 求めるものは何もありません。

これを明記するのは、適合するパッケージの中で中身が実行可能なエントリが これだけであることと、パッケージを replay する読み手は既に実行の context を 開いているためです。

Supplied scripts

preload のスクリプトを走らせた適合パッケージは、それらを preload/scripts.jsonl に、1 行 1 つの JSON オブジェクトとして、 登録した順に記録しなければならない（MUST）。 各行は profile（文字列 "browserhive:preload/1"）・ id（持ち込まれた名前）・source（評価されたとおりの スクリプト）を持たなければならない（MUST）。

id が、パッケージの中での項目の名前を決めては ならない（MUST NOT）。それは行の中の値です。

名前は送った側が決めたもので、制約がありません。経路に見える名前は、 そうでなければ項目の置き場所を決めてしまいます。リクエストが持ち込む behavior と 同じ規則で、理由も同じです。

Reading these entries

読み手は preload の中身を実行してはならない （MUST NOT）。behaviors と同じく、producer が走らせたものの記録であって、 アーカイブされたページの一部ではありません。

preload/scripts.jsonl が無いことと、settings の preload が空であることは、合わせて「そのようなコードは走らなかった」と 述べます。読み手はこの 2 つを 1 つの主張として扱わ なければならない（MUST）—— ファイルを持つのに member を欠く（またはその逆の）パッケージは適合しません。