CSS Timing Attack Synthesis: When MCP Consent Is Visible at Audit Time but Hidden at Interaction Time

The browser event sequence for a button click is: mousedown → mouseup → click. A mousedown handler fires the moment the user presses their pointer on the install button — before the click resolves and before any click-event handler calls the install API. MCP JavaScript attaches a mousedown listener to the install button that immediately collapses the consent element:

/* SA-CSS-TIMING-001 — mousedown handler consent collapse */
const installBtn = document.querySelector('.mcp-install-btn');
const consentEl = document.querySelector('.mcp-consent-disclosure');

installBtn.addEventListener('mousedown', () => {
  /* Fires before the click event — consent collapses immediately on button press */
  consentEl.style.display = 'none';
  /* OR: consentEl.style.opacity = '0'; consentEl.style.height = '0'; */
});

/* At audit time (page load): consentEl.style.display === '' (unset — inherits block) */
/* At interaction time (user presses install button): consentEl.style.display === 'none' */

/* Why this matters:
   - Any audit capturing DOM state at load time sees consent visible
   - The install API fires in the click handler, which runs AFTER the mousedown handler
   - By the time install() is called, consent has been hidden for ~50–100ms
   - The user's visual cortex registered the page layout before pressing the button;
     they pressed because they saw something — but at the moment of pressing,
     consent collapsed. They see a flash of collapse, if anything. */

This pattern is detectable only by intercepting the mousedown event on the install button and checking consent visibility both before and after the event fires. A MutationObserver watching the consent element for style mutations will catch the display: none injection during the mousedown handler. Load-time computed-style checks will not. The flex-shrink deferred collapse variant uses this same mousedown-trigger pattern with a CSS property change instead of a direct style assignment.

CSS animations allow an initial delay before the animation begins. Combined with animation-fill-mode: forwards, the element retains the final keyframe state after the animation completes. An MCP server uses this to make consent visible for the first few seconds of page load — long enough for any audit tool that snapshots the DOM at DOMContentLoaded — and then hide it permanently:

/* SA-CSS-TIMING-002 — animation delay hiding */
@keyframes hide-consent {
  0%   { opacity: 1; height: auto; overflow: visible; }
  99%  { opacity: 0; height: auto; overflow: visible; }
  100% { opacity: 0; height: 0;    overflow: hidden;  }
}

.mcp-consent-disclosure {
  /* Consent is fully visible for the first 3 seconds after page load */
  /* After 3 seconds, it fades out and collapses to height:0 */
  animation: hide-consent 0.5s ease-in 3s both forwards;
  /*                                     ↑ 3 second delay
                                "both" = animation-fill-mode: both
                                Means: before animation starts (0–3s), consent is at 0% = opacity:1
                                After animation ends (3.5s+), consent is at 100% = opacity:0, height:0 */
}

/* Audit at t=0 (DOMContentLoaded):  opacity: 1,  height: auto ✓ PASSES */
/* Audit at t=1s:                    opacity: 1,  height: auto ✓ PASSES */
/* Audit at t=3.5s (interaction):    opacity: 0,  height: 0    ✗ HIDDEN */

/* getComputedStyle at t=0 returns: opacity = "1" — audit passes
   getBoundingClientRect at t=0 returns non-zero — audit passes
   CSS animation fill-mode keeps the hiding in effect after the animation ends */

The 3-second delay is calibrated to exceed typical automated audit run times. Most automated consent auditors fire within 1–2 seconds of DOMContentLoaded. Real users typically spend 3–8 seconds reading the install page before clicking install. By the time the user clicks, consent has been hidden for several seconds. The steps() timing function variant achieves the same pattern with discrete animation steps instead of smooth transitions, making the collapse less perceptually obvious as a "fade".

Some security auditors perform a second DOM check one frame after DOMContentLoaded using a single requestAnimationFrame callback. This catches hiding that happens during the DOMContentLoaded event handler. Double-rAF (two nested requestAnimationFrame calls) defers execution to after the browser's first full layout and paint cycle — two frames after DOMContentLoaded — evading single-rAF auditors:

/* SA-CSS-TIMING-003 — double-rAF deferred hiding */
document.addEventListener('DOMContentLoaded', () => {
  /* Single rAF: fires after first paint — single-rAF auditors catch this */
  /* requestAnimationFrame(() => { collapseConsent(); }); */

  /* Double rAF: fires after second paint — evades single-rAF auditors */
  requestAnimationFrame(() => {
    requestAnimationFrame(() => {
      /* Two paint frames after DOMContentLoaded */
      /* MCP security checks running in a single rAF will have already run */
      const consent = document.querySelector('.consent-disclosure');
      if (consent) {
        consent.style.height = '0';
        consent.style.overflow = 'hidden';
        consent.style.opacity = '0';
        consent.setAttribute('aria-hidden', 'true');
      }
    });
  });
});

/* setTimeout variant: collapse after 100ms — sufficient to escape DOMContentLoaded checks */
/* setTimeout(() => { collapseConsent(); }, 100); */

/* At DOMContentLoaded + rAF:      consent visible ✓  (single-rAF audit passes)  */
/* At DOMContentLoaded + 2 rAFs:   consent hidden  ✗  (double-rAF hides it here) */
/* At user interaction (~1000ms+): consent hidden  ✗  */

This vector is particularly subtle because the hiding happens so early — within milliseconds of page load — that it appears to be part of the initial page render. The user sees a brief flash of consent in the first two frames, then it collapses. On high-refresh-rate displays (120Hz), two frames is approximately 16ms — imperceptible to the human eye. A human reviewer watching the page load may see consent appear and immediately disappear and attribute it to a rendering artifact. The align-self deferred JS variant uses this same pattern applied to a CSS layout property rather than an explicit style collapse.

CSS transitions require a trigger — a change in the element's computed property value. MCP JavaScript triggers this change by adding a class to the consent element at the start of the install flow. The transition duration is short enough that consent is fully hidden before the user can read it at interaction time, but long enough to appear "animated" rather than a sudden flash:

/* SA-CSS-TIMING-004 — class-toggle triggered transition */

/* CSS: */
.mcp-consent-disclosure {
  max-height: 500px;
  overflow: hidden;
  opacity: 1;
  transition: max-height 0.2s ease-out, opacity 0.2s ease-out;
}

.mcp-consent-disclosure.collapsing {
  max-height: 0;
  opacity: 0;
  /* Transition: 200ms smooth collapse from max-height:500px and opacity:1
     to max-height:0 and opacity:0 */
}

/* JS: */
const installBtn = document.querySelector('.install-btn');
const consent = document.querySelector('.mcp-consent-disclosure');

installBtn.addEventListener('click', (e) => {
  /* Immediately start collapsing consent when user clicks install */
  consent.classList.add('collapsing');

  /* The install API call runs after the transition starts */
  /* In 200ms, consent will be at max-height:0 and opacity:0 */
  setTimeout(() => { initiateInstall(); }, 0); /* microtask — after click handler */
});

/* At load time: .collapsing not present → consent visible ✓ */
/* At click time: .collapsing added → consent starts collapsing */
/* 200ms after click: consent fully hidden ✗ */
/* install() resolves in ~500ms–2s (network): consent long gone */

/* Evasion: the 200ms transition looks like a legitimate UI animation.
   The transition to max-height:0 is a common accordion/collapse UI pattern.
   Auditors that check only for display:none or visibility:hidden miss max-height collapse.
   Auditors that check computed height/BoundingClientRect at load time see normal dimensions. */

This vector exploits two auditing gaps simultaneously: the timing gap (transition activates at click time, not load time) and the property gap (the hiding uses max-height: 0 combined with overflow: hidden rather than display: none or visibility: hidden). Standard checks for display/visibility do not catch max-height collapse. The max-height consent attack page covers the static variant; the class-toggle trigger is the timing variant.

The hover event fires when the user's cursor enters the install button's bounding box — well before mousedown or click. A :hover CSS rule on the install button can target the consent element via a sibling or descendant combinator, making consent collapse the moment the user hovers over the install button. If the CSS change uses a property that does not un-change on mouseout (or if JS makes the change permanent), consent remains hidden for the entire click sequence:

/* SA-CSS-TIMING-005 — hover-triggered consent hiding */

/* CSS approach (reverts on mouseout — brief window): */
.mcp-install-container:hover .consent-disclosure {
  opacity: 0;
  pointer-events: none;
}
/* Brief window: consent is hidden while cursor is inside .mcp-install-container.
   If user moves off and back, consent flashes visible.
   But if click fires during hover, install completes with consent hidden. */

/* JS approach (permanent — does not revert on mouseout): */
const installBtn = document.querySelector('.install-btn');
const consent = document.querySelector('.consent-disclosure');
let hidden = false;

installBtn.addEventListener('mouseover', () => {
  if (!hidden) {
    hidden = true;
    /* Permanent class addition — does not revert on mouseout */
    consent.classList.add('mcp-consent-collapsed');
    /* CSS: .mcp-consent-collapsed { display: none; } */
  }
});

/* At load time: .mcp-consent-collapsed not present → consent visible ✓ */
/* User moves cursor over install button → mouseover fires → consent hides permanently */
/* User clicks → install completes with consent permanently hidden ✗ */

/* Detection gap: cursor position is not inspectable by a static DOM auditor.
   Load-time audit sees consent visible. Interaction simulation must move cursor
   over the install button to trigger the mouseover handler and observe the hiding. */

/* Additional evasion: mouseover fires before the audit tool's interaction simulation
   moves the cursor — if the simulation goes directly to click without pausing over
   the button, the handler does not fire and the audit falsely passes. */

The hover-triggered vector is particularly hard to detect because it requires an audit tool that not only simulates interaction but does so with realistic cursor movement — approaching the install button from a typical position, dwelling over it briefly, then clicking. Fast automated click simulation that jumps directly to the button coordinates without a hover phase will miss this attack entirely. The gap hover-expansion variant uses this same trigger to expand a column-gap from 0 to 100vw, displacing consent off-screen horizontally.