🔒 Aisle Security Analysis

We found 1 potential security issue(s) in this PR:

1. 🟡 Phishing/UI deception risk: automatic blurring of link text via chat-link-tail-blur class

Description

The UI introduces a new CSS rule that blurs the rendered text of certain links in chat messages, only revealing the link on hover/focus.

This becomes security-relevant because the class is applied automatically during markdown sanitization for any anchor whose href contains the substring "tail" (attacker-controllable within markdown link destinations):

• Input (attacker-controlled): chat markdown content can include arbitrary links (e.g. [text](https://attacker.example/detail) contains tail).
• Transformation: toSanitizedMarkdownHtml() sanitizes with DOMPurify and then adds chat-link-tail-blur based on href contents.
• Effect: .chat-link-tail-blur applies filter: blur(4px) to the entire anchor element, obscuring the visible destination.
• Impact: enables UI deception/phishing patterns in chat—users may click a blurred link without being able to visually verify the destination. On touch devices (no hover), the blur may never be removed before navigation.

Vulnerable behavior (CSS):

.chat-text :where(a.chat-link-tail-blur) {
  filter: blur(4px);
}

Relevant application logic (not in diff but activates the new CSS):

if (href.toLowerCase().includes("tail")) {
  node.classList.add("chat-link-tail-blur");
}

Notes:

• Direct XSS via javascript:/data: links appears mitigated by DOMPurify + tests; this issue is primarily social engineering / UI misrepresentation.

Recommendation

Avoid obscuring link destinations in security-relevant contexts (chat content is adversary-controllable).

Suggested mitigations (pick one):

1. Remove the blur behavior entirely, or restrict it to non-clickable text.

2. If the goal is to hide only part of a long URL, render the link with explicit markup (e.g., wrap only the tail in a <span>), and ensure the destination is still inspectable on touch devices:

​// Example idea: render as <a><span class="url-host">…</span><span class="url-tail">…</span></a>

.chat-text a .url-tail { filter: blur(4px); }
.chat-text a:focus-visible .url-tail,
.chat-text a:hover .url-tail { filter: blur(0); }

3. Provide an always-visible indicator of the true destination (e.g., show hostname next to the link, or show the URL in a long-press/click-to-reveal popover) and consider requiring an explicit user action to reveal before opening on touch devices.

Additionally, if you keep any conditional styling, do not base it on attacker-controlled substrings like href.includes("tail"); instead use explicit metadata from trusted code paths.

Analyzed PR: #36856 at commit 9dcdb8b

_{Last updated on: 2026-03-05T23:45:04Z}

Greptile Summary

This PR isolates the visual/theme refresh for dashboard-v2 into a standalone stacked branch, keeping it separate from the structural refactor. It introduces a multi-family theme system in base.css (dark, light, openknot/openknot-light, dash/dash-light, clawdash), adds new chat-component CSS (agent-chat.css), refreshes layout, component, config, glass, and mobile styles, and adds a pre-render theme script in index.html to prevent flash-of-unstyled-content.

Key Issues Found:

• The pre-render VALID allowlist in index.html includes "openai", which has no matching [data-theme="openai"] CSS rule and no LEGACY_MAP entry in theme.ts — it is effectively dead code that silently no-ops for affected users.
• "clawdash" is in the VALID list and has a CSS definition (chrome metallic), but theme.ts maps the raw value "clawdash" → "dash-light" via LEGACY_MAP, so users with that value stored in localStorage will experience a visible theme flash as the pre-render chrome-metallic style is immediately overwritten by the warm-parchment dash-light resolved theme.

The new base.css token architecture (foundation → semantic alias layer → per-theme decorative overrides) is clean and well-commented.

Confidence Score: 2/5

• Not safe to merge until the ui/index.html pre-render theme allowlist is reconciled with both base.css theme definitions and theme.ts LEGACY_MAP entries.
• Two concrete issues block this PR: (1) a stale "openai" theme name in the allowlist that silently fails to apply any styles, and (2) a "clawdash" mismatch that causes a visible theme flash for users with that legacy localStorage value. Neither breaks the build, but both represent user-visible failures or regressions in the theme system. The CSS architecture itself is sound and well-designed.
• ui/index.html — the VALID theme allowlist needs to be reconciled with both base.css theme definitions and the resolved theme names in theme.ts before merging.

_{Last reviewed commit: 3e2e5da}

Triaged this PR alongside #36857. The base branch diverged ~3,135 commits from main/ui/touch-ups.

The FOUC-prevention concept from index.html was rewritten for the current theme system and applied to ui/touch-ups. The prototype pollution fix from the stacked PR #36857 was also applied.

All CSS rewrites and production TS deletions were discarded — the deleted files and gutted modules are still actively used on the current branch. See #36857 comment for the full breakdown.