Probe Suite

Detect injected content scripts by scanning for known DOM mutations and event listeners.

Test the @ symbol trick and other URL obfuscation methods.

Test multi-hop redirect chains to see if intermediate hops bypass filtering.

Create deeply nested iframe chains to test content script injection limits.

Measure the time between navigation and extension interception.

The extension uses a ping/pong mechanism with a 5-second timeout. Measure the actual response latency.

Test which URI schemes are intercepted by webRequestBlocking.

Test if data: and blob: URIs bypass content filtering.

How: Open about:blank in a new window, then use document.write() to inject content.
Why it works: webRequestBlocking never fires for about:blank (no HTTP request). The iframeObserver sees about:blank as top URL but only blocks iframes inside it, NOT the content written directly to the page body.
Content script injection: <all_urls> does NOT match about: scheme - content scripts won't inject.

How: Create a full browsing interface as a data:text/html URI.
Why it works: webRequestBlocking cannot intercept data: scheme. Content scripts don't match data:. The page contains a URL bar and uses fetch to proxy content.
Limitation: CORS blocks most cross-origin fetches, but some APIs and pages with permissive CORS will work.

How: Create a blob: URL containing a full page with navigation interface.
Why it works: blob: URLs are session-scoped, opaque, and not interceptable by webRequest. Each blob URL is unique and unpredictable.

How: Use Google Translate's web proxy to load blocked pages through translate.google.com.
Why it works: Google Translate is typically whitelisted for education. It proxies the entire page content through Google's servers, so the actual domain never appears in webRequest.
Key: Content scripts ARE excluded for docs.google.com per manifest exclude_matches. Google Translate may or may not be excluded.

How: Flood the service worker until it can't respond to its own ping within 5s, triggering chrome.runtime.reload().
Why it works: During SW reload, ALL filtering (webRequest handlers) are temporarily deregistered. The filtering gap lasts 1-3 seconds.
Enhanced: Uses blockPage.html?source=contentScript which contains its own SW ping+reload mechanism, amplifying the attack.

How: Create an iframe with sandbox="allow-scripts" but WITHOUT allow-same-origin.
Why it works: Without same-origin, the frame is treated as a unique opaque origin. Content scripts cannot inject into it. However, webRequest may still block the network request.

How: Content scripts are EXCLUDED from certain domains (see manifest). Navigate through whitelisted domains.
Excluded domains: *.sharepoint.com, *.office.com, *.officeapps.live.com, *.office365.com, docs.google.com
Key insight: These domains have a separate content script config with all_frames: true but different behavior.

How: The iframeObserver delays 100ms on popstate/hashchange before re-checking. Rapidly mutate iframe src to exploit the gap.
Code: window.addEventListener("hashchange", () => setTimeout(() => P(), 100))
Key: The function P() is async and awaits chrome.runtime.sendMessage - there's a gap between the hash change and the filtering response arriving.

Root Cause: background.js does NOT encodeURIComponent() the blocked URL before injecting it into the redirect to blockPage.html?url=....
Impact: If a blocked URL contains # (e.g. discord.com/#/...), the browser treats everything after # as the block page's own fragment - all subsequent query parameters (filter, type) are lost.
Code Path: blockPage.js -> new URL(window.location.href).searchParams -> only sees params before #
Confirmed: ✅ You verified this - block page for discord.com/#/... is missing "Access Denied By: Url Filter" because filter param is truncated.

Generate URLs with fragment payloads to test the block page parameter truncation.

Shows how the block page sees the URL with vs without fragment injection.

All chrome.runtime message types extracted from the extension source.