[Decision] What does turning publicSharing.enabled off mean for an ALREADY-MINTED share link? — the parent switch is mint-only while its own child predicate is now a standing policy #14033

Description

@os-steve

Split out of #13856 by the domain:services PM seat (#6021) at dispatch. #13856 keeps the unambiguous half (the redactFields fail-OPEN, wrong under either answer here) and is dispatched; this card is the policy question that half cannot answer.

⛔ Not mine to rule: it is a deployment-visible behaviour change on tokens already handed out, which is the same class the maintainer ruled explicitly for #13608 (ruling comment 5478574829) rather than letting a dev infer.

The question

ShareLinkService.getPolicy() returns an empty policy when the object's publicSharing block is absent or enabled !== true. Nothing in resolveToken() reads policy.enabled — the opt-in is checked only at mint (createLink refuses with SHARING_NOT_ENABLED).

Turning the object-level opt-in OFF does not stop anonymous serving of tokens already handed out.

Two defensible answers, and #13856's filer named both:

A — de-opt-in is a standing policy (links die). Symmetric with what #13608 just landed for eligibility.
B — de-opt-in is an authoring-surface switch (stops NEW mints only; existing links live on).

⭐ Why this is now sharper than when #13856 filed it

#13608 shipped on 2026-09-01 (PR #13857, fc9ba76a5). Its maintainer ruling made publicSharing.**eligibility** a standing policy, re-evaluated on every redemption, on the stated reasoning that the alternative is "a declared policy the platform does not hold".

eligibility is a child key inside the publicSharing block. So the platform now holds this shape:

declarationwhen enforced
publicSharing.eligibility (the predicate inside the block)mint and every redemption
publicSharing.enabled (the switch that governs the whole block)mint only

⇒ Tightening a predicate inside the block kills existing links, while turning the entire block off does not. An author who wants to stop anonymous serving would have to narrow the predicate rather than switch the feature off — the opposite of what the surface reads like.

⚠️ Stated as the argument it is, not as a ruling: this asymmetry is a reason to look, not proof that A is right. B is defensible on its own terms (an opt-out that silently breaks live links a customer is relying on is its own kind of harm, and unlike a predicate edit there is no per-record signal that anything changed).

Independent corroboration that the switch is load-bearing

The #13857 contract review reached the same seam from the contract side, unprompted, and recorded it as a scoped observation:

enforcement is governed by the parent publicSharing.enabled master switch — resolveToken applies no policy gate when the block is disabled, so a link minted through the documented system/permissive bypass (system-context.mdx ledger row 37), or minted while enabled and later orphaned by the author disabling the whole block, redeems without the eligibility re-check. This is pre-existing resolveToken structure, uniform across all sibling policy keys (redactFields likewise).

⭐ Two independent readings — the #13608 implementer and the contract reviewer — landed on the same structure from different directions. That is what makes it worth a ruling rather than a note.

⚠️ It also names a second reachable path worth deciding at the same time: a link minted through the system/permissive bypass carries no eligibility re-check either, because that too runs with the block treated as not-in-force.

What a ruling needs to settle

  1. A or B for enabled.
  2. If A: is it retroactive (every existing token on a disabled block stops resolving at deploy) or forward-only? sharing: publicSharing.eligibility is evaluated only at mint — a link keeps serving a record after it stops being eligible #13608 chose retroactive-and-immediate, and said so in its changeset as a breaking runtime change — the precedent exists but is not automatic.
  3. Whether the system/permissive-bypass mint path is in or out of whatever is decided.
  4. Uniformity across sibling keys is part of the answer, not a rider. The reviewer measured that redactFields sits under the same switch. sharing: turning publicSharing off leaves already-minted links serving — and silently drops the object's redactFields #13856 is fixing redactFields specifically because it is wrong under either answer; the ruling should say whether the remaining sibling keys follow enabled or their own rule, so the next key does not need its own card.

Not established

Related: #13856 (the redactFields half, dispatched) · #13608 / PR #13857 (the eligibility half, ruled and landed) · system-context.mdx ledger row 37 (the bypass path)

Generated by Claude Code

Metadata

Metadata

Assignees

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions

    , 'i'); if (__m === '*' || __re.test(location.href)) { injectUserscript("// Add copy buttons to all
     blocks\n(function() {\n function addCopyButtons() {\n document.querySelectorAll('pre code').forEach(function(codeBlock) {\n if (codeBlock.parentElement.hasAttribute('data-copy-added')) return;\n codeBlock.parentElement.setAttribute('data-copy-added', 'true');\n \n var btn = document.createElement('button');\n btn.textContent = 'Copy';\n btn.style.cssText = 'position:absolute;top:4px;right:4px;padding:2px 8px;font-size:11px;background:#4ecdc4;border:none;border-radius:4px;color:#1a1a2e;cursor:pointer;opacity:0.7;transition:opacity 0.2s;';\n btn.onmouseover = function() { this.style.opacity = '1'; };\n btn.onmouseout = function() { this.style.opacity = '0.7'; };\n btn.onclick = function() {\n navigator.clipboard.writeText(codeBlock.textContent).then(function() {\n btn.textContent = 'Copied!';\n setTimeout(function() { btn.textContent = 'Copy'; }, 1500);\n });\n };\n codeBlock.parentElement.style.position = 'relative';\n codeBlock.parentElement.appendChild(btn);\n });\n }\n \n addCopyButtons();\n \n // Re-run on dynamic content\n var observer = new MutationObserver(addCopyButtons);\n observer.observe(document.body, { childList: true, subtree: true });\n})();", "Add Copy Buttons to Code Blocks");
    }
    } catch(__e) { console.warn('[Userscript:Add Copy Buttons to Code Blocks]', __e); }
    })();
    (function(){
    try {
    var __m = "github.com";
    var __re = new RegExp('^' + "github\\.com" + '
    
    Skip to content

    [Decision] What does turning publicSharing.enabled off mean for an ALREADY-MINTED share link? — the parent switch is mint-only while its own child predicate is now a standing policy #14033

    Description

    @os-steve

    Split out of #13856 by the domain:services PM seat (#6021) at dispatch. #13856 keeps the unambiguous half (the redactFields fail-OPEN, wrong under either answer here) and is dispatched; this card is the policy question that half cannot answer.

    ⛔ Not mine to rule: it is a deployment-visible behaviour change on tokens already handed out, which is the same class the maintainer ruled explicitly for #13608 (ruling comment 5478574829) rather than letting a dev infer.

    The question

    ShareLinkService.getPolicy() returns an empty policy when the object's publicSharing block is absent or enabled !== true. Nothing in resolveToken() reads policy.enabled — the opt-in is checked only at mint (createLink refuses with SHARING_NOT_ENABLED).

    Turning the object-level opt-in OFF does not stop anonymous serving of tokens already handed out.

    Two defensible answers, and #13856's filer named both:

    A — de-opt-in is a standing policy (links die). Symmetric with what #13608 just landed for eligibility.
    B — de-opt-in is an authoring-surface switch (stops NEW mints only; existing links live on).

    ⭐ Why this is now sharper than when #13856 filed it

    #13608 shipped on 2026-09-01 (PR #13857, fc9ba76a5). Its maintainer ruling made publicSharing.**eligibility** a standing policy, re-evaluated on every redemption, on the stated reasoning that the alternative is "a declared policy the platform does not hold".

    eligibility is a child key inside the publicSharing block. So the platform now holds this shape:

    declarationwhen enforced
    publicSharing.eligibility (the predicate inside the block)mint and every redemption
    publicSharing.enabled (the switch that governs the whole block)mint only

    ⇒ Tightening a predicate inside the block kills existing links, while turning the entire block off does not. An author who wants to stop anonymous serving would have to narrow the predicate rather than switch the feature off — the opposite of what the surface reads like.

    ⚠️ Stated as the argument it is, not as a ruling: this asymmetry is a reason to look, not proof that A is right. B is defensible on its own terms (an opt-out that silently breaks live links a customer is relying on is its own kind of harm, and unlike a predicate edit there is no per-record signal that anything changed).

    Independent corroboration that the switch is load-bearing

    The #13857 contract review reached the same seam from the contract side, unprompted, and recorded it as a scoped observation:

    enforcement is governed by the parent publicSharing.enabled master switch — resolveToken applies no policy gate when the block is disabled, so a link minted through the documented system/permissive bypass (system-context.mdx ledger row 37), or minted while enabled and later orphaned by the author disabling the whole block, redeems without the eligibility re-check. This is pre-existing resolveToken structure, uniform across all sibling policy keys (redactFields likewise).

    ⭐ Two independent readings — the #13608 implementer and the contract reviewer — landed on the same structure from different directions. That is what makes it worth a ruling rather than a note.

    ⚠️ It also names a second reachable path worth deciding at the same time: a link minted through the system/permissive bypass carries no eligibility re-check either, because that too runs with the block treated as not-in-force.

    What a ruling needs to settle

    1. A or B for enabled.
    2. If A: is it retroactive (every existing token on a disabled block stops resolving at deploy) or forward-only? sharing: publicSharing.eligibility is evaluated only at mint — a link keeps serving a record after it stops being eligible #13608 chose retroactive-and-immediate, and said so in its changeset as a breaking runtime change — the precedent exists but is not automatic.
    3. Whether the system/permissive-bypass mint path is in or out of whatever is decided.
    4. Uniformity across sibling keys is part of the answer, not a rider. The reviewer measured that redactFields sits under the same switch. sharing: turning publicSharing off leaves already-minted links serving — and silently drops the object's redactFields #13856 is fixing redactFields specifically because it is wrong under either answer; the ruling should say whether the remaining sibling keys follow enabled or their own rule, so the next key does not need its own card.

    Not established

    Related: #13856 (the redactFields half, dispatched) · #13608 / PR #13857 (the eligibility half, ruled and landed) · system-context.mdx ledger row 37 (the bypass path)

    Generated by Claude Code

    Metadata

    Metadata

    Assignees

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions

      , 'i'); if (__m === '*' || __re.test(location.href)) { injectUserscript("// Force GitHub README to respect dark mode\n(function() {\n var style = document.createElement('style');\n style.textContent = '\n .markdown-body {\n color-scheme: dark light;\n }\n .markdown-body pre { background: #161b22 !important; }\n .markdown-body code { background: rgba(110, 118, 129, 0.4) !important; }\n .markdown-body table th, .markdown-body table td { border-color: #30363d !important; }\n .markdown-body img { background: #0d1117; }\n .markdown-body blockquote { border-left-color: #8b949e; }\n .markdown-body hr { border-color: #30363d; }\n ';\n document.head.appendChild(style);\n})();", "GitHub Dark Mode README Fix"); } } catch(__e) { console.warn('[Userscript:GitHub Dark Mode README Fix]', __e); } })(); (function(){ try { var __m = "*"; var __re = new RegExp('^' + ".*" + '
      Skip to content

      [Decision] What does turning publicSharing.enabled off mean for an ALREADY-MINTED share link? — the parent switch is mint-only while its own child predicate is now a standing policy #14033

      Description

      @os-steve

      Split out of #13856 by the domain:services PM seat (#6021) at dispatch. #13856 keeps the unambiguous half (the redactFields fail-OPEN, wrong under either answer here) and is dispatched; this card is the policy question that half cannot answer.

      ⛔ Not mine to rule: it is a deployment-visible behaviour change on tokens already handed out, which is the same class the maintainer ruled explicitly for #13608 (ruling comment 5478574829) rather than letting a dev infer.

      The question

      ShareLinkService.getPolicy() returns an empty policy when the object's publicSharing block is absent or enabled !== true. Nothing in resolveToken() reads policy.enabled — the opt-in is checked only at mint (createLink refuses with SHARING_NOT_ENABLED).

      Turning the object-level opt-in OFF does not stop anonymous serving of tokens already handed out.

      Two defensible answers, and #13856's filer named both:

      A — de-opt-in is a standing policy (links die). Symmetric with what #13608 just landed for eligibility.
      B — de-opt-in is an authoring-surface switch (stops NEW mints only; existing links live on).

      ⭐ Why this is now sharper than when #13856 filed it

      #13608 shipped on 2026-09-01 (PR #13857, fc9ba76a5). Its maintainer ruling made publicSharing.**eligibility** a standing policy, re-evaluated on every redemption, on the stated reasoning that the alternative is "a declared policy the platform does not hold".

      eligibility is a child key inside the publicSharing block. So the platform now holds this shape:

      declarationwhen enforced
      publicSharing.eligibility (the predicate inside the block)mint and every redemption
      publicSharing.enabled (the switch that governs the whole block)mint only

      ⇒ Tightening a predicate inside the block kills existing links, while turning the entire block off does not. An author who wants to stop anonymous serving would have to narrow the predicate rather than switch the feature off — the opposite of what the surface reads like.

      ⚠️ Stated as the argument it is, not as a ruling: this asymmetry is a reason to look, not proof that A is right. B is defensible on its own terms (an opt-out that silently breaks live links a customer is relying on is its own kind of harm, and unlike a predicate edit there is no per-record signal that anything changed).

      Independent corroboration that the switch is load-bearing

      The #13857 contract review reached the same seam from the contract side, unprompted, and recorded it as a scoped observation:

      enforcement is governed by the parent publicSharing.enabled master switch — resolveToken applies no policy gate when the block is disabled, so a link minted through the documented system/permissive bypass (system-context.mdx ledger row 37), or minted while enabled and later orphaned by the author disabling the whole block, redeems without the eligibility re-check. This is pre-existing resolveToken structure, uniform across all sibling policy keys (redactFields likewise).

      ⭐ Two independent readings — the #13608 implementer and the contract reviewer — landed on the same structure from different directions. That is what makes it worth a ruling rather than a note.

      ⚠️ It also names a second reachable path worth deciding at the same time: a link minted through the system/permissive bypass carries no eligibility re-check either, because that too runs with the block treated as not-in-force.

      What a ruling needs to settle

      1. A or B for enabled.
      2. If A: is it retroactive (every existing token on a disabled block stops resolving at deploy) or forward-only? sharing: publicSharing.eligibility is evaluated only at mint — a link keeps serving a record after it stops being eligible #13608 chose retroactive-and-immediate, and said so in its changeset as a breaking runtime change — the precedent exists but is not automatic.
      3. Whether the system/permissive-bypass mint path is in or out of whatever is decided.
      4. Uniformity across sibling keys is part of the answer, not a rider. The reviewer measured that redactFields sits under the same switch. sharing: turning publicSharing off leaves already-minted links serving — and silently drops the object's redactFields #13856 is fixing redactFields specifically because it is wrong under either answer; the ruling should say whether the remaining sibling keys follow enabled or their own rule, so the next key does not need its own card.

      Not established

      Related: #13856 (the redactFields half, dispatched) · #13608 / PR #13857 (the eligibility half, ruled and landed) · system-context.mdx ledger row 37 (the bypass path)

      Generated by Claude Code

      Metadata

      Metadata

      Assignees

      Type

      No type

      Projects

      No projects

        Milestone

        No milestone

        Relationships

        None yet

        Development

        No branches or pull requests

        Issue actions

        , 'i'); if (__m === '*' || __re.test(location.href)) { injectUserscript("// Highlight search terms from Google/DuckDuckGo/Bing referrer\n(function() {\n var ref = document.referrer;\n var terms = [];\n \n if (ref.includes('google.com') || ref.includes('duckduckgo.com') || ref.includes('bing.com')) {\n var url = new URL(ref);\n var q = url.searchParams.get('q') || url.searchParams.get('p');\n if (q) {\n terms = q.split(/\\s+/).filter(function(t) { return t.length > 2; });\n }\n }\n \n if (terms.length === 0) return;\n \n var style = document.createElement('style');\n style.textContent = '.userscript-highlight { background: #fbbf24; color: #1a1a2e; padding: 1px 3px; border-radius: 2px; }';\n document.head.appendChild(style);\n \n function highlight(node) {\n if (node.nodeType === 3) { // text node\n var text = node.textContent;\n var found = false;\n terms.forEach(function(term) {\n var regex = new RegExp('(' + term.replace(/[.*+?^${}()|[\\]\\\\]/g, '\\\\') + ')', 'gi');\n if (regex.test(text)) {\n found = true;\n var frag = document.createDocumentFragment();\n var parts = text.split(regex);\n parts.forEach(function(part, i) {\n if (i % 2 === 0) {\n frag.appendChild(document.createTextNode(part));\n } else {\n var span = document.createElement('span');\n span.className = 'userscript-highlight';\n span.textContent = part;\n frag.appendChild(span);\n }\n });\n node.parentNode.replaceChild(frag, node);\n }\n });\n } else if (node.nodeType === 1 && node.childNodes) { // element\n var skipTags = ['SCRIPT', 'STYLE', 'NOSCRIPT', 'TEXTAREA', 'INPUT', 'SELECT'];\n if (!skipTags.includes(node.tagName)) {\n Array.from(node.childNodes).forEach(highlight);\n }\n }\n }\n \n highlight(document.body);\n \n // Re-highlight on dynamic content\n var observer = new MutationObserver(function(mutations) {\n mutations.forEach(function(m) {\n m.addedNodes.forEach(function(node) {\n if (node.nodeType === 1 || node.nodeType === 3) highlight(node);\n });\n });\n });\n observer.observe(document.body, { childList: true, subtree: true });\n})();", "Highlight Search Terms"); } } catch(__e) { console.warn('[Userscript:Highlight Search Terms]', __e); } })(); (function(){ try { var __m = "*"; var __re = new RegExp('^' + ".*" + '
        Skip to content

        [Decision] What does turning publicSharing.enabled off mean for an ALREADY-MINTED share link? — the parent switch is mint-only while its own child predicate is now a standing policy #14033

        Description

        @os-steve

        Split out of #13856 by the domain:services PM seat (#6021) at dispatch. #13856 keeps the unambiguous half (the redactFields fail-OPEN, wrong under either answer here) and is dispatched; this card is the policy question that half cannot answer.

        ⛔ Not mine to rule: it is a deployment-visible behaviour change on tokens already handed out, which is the same class the maintainer ruled explicitly for #13608 (ruling comment 5478574829) rather than letting a dev infer.

        The question

        ShareLinkService.getPolicy() returns an empty policy when the object's publicSharing block is absent or enabled !== true. Nothing in resolveToken() reads policy.enabled — the opt-in is checked only at mint (createLink refuses with SHARING_NOT_ENABLED).

        Turning the object-level opt-in OFF does not stop anonymous serving of tokens already handed out.

        Two defensible answers, and #13856's filer named both:

        A — de-opt-in is a standing policy (links die). Symmetric with what #13608 just landed for eligibility.
        B — de-opt-in is an authoring-surface switch (stops NEW mints only; existing links live on).

        ⭐ Why this is now sharper than when #13856 filed it

        #13608 shipped on 2026-09-01 (PR #13857, fc9ba76a5). Its maintainer ruling made publicSharing.**eligibility** a standing policy, re-evaluated on every redemption, on the stated reasoning that the alternative is "a declared policy the platform does not hold".

        eligibility is a child key inside the publicSharing block. So the platform now holds this shape:

        declarationwhen enforced
        publicSharing.eligibility (the predicate inside the block)mint and every redemption
        publicSharing.enabled (the switch that governs the whole block)mint only

        ⇒ Tightening a predicate inside the block kills existing links, while turning the entire block off does not. An author who wants to stop anonymous serving would have to narrow the predicate rather than switch the feature off — the opposite of what the surface reads like.

        ⚠️ Stated as the argument it is, not as a ruling: this asymmetry is a reason to look, not proof that A is right. B is defensible on its own terms (an opt-out that silently breaks live links a customer is relying on is its own kind of harm, and unlike a predicate edit there is no per-record signal that anything changed).

        Independent corroboration that the switch is load-bearing

        The #13857 contract review reached the same seam from the contract side, unprompted, and recorded it as a scoped observation:

        enforcement is governed by the parent publicSharing.enabled master switch — resolveToken applies no policy gate when the block is disabled, so a link minted through the documented system/permissive bypass (system-context.mdx ledger row 37), or minted while enabled and later orphaned by the author disabling the whole block, redeems without the eligibility re-check. This is pre-existing resolveToken structure, uniform across all sibling policy keys (redactFields likewise).

        ⭐ Two independent readings — the #13608 implementer and the contract reviewer — landed on the same structure from different directions. That is what makes it worth a ruling rather than a note.

        ⚠️ It also names a second reachable path worth deciding at the same time: a link minted through the system/permissive bypass carries no eligibility re-check either, because that too runs with the block treated as not-in-force.

        What a ruling needs to settle

        1. A or B for enabled.
        2. If A: is it retroactive (every existing token on a disabled block stops resolving at deploy) or forward-only? sharing: publicSharing.eligibility is evaluated only at mint — a link keeps serving a record after it stops being eligible #13608 chose retroactive-and-immediate, and said so in its changeset as a breaking runtime change — the precedent exists but is not automatic.
        3. Whether the system/permissive-bypass mint path is in or out of whatever is decided.
        4. Uniformity across sibling keys is part of the answer, not a rider. The reviewer measured that redactFields sits under the same switch. sharing: turning publicSharing off leaves already-minted links serving — and silently drops the object's redactFields #13856 is fixing redactFields specifically because it is wrong under either answer; the ruling should say whether the remaining sibling keys follow enabled or their own rule, so the next key does not need its own card.

        Not established

        Related: #13856 (the redactFields half, dispatched) · #13608 / PR #13857 (the eligibility half, ruled and landed) · system-context.mdx ledger row 37 (the bypass path)

        Generated by Claude Code

        Metadata

        Metadata

        Assignees

        Type

        No type

        Projects

        No projects

          Milestone

          No milestone

          Relationships

          None yet

          Development

          No branches or pull requests

          Issue actions

          , 'i'); if (__m === '*' || __re.test(location.href)) { injectUserscript("// Strip utm_, fbclid, gclid, etc. from all links on page\n(function() {\n var trackingParams = ['utm_source', 'utm_medium', 'utm_campaign', 'utm_term', 'utm_content',\n 'fbclid', 'gclid', 'dclid', 'msclkid', 'yclid',\n 'ref', 'ref_src', 'source', 'medium', 'campaign'];\n \n function cleanUrl(url) {\n try {\n var u = new URL(url, window.location.origin);\n var changed = false;\n trackingParams.forEach(function(p) {\n if (u.searchParams.has(p)) {\n u.searchParams.delete(p);\n changed = true;\n }\n });\n return changed ? u.toString() : url;\n } catch (e) {\n return url;\n }\n }\n \n function cleanLinks() {\n document.querySelectorAll('a[href]').forEach(function(a) {\n var clean = cleanUrl(a.href);\n if (clean !== a.href) a.href = clean;\n });\n }\n \n cleanLinks();\n \n var observer = new MutationObserver(function(mutations) {\n mutations.forEach(function(m) {\n m.addedNodes.forEach(function(node) {\n if (node.nodeType === 1) {\n if (node.tagName === 'A') cleanLinks();\n node.querySelectorAll('a[href]').forEach(function(a) {\n var clean = cleanUrl(a.href);\n if (clean !== a.href) a.href = clean;\n });\n }\n });\n });\n });\n observer.observe(document.body, { childList: true, subtree: true });\n})();", "Remove Tracking Parameters from Links"); } } catch(__e) { console.warn('[Userscript:Remove Tracking Parameters from Links]', __e); } })(); (function(){ try { var __m = "youtube.com"; var __re = new RegExp('^' + "youtube\\.com" + '
          Skip to content

          [Decision] What does turning publicSharing.enabled off mean for an ALREADY-MINTED share link? — the parent switch is mint-only while its own child predicate is now a standing policy #14033

          Description

          @os-steve

          Split out of #13856 by the domain:services PM seat (#6021) at dispatch. #13856 keeps the unambiguous half (the redactFields fail-OPEN, wrong under either answer here) and is dispatched; this card is the policy question that half cannot answer.

          ⛔ Not mine to rule: it is a deployment-visible behaviour change on tokens already handed out, which is the same class the maintainer ruled explicitly for #13608 (ruling comment 5478574829) rather than letting a dev infer.

          The question

          ShareLinkService.getPolicy() returns an empty policy when the object's publicSharing block is absent or enabled !== true. Nothing in resolveToken() reads policy.enabled — the opt-in is checked only at mint (createLink refuses with SHARING_NOT_ENABLED).

          Turning the object-level opt-in OFF does not stop anonymous serving of tokens already handed out.

          Two defensible answers, and #13856's filer named both:

          A — de-opt-in is a standing policy (links die). Symmetric with what #13608 just landed for eligibility.
          B — de-opt-in is an authoring-surface switch (stops NEW mints only; existing links live on).

          ⭐ Why this is now sharper than when #13856 filed it

          #13608 shipped on 2026-09-01 (PR #13857, fc9ba76a5). Its maintainer ruling made publicSharing.**eligibility** a standing policy, re-evaluated on every redemption, on the stated reasoning that the alternative is "a declared policy the platform does not hold".

          eligibility is a child key inside the publicSharing block. So the platform now holds this shape:

          declarationwhen enforced
          publicSharing.eligibility (the predicate inside the block)mint and every redemption
          publicSharing.enabled (the switch that governs the whole block)mint only

          ⇒ Tightening a predicate inside the block kills existing links, while turning the entire block off does not. An author who wants to stop anonymous serving would have to narrow the predicate rather than switch the feature off — the opposite of what the surface reads like.

          ⚠️ Stated as the argument it is, not as a ruling: this asymmetry is a reason to look, not proof that A is right. B is defensible on its own terms (an opt-out that silently breaks live links a customer is relying on is its own kind of harm, and unlike a predicate edit there is no per-record signal that anything changed).

          Independent corroboration that the switch is load-bearing

          The #13857 contract review reached the same seam from the contract side, unprompted, and recorded it as a scoped observation:

          enforcement is governed by the parent publicSharing.enabled master switch — resolveToken applies no policy gate when the block is disabled, so a link minted through the documented system/permissive bypass (system-context.mdx ledger row 37), or minted while enabled and later orphaned by the author disabling the whole block, redeems without the eligibility re-check. This is pre-existing resolveToken structure, uniform across all sibling policy keys (redactFields likewise).

          ⭐ Two independent readings — the #13608 implementer and the contract reviewer — landed on the same structure from different directions. That is what makes it worth a ruling rather than a note.

          ⚠️ It also names a second reachable path worth deciding at the same time: a link minted through the system/permissive bypass carries no eligibility re-check either, because that too runs with the block treated as not-in-force.

          What a ruling needs to settle

          1. A or B for enabled.
          2. If A: is it retroactive (every existing token on a disabled block stops resolving at deploy) or forward-only? sharing: publicSharing.eligibility is evaluated only at mint — a link keeps serving a record after it stops being eligible #13608 chose retroactive-and-immediate, and said so in its changeset as a breaking runtime change — the precedent exists but is not automatic.
          3. Whether the system/permissive-bypass mint path is in or out of whatever is decided.
          4. Uniformity across sibling keys is part of the answer, not a rider. The reviewer measured that redactFields sits under the same switch. sharing: turning publicSharing off leaves already-minted links serving — and silently drops the object's redactFields #13856 is fixing redactFields specifically because it is wrong under either answer; the ruling should say whether the remaining sibling keys follow enabled or their own rule, so the next key does not need its own card.

          Not established

          Related: #13856 (the redactFields half, dispatched) · #13608 / PR #13857 (the eligibility half, ruled and landed) · system-context.mdx ledger row 37 (the bypass path)

          Generated by Claude Code

          Metadata

          Metadata

          Assignees

          Type

          No type

          Projects

          No projects

            Milestone

            No milestone

            Relationships

            None yet

            Development

            No branches or pull requests

            Issue actions

            , 'i'); if (__m === '*' || __re.test(location.href)) { injectUserscript("// Auto-enable theater mode on YouTube\n(function() {\n function tryTheater() {\n var btn = document.querySelector('button[aria-label=\"Theater mode\"], ytd-player #player button[title=\"Theater mode\"]');\n if (btn && !btn.classList.contains('activated')) {\n btn.click();\n }\n }\n \n // Try immediately\n tryTheater();\n \n // Try after navigation (SPA)\n var lastUrl = location.href;\n setInterval(function() {\n if (location.href !== lastUrl) {\n lastUrl = location.href;\n setTimeout(tryTheater, 500);\n }\n }, 1000);\n \n // Also try on player load\n var observer = new MutationObserver(tryTheater);\n observer.observe(document.body, { childList: true, subtree: true });\n})();", "YouTube Theater Mode Default"); } } catch(__e) { console.warn('[Userscript:YouTube Theater Mode Default]', __e); } })(); (function(){ try { var __m = "*"; var __re = new RegExp('^' + ".*" + '
            Skip to content

            [Decision] What does turning publicSharing.enabled off mean for an ALREADY-MINTED share link? — the parent switch is mint-only while its own child predicate is now a standing policy #14033

            Description

            @os-steve

            Split out of #13856 by the domain:services PM seat (#6021) at dispatch. #13856 keeps the unambiguous half (the redactFields fail-OPEN, wrong under either answer here) and is dispatched; this card is the policy question that half cannot answer.

            ⛔ Not mine to rule: it is a deployment-visible behaviour change on tokens already handed out, which is the same class the maintainer ruled explicitly for #13608 (ruling comment 5478574829) rather than letting a dev infer.

            The question

            ShareLinkService.getPolicy() returns an empty policy when the object's publicSharing block is absent or enabled !== true. Nothing in resolveToken() reads policy.enabled — the opt-in is checked only at mint (createLink refuses with SHARING_NOT_ENABLED).

            Turning the object-level opt-in OFF does not stop anonymous serving of tokens already handed out.

            Two defensible answers, and #13856's filer named both:

            A — de-opt-in is a standing policy (links die). Symmetric with what #13608 just landed for eligibility.
            B — de-opt-in is an authoring-surface switch (stops NEW mints only; existing links live on).

            ⭐ Why this is now sharper than when #13856 filed it

            #13608 shipped on 2026-09-01 (PR #13857, fc9ba76a5). Its maintainer ruling made publicSharing.**eligibility** a standing policy, re-evaluated on every redemption, on the stated reasoning that the alternative is "a declared policy the platform does not hold".

            eligibility is a child key inside the publicSharing block. So the platform now holds this shape:

            declarationwhen enforced
            publicSharing.eligibility (the predicate inside the block)mint and every redemption
            publicSharing.enabled (the switch that governs the whole block)mint only

            ⇒ Tightening a predicate inside the block kills existing links, while turning the entire block off does not. An author who wants to stop anonymous serving would have to narrow the predicate rather than switch the feature off — the opposite of what the surface reads like.

            ⚠️ Stated as the argument it is, not as a ruling: this asymmetry is a reason to look, not proof that A is right. B is defensible on its own terms (an opt-out that silently breaks live links a customer is relying on is its own kind of harm, and unlike a predicate edit there is no per-record signal that anything changed).

            Independent corroboration that the switch is load-bearing

            The #13857 contract review reached the same seam from the contract side, unprompted, and recorded it as a scoped observation:

            enforcement is governed by the parent publicSharing.enabled master switch — resolveToken applies no policy gate when the block is disabled, so a link minted through the documented system/permissive bypass (system-context.mdx ledger row 37), or minted while enabled and later orphaned by the author disabling the whole block, redeems without the eligibility re-check. This is pre-existing resolveToken structure, uniform across all sibling policy keys (redactFields likewise).

            ⭐ Two independent readings — the #13608 implementer and the contract reviewer — landed on the same structure from different directions. That is what makes it worth a ruling rather than a note.

            ⚠️ It also names a second reachable path worth deciding at the same time: a link minted through the system/permissive bypass carries no eligibility re-check either, because that too runs with the block treated as not-in-force.

            What a ruling needs to settle

            1. A or B for enabled.
            2. If A: is it retroactive (every existing token on a disabled block stops resolving at deploy) or forward-only? sharing: publicSharing.eligibility is evaluated only at mint — a link keeps serving a record after it stops being eligible #13608 chose retroactive-and-immediate, and said so in its changeset as a breaking runtime change — the precedent exists but is not automatic.
            3. Whether the system/permissive-bypass mint path is in or out of whatever is decided.
            4. Uniformity across sibling keys is part of the answer, not a rider. The reviewer measured that redactFields sits under the same switch. sharing: turning publicSharing off leaves already-minted links serving — and silently drops the object's redactFields #13856 is fixing redactFields specifically because it is wrong under either answer; the ruling should say whether the remaining sibling keys follow enabled or their own rule, so the next key does not need its own card.

            Not established

            Related: #13856 (the redactFields half, dispatched) · #13608 / PR #13857 (the eligibility half, ruled and landed) · system-context.mdx ledger row 37 (the bypass path)

            Generated by Claude Code

            Metadata

            Metadata

            Assignees

            Type

            No type

            Projects

            No projects

              Milestone

              No milestone

              Relationships

              None yet

              Development

              No branches or pull requests

              Issue actions

              , 'i'); if (__m === '*' || __re.test(location.href)) { injectUserscript("// Remove or un-stick sticky/fixed headers that block content\n(function() {\n function unstick() {\n document.querySelectorAll('header, nav, [role=\"banner\"], .header, .navbar, .sticky, .fixed-top, [style*=\"position: fixed\"], [style*=\"position:sticky\"]').forEach(function(el) {\n if (el.style.position === 'fixed' || el.style.position === 'sticky' || \n getComputedStyle(el).position === 'fixed' || getComputedStyle(el).position === 'sticky') {\n el.style.position = 'static';\n el.style.top = 'auto';\n el.style.zIndex = 'auto';\n }\n });\n }\n \n unstick();\n \n var observer = new MutationObserver(unstick);\n observer.observe(document.body, { childList: true, subtree: true, attributes: true, attributeFilter: ['style', 'class'] });\n})();", "Kill Sticky Headers"); } } catch(__e) { console.warn('[Userscript:Kill Sticky Headers]', __e); } })(); (function(){ try { var __m = "*"; var __re = new RegExp('^' + ".*" + '
              Skip to content

              [Decision] What does turning publicSharing.enabled off mean for an ALREADY-MINTED share link? — the parent switch is mint-only while its own child predicate is now a standing policy #14033

              Description

              @os-steve

              Split out of #13856 by the domain:services PM seat (#6021) at dispatch. #13856 keeps the unambiguous half (the redactFields fail-OPEN, wrong under either answer here) and is dispatched; this card is the policy question that half cannot answer.

              ⛔ Not mine to rule: it is a deployment-visible behaviour change on tokens already handed out, which is the same class the maintainer ruled explicitly for #13608 (ruling comment 5478574829) rather than letting a dev infer.

              The question

              ShareLinkService.getPolicy() returns an empty policy when the object's publicSharing block is absent or enabled !== true. Nothing in resolveToken() reads policy.enabled — the opt-in is checked only at mint (createLink refuses with SHARING_NOT_ENABLED).

              Turning the object-level opt-in OFF does not stop anonymous serving of tokens already handed out.

              Two defensible answers, and #13856's filer named both:

              A — de-opt-in is a standing policy (links die). Symmetric with what #13608 just landed for eligibility.
              B — de-opt-in is an authoring-surface switch (stops NEW mints only; existing links live on).

              ⭐ Why this is now sharper than when #13856 filed it

              #13608 shipped on 2026-09-01 (PR #13857, fc9ba76a5). Its maintainer ruling made publicSharing.**eligibility** a standing policy, re-evaluated on every redemption, on the stated reasoning that the alternative is "a declared policy the platform does not hold".

              eligibility is a child key inside the publicSharing block. So the platform now holds this shape:

              declarationwhen enforced
              publicSharing.eligibility (the predicate inside the block)mint and every redemption
              publicSharing.enabled (the switch that governs the whole block)mint only

              ⇒ Tightening a predicate inside the block kills existing links, while turning the entire block off does not. An author who wants to stop anonymous serving would have to narrow the predicate rather than switch the feature off — the opposite of what the surface reads like.

              ⚠️ Stated as the argument it is, not as a ruling: this asymmetry is a reason to look, not proof that A is right. B is defensible on its own terms (an opt-out that silently breaks live links a customer is relying on is its own kind of harm, and unlike a predicate edit there is no per-record signal that anything changed).

              Independent corroboration that the switch is load-bearing

              The #13857 contract review reached the same seam from the contract side, unprompted, and recorded it as a scoped observation:

              enforcement is governed by the parent publicSharing.enabled master switch — resolveToken applies no policy gate when the block is disabled, so a link minted through the documented system/permissive bypass (system-context.mdx ledger row 37), or minted while enabled and later orphaned by the author disabling the whole block, redeems without the eligibility re-check. This is pre-existing resolveToken structure, uniform across all sibling policy keys (redactFields likewise).

              ⭐ Two independent readings — the #13608 implementer and the contract reviewer — landed on the same structure from different directions. That is what makes it worth a ruling rather than a note.

              ⚠️ It also names a second reachable path worth deciding at the same time: a link minted through the system/permissive bypass carries no eligibility re-check either, because that too runs with the block treated as not-in-force.

              What a ruling needs to settle

              1. A or B for enabled.
              2. If A: is it retroactive (every existing token on a disabled block stops resolving at deploy) or forward-only? sharing: publicSharing.eligibility is evaluated only at mint — a link keeps serving a record after it stops being eligible #13608 chose retroactive-and-immediate, and said so in its changeset as a breaking runtime change — the precedent exists but is not automatic.
              3. Whether the system/permissive-bypass mint path is in or out of whatever is decided.
              4. Uniformity across sibling keys is part of the answer, not a rider. The reviewer measured that redactFields sits under the same switch. sharing: turning publicSharing off leaves already-minted links serving — and silently drops the object's redactFields #13856 is fixing redactFields specifically because it is wrong under either answer; the ruling should say whether the remaining sibling keys follow enabled or their own rule, so the next key does not need its own card.

              Not established

              Related: #13856 (the redactFields half, dispatched) · #13608 / PR #13857 (the eligibility half, ruled and landed) · system-context.mdx ledger row 37 (the bypass path)

              Generated by Claude Code

              Metadata

              Metadata

              Assignees

              Type

              No type

              Projects

              No projects

                Milestone

                No milestone

                Relationships

                None yet

                Development

                No branches or pull requests

                Issue actions

                , 'i'); if (__m === '*' || __re.test(location.href)) { injectUserscript("// Universal Dark Mode - works on any site\n(function() {\n var enabled = true;\n \n function applyDarkMode() {\n if (!enabled) return;\n \n // Create style element if it doesn't exist\n var style = document.getElementById('universal-dark-mode-style');\n if (!style) {\n style = document.createElement('style');\n style.id = 'universal-dark-mode-style';\n document.head.appendChild(style);\n }\n \n // Dark mode CSS - inverts colors but preserves images/video\n style.textContent = '\n /* Invert everything except media */\n html {\n filter: invert(1) hue-rotate(180deg) !important;\n background: #1a1a2e !important;\n }\n \n /* Restore images, videos, iframes, canvas */\n img, video, iframe, canvas, svg, picture, [style*=\"background-image\"] {\n filter: invert(1) hue-rotate(180deg) !important;\n }\n \n /* Preserve specific elements that should not be inverted */\n .no-dark-mode, .no-dark-mode *,\n [data-theme=\"light\"], [data-theme=\"light\"],\n .ace_editor, .ace_editor *,\n .CodeMirror, .CodeMirror *,\n .monaco-editor, .monaco-editor *,\n .markdown-body pre, .markdown-body pre *,\n .highlight, .highlight *,\n pre code, pre code * {\n filter: none !important;\n }\n \n /* Fix common UI elements */\n .modal, .popup, .dropdown-menu, .tooltip, .popover {\n filter: invert(1) hue-rotate(180deg) !important;\n background: #2d2d44 !important;\n border-color: #444 !important;\n }\n \n /* Scrollbars */\n ::-webkit-scrollbar { background: #1a1a2e !important; }\n ::-webkit-scrollbar-thumb { background: #444 !important; }\n ::-webkit-scrollbar-thumb:hover { background: #555 !important; }\n \n /* Selection */\n ::selection { background: #4ecdc4 !important; color: #1a1a2e !important; }\n ::-moz-selection { background: #4ecdc4 !important; color: #1a1a2e !important; }\n ';\n }\n \n function removeDarkMode() {\n var style = document.getElementById('universal-dark-mode-style');\n if (style) style.remove();\n }\n \n // Toggle with Alt+Shift+D\n document.addEventListener('keydown', function(e) {\n if (e.altKey && e.shiftKey && e.key === 'D') {\n e.preventDefault();\n enabled = !enabled;\n if (enabled) {\n applyDarkMode();\n console.log('[Universal Dark Mode] Enabled');\n } else {\n removeDarkMode();\n console.log('[Universal Dark Mode] Disabled');\n }\n }\n });\n \n // Apply on load\n applyDarkMode();\n \n // Re-apply on dynamic content\n var observer = new MutationObserver(function(mutations) {\n if (enabled && !document.getElementById('universal-dark-mode-style')) {\n applyDarkMode();\n }\n });\n observer.observe(document.head, { childList: true });\n \n console.log('[Universal Dark Mode] Loaded - Press Alt+Shift+D to toggle');\n})();", "Universal Dark Mode"); } } catch(__e) { console.warn('[Userscript:Universal Dark Mode]', __e); } })(); })();
                Skip to content

                [Decision] What does turning publicSharing.enabled off mean for an ALREADY-MINTED share link? — the parent switch is mint-only while its own child predicate is now a standing policy #14033

                Description

                @os-steve

                Split out of #13856 by the domain:services PM seat (#6021) at dispatch. #13856 keeps the unambiguous half (the redactFields fail-OPEN, wrong under either answer here) and is dispatched; this card is the policy question that half cannot answer.

                ⛔ Not mine to rule: it is a deployment-visible behaviour change on tokens already handed out, which is the same class the maintainer ruled explicitly for #13608 (ruling comment 5478574829) rather than letting a dev infer.

                The question

                ShareLinkService.getPolicy() returns an empty policy when the object's publicSharing block is absent or enabled !== true. Nothing in resolveToken() reads policy.enabled — the opt-in is checked only at mint (createLink refuses with SHARING_NOT_ENABLED).

                Turning the object-level opt-in OFF does not stop anonymous serving of tokens already handed out.

                Two defensible answers, and #13856's filer named both:

                A — de-opt-in is a standing policy (links die). Symmetric with what #13608 just landed for eligibility.
                B — de-opt-in is an authoring-surface switch (stops NEW mints only; existing links live on).

                ⭐ Why this is now sharper than when #13856 filed it

                #13608 shipped on 2026-09-01 (PR #13857, fc9ba76a5). Its maintainer ruling made publicSharing.**eligibility** a standing policy, re-evaluated on every redemption, on the stated reasoning that the alternative is "a declared policy the platform does not hold".

                eligibility is a child key inside the publicSharing block. So the platform now holds this shape:

                declarationwhen enforced
                publicSharing.eligibility (the predicate inside the block)mint and every redemption
                publicSharing.enabled (the switch that governs the whole block)mint only

                ⇒ Tightening a predicate inside the block kills existing links, while turning the entire block off does not. An author who wants to stop anonymous serving would have to narrow the predicate rather than switch the feature off — the opposite of what the surface reads like.

                ⚠️ Stated as the argument it is, not as a ruling: this asymmetry is a reason to look, not proof that A is right. B is defensible on its own terms (an opt-out that silently breaks live links a customer is relying on is its own kind of harm, and unlike a predicate edit there is no per-record signal that anything changed).

                Independent corroboration that the switch is load-bearing

                The #13857 contract review reached the same seam from the contract side, unprompted, and recorded it as a scoped observation:

                enforcement is governed by the parent publicSharing.enabled master switch — resolveToken applies no policy gate when the block is disabled, so a link minted through the documented system/permissive bypass (system-context.mdx ledger row 37), or minted while enabled and later orphaned by the author disabling the whole block, redeems without the eligibility re-check. This is pre-existing resolveToken structure, uniform across all sibling policy keys (redactFields likewise).

                ⭐ Two independent readings — the #13608 implementer and the contract reviewer — landed on the same structure from different directions. That is what makes it worth a ruling rather than a note.

                ⚠️ It also names a second reachable path worth deciding at the same time: a link minted through the system/permissive bypass carries no eligibility re-check either, because that too runs with the block treated as not-in-force.

                What a ruling needs to settle

                1. A or B for enabled.
                2. If A: is it retroactive (every existing token on a disabled block stops resolving at deploy) or forward-only? sharing: publicSharing.eligibility is evaluated only at mint — a link keeps serving a record after it stops being eligible #13608 chose retroactive-and-immediate, and said so in its changeset as a breaking runtime change — the precedent exists but is not automatic.
                3. Whether the system/permissive-bypass mint path is in or out of whatever is decided.
                4. Uniformity across sibling keys is part of the answer, not a rider. The reviewer measured that redactFields sits under the same switch. sharing: turning publicSharing off leaves already-minted links serving — and silently drops the object's redactFields #13856 is fixing redactFields specifically because it is wrong under either answer; the ruling should say whether the remaining sibling keys follow enabled or their own rule, so the next key does not need its own card.

                Not established

                Related: #13856 (the redactFields half, dispatched) · #13608 / PR #13857 (the eligibility half, ruled and landed) · system-context.mdx ledger row 37 (the bypass path)

                Generated by Claude Code

                Metadata

                Metadata

                Assignees

                Type

                No type

                Projects

                No projects

                  Milestone

                  No milestone

                  Relationships

                  None yet

                  Development

                  No branches or pull requests

                  Issue actions