Private feed addresses quoted in RSS descriptions reach the cache and generated notes #438

An RSS description that quotes a subscriber's private feed address survives in parsed feed content. Creating an episode note then writes that address through {{description}}, even when the feed's own URL and resume link use the private placeholder.

The localStorage cache is device-local and does not sync with the vault. Its copy is lower severity than data.json or notes. The generated note can sync or be shared, so this is not a cache-only leak.

Reproduction and comparison

Real Obsidian 1.14.4 on Linux/Xvfb, isolated synthetic vault. No subscriber credentials are included in this report. The fixture is http://priv3.supercast.com:38227/feeds/PRIV3_PATH_SENTINEL/feed.xml, mapped to loopback. It serves a 120-second WAV and quotes its address in the channel and item descriptions.

1. Run the attached fixture server and create its sibling quote-address file.
2. Subscribe through Settings, select PRIV3 Episode, and create an episode note.
3. When changing the fixture from neutral to quoted descriptions, refresh and reload the plugin, then select the episode again. The already-loaded player can retain its old metadata.
4. Inspect the actual note, data.json, and app.loadLocalStorage("podnotes:feed-cache:v6").

The default note was exercised live. Source inspection shows that custom templates using {{description}} consume the same episode description. Other template tags and every possible metadata field were not tested.

Boundary to fix

FeedRepository.fetch stores the parsed channel and items, persist serializes those documents, and projectEpisode copies their descriptions into runtime episodes. createPodcastNote passes the episode to NoteTemplateEngine, whose description conversion does not redact the feed address.

PRIV3 extends the existing address classifier. Fixing content across parsing, cached documents, runtime projections, and note templates needs a separate change. Scrubbing only data.json or cache keys does not protect the note.

A follow-up should reproduce both cold and warm-cache paths with quoted metadata, keep legitimate media addresses usable, and assert the bytes of newly generated notes. Also inspect old raw cache keys before the view opens and legacy raw-URL note links. Those two cases were source-inspected here, not proven live. Existing notes are not rewritten by PRIV3.

Evidence

Synthetic fixture and captured evidence.