Rule proposal: long-context-redact — collapse over-budget threads on long pages
维护者通常 3 天内回复
还没有人认领这个 Issue。
评估
- 难度
- 5/5
- 预计耗时
- 一周以上
- 新手友好度
- 35/100
- Issue 类型
- 功能
- 描述清晰度
- 基本清楚
- 活跃度
- 冷清
- 技术栈
- typescript
- 领域
- security
调研方向
Start with rules.md and compare the existing comments-redact, reviews-redact, cross-origin-frame-redact, and irrelevant-sections-redact rules referenced in the proposal. Determine the rule entry point, configuration and placeholder behavior from those implementations, then define tests for per-section limits, reveal-on-demand behavior, denylist exceptions, and structural significance markers.
由索引模型根据 Issue 内容生成。
描述
Category
New defense rule
What problem does this solve?
Even when a page is "clean" (no injection, no dark patterns), sheer length is a defense surface. Liu et al. (TACL 2023), Lost in the Middle: How Language Models Use Long Contexts, document a U-shaped accuracy curve: LLM retrieval and reasoning degrade sharply when relevant information sits in the middle of a long context window, even on models advertised as long-context.
A page with 200 comments or 80 reviews pushes the agent's task instructions and the page payload to the edges, where the agent both (a) misses the answer and (b) is more susceptible to mid-context injection that benefits from positional dilution. The existing comments-redact and reviews-redact rules remove these surfaces entirely. But when the comments are the task ("summarize the top criticism of this product"), removal is wrong — the agent needs the content, just not all 800 entries.
Proposed solution
On pages whose visible text exceeds a budget (proposed: 50k chars; tunable), collapse:
- Comment threads past the first N entries
- Review lists past the first N entries
- Reply chains past the first N levels of depth
into the same click-to-reveal placeholder shape cross-origin-frame-redact, comments-redact, and irrelevant-sections-redact already use. Agents that need the tail can reveal explicitly; default behavior preserves the head of the list (typically highest-quality on engagement-sorted platforms).
Alternatives considered
- Lower the cap in
comments-redact/reviews-redact. Doesn't help — those rules are all-or-nothing today; this proposal is the "keep the head" variant. - Reader-mode extraction (Readability.js). Already part of the prior-art lineage; Readability picks a main article and discards comments wholesale. We want the keep-some-comments shape.
- Generic LLM trim. Same shape as
irrelevant-sections-redact, but the trigger here is length, not engagement-rail recognition — no LLM call needed for a "keep first N" heuristic.
Controlling false positives
- Default-off. Until per-host hit/skip data confirms the head-N preserves task-relevant content, this rule should ship default-off — same posture as
irrelevant-sections-redact. Users opt in when their workflow tolerates the trade-off. - Per-host denylist. Sites where the tail is structurally load-bearing — Hacker News (highly-rated child comments outvalue top-level), GitHub issue threads (resolution often in the last reply), Reddit (
AskScience-style threads with cited replies), public-comment portals like regulations.gov, court records — never apply the rule. - Preserve elements with structural significance markers. Reddit "best answer" flags, Stack Overflow "Accepted" badges, GitHub "Marked as answer",
aria-label*="solved", and rows with engagement scores above a per-host percentile. The head-N count should not blindly drop a flagged answer because it sits at position 47. - High length threshold. 50k visible chars is roughly 12k tokens — well above the budget where Lost-in-the-Middle starts to bite for current frontier models. Tuning low risks redacting pages that fit comfortably in context.
- Reveal-on-demand contract. Collapsed regions become click-to-reveal placeholders, not deletions. An agent that detects the placeholder shape can decide to expand — same affordance as
cross-origin-frame-redact. - Per-section quotas, not page-wide. Apply N independently to each thread/list so a page with multiple distinct conversation surfaces (an article with comments + a sidebar of reviews) doesn't lose representation in one to keep room for the other.
- Skip when the page is the agent's task surface. If the user's task implies "summarize all reviews", the agent can't tell us — but a per-host denylist for the platforms where this is the common ask (review-aggregator sites like Trustpilot, Amazon SERP review pages once the user navigates to "see all reviews") gets most of the way there.
Prior art / references
- Liu et al. (TACL 2023). Lost in the Middle. https://arxiv.org/abs/2307.03172 — foundational motivation. Code/data: https://github.com/nelson-liu/lost-in-the-middle.
- Mozilla Readability.js (Apache 2.0) — boilerplate prior art already cited in
rules.md. - Kohlschütter et al. (WSDM 2010) — same lineage.
Tagged Impact M / Complexity H.
- 主要语言
- TypeScript
- 星标
- 34
- 派生
- 3
- 平均合并
- 3 天 3 小时
- 30 天内合并 PR
- 35
环境准备
- 没有 Dockerfile 或 Docker Compose 文件
- 有 Pull Request 模板
- 阅读贡献指南
从这里开始
- 先读完整个 Issue,再读项目的贡献指南。
- 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
- Fork 仓库,在一个分支上完成修改。
- 提交 Pull Request,并在描述里引用这个 Issue 编号。
pixiebrix/agent-browser-shield 的其他 Issue
-
enhancement question
难度 5/5 一周以上 新手友好度 30/100
pixiebrix/agent-browser-shield#178 ·
维护者通常 3 天内回复
-
enhancement rule-proposal
难度 5/5 一周以上 新手友好度 28/100
pixiebrix/agent-browser-shield#123 · 1 条评论 ·
维护者通常 3 天内回复
-
enhancement rule-proposal
难度 5/5 一周以上 新手友好度 25/100
pixiebrix/agent-browser-shield#122 ·
维护者通常 3 天内回复
-
enhancement rule-proposal
难度 5/5 一周以上 新手友好度 38/100
pixiebrix/agent-browser-shield#121 · 1 条评论 ·
维护者通常 3 天内回复
查看 pixiebrix/agent-browser-shield 的全部 Issue
相似的 Issue
-
难度 2/5 1-3 小时 新手友好度 78/100
维护者通常 1 天内回复
-
难度 1/5 1 小时以内 新手友好度 82/100
homarr-labs/dashboard-icons#2939 ·
维护者通常 1 天内回复
-
Agent/category reasoning variants are still checked against the stale model cache in chat.params未关闭opencode
难度 2/5 1-3 小时 新手友好度 75/100
code-yeongyu/oh-my-openagent#10003 ·
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 77/100
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 65/100
nextcloud-libraries/nextcloud-dialogs#2669 ·
维护者通常 1 天内回复