Skip to content

Embedded .svg parts are excluded from scanning because path geometry floods PHONE; an SVG-aware text extractor would recover the real content #314

Description

@sectoramen

An .svg embedded in an Office document is currently not scanned, and that is a deliberate deferral made in #311 rather than an oversight. This issue records what was measured and what the real fix is.

Why they are excluded today

#311 changed embedded-part admission from a hand-maintained extension table to "whatever the pipeline can process". .svg is XML text, so the byte-sniffing text path claims it happily — and its content is drawing geometry.

Measured on one real deck carrying 171 embedded .svg parts:

PHONE findings
before 0
routing .svg through the validators 1,095 — of which 826 HIGH

The matches are path data:

43.5968 15.4721 43.4928 15.7281 43.3048 15.9
38.9358 20.3361 37.5138 18.9301 40.1318 16.2
4.1078 15.7661 3.9998 15.5101 3.9998 15.2421

826 HIGH false positives in a single file is not coverage. HIGH is the band operators triage first, so this buries the findings that matter — exactly what the confidence contract exists to prevent. embedded.SkipTextPipeline therefore excludes .svg, .emf, .wmf and .wdp on both the read and write sides.

Why it is worth fixing

The detection value is real, not hypothetical. An SVG's <text>, <title> and <desc> nodes are ordinary prose — diagram labels, callouts, annotations — and they are exactly where a name, email or ID ends up in an architecture diagram. Verified with a standalone fixture:

<svg ...><text x="5" y="20">Employee SSN: 452-11-9384</text></svg>

scans to 1 SSN finding at confidence 90.

And the volume is significant: across 334 real Office files, .svg accounted for 411 of 2,520 embedded parts — the second most common embedded type after .png.

Proposed fix

An SVG-aware extractor that reads text-bearing nodes and ignores everything else:

  • extract the character data of <text>, <tspan>, <title>, <desc>, and <metadata>
  • ignore d, points, transform, viewBox and every other geometry attribute
  • ignore <path>, <polygon>, <polyline> element content entirely

That inverts the current problem: instead of scanning coordinates and hoping validators reject them, only prose reaches the validators.

Acceptance criteria

Corpus figures are aggregate counts only; every value shown is from a synthetic fixture.

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementNew feature or request

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions