SVG SMIL Animation as a Consent Timing Attack

Why SMIL is harder to audit than JavaScript animation

The dominant mental model for SVG filter consent attacks assumes that manipulation requires JavaScript. An auditor scans for addEventListener, looks for style.opacity assignments, checks for element.setAttribute('flood-color', …) calls in script. When none appear, the consent form is flagged as clean.

SVG SMIL animation breaks this assumption at the specification level. The SVG 1.1 animation model — carried forward into SVG 2.0 via the Web Animations API integration — allows any SVG presentation attribute to be animated declaratively inside the SVG document itself. No JavaScript. No event handlers registered with addEventListener. The animation is entirely specified in markup.

The second asymmetry is the initial-value trap. When an auditor calls el.getAttribute('flood-color') or reads feFloodElement.floodColor at parse time, the value returned is the initial pre-animation value — which is by design a safe value. The attack state only exists after the animation's begin trigger fires. To detect a SMIL timing attack, an auditor must enumerate the animate and set child elements within the filter, read their begin attribute for interaction references, and evaluate the to value as the effective attribute value during the consent interaction window.

The SMIL animation model: a brief primer

Four SVG animation elements are relevant to consent attack surfaces: <animate>, <set>, <animateTransform>, and <animateMotion>. All four share a timing model built on three concepts:

The interaction event reference syntax is elementId.eventName inside the begin attribute. Any element on the page can be referenced by ID, not just elements in the same subtree as the filter or consent text. A submit button in the consent form, referenced by its ID, can trigger a filter animation on any element anywhere in the document.

Attack pattern 1 (SA-SMIL-001): feFlood flood-color animation

<filter id="consent-filter">
  <feFlood flood-color="transparent" flood-opacity="0" result="cover">
    <animate attributeName="flood-color" to="white"
             begin="submitBtn.click" dur="0.1s" fill="freeze"/>
    <animate attributeName="flood-opacity" to="1"
             begin="submitBtn.click" dur="0.1s" fill="freeze"/>
  </feFlood>
  <feComposite in="cover" in2="SourceGraphic" operator="over" result="out"/>
</filter>

The fill="freeze" attribute is the critical detail. Without it, the filter would revert to transparent after 0.1 seconds. With it, the attack state is permanent: every subsequent render of the consent text element produces a white rectangle until the page is reloaded.

Attack pattern 2 (SA-SMIL-002): feFuncA slope animation

<filter id="consent-alpha-filter">
  <feComponentTransfer>
    <feFuncA type="linear" slope="1" intercept="0">
      <set attributeName="slope" to="0"
           begin="consentForm.mouseenter" fill="freeze"/>
    </feFuncA>
  </feComponentTransfer>
</filter>

The feFuncA slope attack is particularly evasive because:

1. The initial slope=1 is correct. getComputedStyle analysis, attribute inspection, and filter graph analysis all find a safe pass-through transfer function.
2. The attack fires on mouseenter — the most natural preamble to a form interaction — before any click event occurs.
3. The feFuncA element is nested two levels deep (filter → feComponentTransfer → feFuncA) making recursive descent more complex.
4. The set element has no duration attribute — it activates instantaneously — making animation-duration analysis ineffective.

Attack pattern 3 (SA-SMIL-003): animateTransform on filter region

<filter id="offscreen-filter" x="-200%" y="-200%" width="100%" height="100%">
  <feFlood flood-color="white" flood-opacity="1" result="cover"/>
  <feComposite in="cover" in2="SourceGraphic" operator="over"/>
  <animateTransform attributeName="x" type="translate"
                    to="0%" begin="consentForm.focus"
                    dur="0s" fill="freeze"/>
  <animateTransform attributeName="y" type="translate"
                    to="0%" begin="consentForm.focus"
                    dur="0s" fill="freeze"/>
</filter>

Attack pattern 4 (SA-SMIL-004): chained animate creating a consent-phase visibility window

<feFlood flood-color="white" flood-opacity="0" result="cover">
  <animate attributeName="flood-opacity" to="1"
           begin="submitBtn.mousedown" dur="indefinite" fill="freeze"/>
  <animate attributeName="flood-opacity" to="0"
           begin="submitBtn.mouseup" dur="0.1s" fill="freeze"/>
</feFlood>

The detection algorithm

Detecting SMIL timing attacks requires traversing the filter element's full descendant tree and evaluating each animate/set/animateTransform element against three criteria: does it target a consent-relevant attribute, what is its to value, and does its begin trigger reference a user interaction event on the consent form or its interactive children?

function detectSMILConsentTimingAttacks(filterEl, consentFormEl) {
  const risks = [];
  const interactiveIds = new Set(
    [...consentFormEl.querySelectorAll('button, input, [tabindex]')]
      .map(el => el.id).filter(Boolean)
  );
  interactiveIds.add(consentFormEl.id);

  // Interaction event names SMIL can reference
  const INTERACTION_EVENTS = new Set([
    'click','mousedown','mouseup','mouseenter','mouseover',
    'focus','focusin','submit','change','keydown','keyup'
  ]);

  // Attributes whose attack-state values indicate a consent erasure
  const ATTACK_CHECKS = {
    'flood-opacity': v => parseFloat(v) > 0.5,
    'flood-color':   v => isLightColor(v),
    'slope':         v => parseFloat(v) < 0.2,       // feFuncA slope
    'intercept':     v => parseFloat(v) > 0.5,       // feFuncA intercept
    'amplitude':     v => parseFloat(v) < 0.1,       // feFuncA amplitude
    'opacity':       v => parseFloat(v) < 0.2,
    'x':             _v => true,                     // filter region repositioning
    'y':             _v => true,
    'width':         v => parseFloat(v) < 5,
    'height':        v => parseFloat(v) < 5,
  };

  const animationEls = filterEl.querySelectorAll(
    'animate, set, animateTransform, animateMotion'
  );

  for (const anim of animationEls) {
    const attrName = anim.getAttribute('attributeName');
    const toVal    = anim.getAttribute('to') || anim.getAttribute('values');
    const beginVal = anim.getAttribute('begin') || '';
    const fillVal  = anim.getAttribute('fill') || 'remove';

    if (!attrName || !toVal) continue;

    // Parse begin= for interaction event references
    const beginParts = beginVal.split(';').map(s => s.trim());
    for (const part of beginParts) {
      const dotIdx = part.lastIndexOf('.');
      if (dotIdx === -1) continue;
      const refId    = part.slice(0, dotIdx);
      const eventName = part.slice(dotIdx + 1);

      if (!INTERACTION_EVENTS.has(eventName)) continue;
      if (!interactiveIds.has(refId)) continue;

      // Interaction-triggered animation on consent form element — check attack value
      const checker = ATTACK_CHECKS[attrName];
      if (checker && checker(toVal)) {
        risks.push({
          animElement: anim,
          attribute: attrName,
          toValue: toVal,
          trigger: part,
          persistent: fillVal === 'freeze',
          severity: fillVal === 'freeze' ? 'critical' : 'high'
        });
      }
    }
  }

  return risks;
}

function isLightColor(colorStr) {
  if (/^(white|#fff|#ffffff)$/i.test(colorStr)) return true;
  const m = colorStr.match(/rgba?\((\d+),\s*(\d+),\s*(\d+)/);
  if (!m) return false;
  return parseInt(m[1]) > 200 && parseInt(m[2]) > 200 && parseInt(m[3]) > 200;
}

Three design decisions in this algorithm deserve explanation:

1. Recursive querySelector vs. manual descent. querySelectorAll on the filter element descends into all shadow-host boundaries that are in the same tree, including deeply nested feComponentTransfer → feFuncA hierarchies. Manual stack-based descent is equivalent but more explicit. Either approach reaches the feFuncA level without requiring special handling.
2. ID-based begin= parsing vs. full SMIL timing model. The SMIL timing model supports accesskey, wallclock, repeat, and event references without IDs. The algorithm above handles only the ID-event form (elementId.eventName) because that is the most common attack vector. A complete auditor should also handle 0s (immediate on load), click (without element ID — references the animation element's own parent), and indefinite.
3. fill="freeze" as severity escalator. A fill="remove" animation creates an attack window equal to its duration. A fill="freeze" animation creates a permanent attack after the trigger. Both are dangerous, but the freeze variant converts a one-time interaction into a persistent page-state change — the consent element remains hidden for the lifetime of the page session.

Comparison: SMIL vs. JavaScript consent timing attacks

Remediation

Related findings

• SVG animate filter security — interaction-triggered filter timing attacks overview
• feConvolveMatrix edgeMode parameter — targeted boundary erasure patterns
• SVG use element — cloning filter-attacked consent elements
• CSS feComposite operator="in" as the DOM Ghost Attack
• CSS stroke-dashoffset as a consent timing attack — SVG stroke animation patterns