COOKR – Cookie Consent & Script Blocking

GDPR cookie consent with real script blocking. Block Google Analytics, Google Tag Manager, Meta Pixel, Hotjar, YouTube embeds, and other third-party services before they reach the browser. Unlike JavaScript-based consent tools, blocked scripts never reach the browser at all. Most cookie consent plugins display a banner and rely on JavaScript to stop tracking scripts. In many cases, those scripts can begin loading before the visitor has made a choice. COOKR takes a different approach. Scripts are blocked server-side before page delivery. Third-party services cannot execute until consent is explicitly granted. This helps website owners meet GDPR and TTDSG requirements more reliably. Avoids the client-side race conditions common to JavaScript-only consent tools. No script guessing. No "hope it loads in time." Consent enforcement instead of consent theatre. ✓ Server-side script blocking — blocked before the browser receives them ✓ Google Consent Mode v2 support ✓ No external consent cloud ✓ No proxy infrastructure ✓ No visitor data sent to third parties ✓ Works entirely on your WordPress installation Built for site owners, agencies, and developers who want real GDPR cookie consent enforcement. COOKR CORE includes:

• Consent banner & preferences UI
• Server-side script interception via PHP output buffer
• Auto-Blocker for third-party scripts and iframes
• Runtime Inspector
• CSP-aware restoration with nonce propagation
• Google Consent Mode v2 support
• Full JavaScript API (window.cookrConsent)
• Compatibility Center — live enforcement status plus a tested-stack matrix with honest VERIFIED/PARTIAL/UNKNOWN/FAILED states
• Automatic optimizer exclusions — LiteSpeed, WP Rocket, Autoptimize, FlyingPress
• Self-hosted operation — no external services required

COOKR RADR additionally includes:

• Privacy Radar — runtime detection and classification of third-party services
• Enforcement Verification Framework — structured protocol for proving enforcement claims
• Curated signature database with automatic weekly updates

How It Works COOKR intercepts scripts in the PHP output buffer using WP_HTML_Tag_Processor before delivery to the browser. Matching script and iframe tags are neutralised server-side and restored only after the visitor grants consent. There is no client-side race condition because blocking happens before the browser receives the page. Reliability Your consent choices are applied precisely — analytics, marketing, and external media are gated independently, with no mixups between categories. You can withdraw consent at any time; it takes effect starting with your next page load. COOKR is safe to use with page caching. The server-rendered HTML is always consent-neutral — a cached page never carries one visitor's consent-based content into another visitor's response. If COOKR encounters an internal enforcement failure, it fails closed rather than silently serving unblocked trackers. Scope of Enforcement COOKR blocks known trackers that are present in the server-rendered HTML as standard external <script src> or <iframe> elements, before the visitor's browser ever receives them. It does not intercept arbitrary JavaScript behaviour at runtime. This includes: scripts and iframes created dynamically after page load, document.write()-based script injection, and tracker requests proxied through a first-party URL — COOKR matches known third-party hostnames, so a same-origin proxy path is invisible to that classification regardless of what it forwards to server-side. One consequence worth knowing specifically: once a tag manager such as Google Tag Manager is itself permitted to run (its own <script src> was consented to and restored), whatever tags that container subsequently injects at runtime are outside COOKR's enforcement scope. Configuring consent-aware tag firing inside the tag manager itself remains the site owner's responsibility. These are architectural limits of a server-side, markup-level blocker, not partial results. If your site loads trackers through any of the paths above, COOKR will not enforce consent on them — migrate them to standard external <script src>/<iframe> markup to bring them into scope. Auto-Blocker Enable in Settings. Off by default. When enabled, COOKR rewrites matching script tags and iframe tags server-side — setting type="text/plain" and preserving original attributes in data-cookr-* attributes for restoration after consent. Test after enabling when using WP Rocket, LiteSpeed Cache, NitroPack, or Cloudflare Rocket Loader. Runtime Inspector The Runtime Inspector exposes third-party runtime activity directly in the browser — blocked scripts, restored services, iframe activity, detected domains. Enable in Settings. Append ?cookr_debug=1 to any frontend URL while logged in as administrator. Compatibility COOKR is verified compatible with WP Rocket and Autoptimize. It is partially verified with LiteSpeed Cache — see the Compatibility Center for exactly which parts are confirmed. For other caching and optimization plugins, check your own site's Compatibility Center before assuming full compatibility. CSP-aware COOKR never sends its own Content-Security-Policy header. It supports strict Content-Security-Policy setups without requiring unsafe-inline, provided your CSP layer supplies a nonce through the cookr_csp_nonce filter. If your site runs a nonce-based script-src policy, hook the cookr_csp_nonce filter once with the nonce your CSP layer already generates for the response: add_filter( 'cookr_csp_nonce', function () { return my_csp_plugin_get_nonce(); } ); COOKR then applies that single nonce consistently to its own scripts and to every dynamically-restored, consented tracker script. Without a hooked cookr_csp_nonce provider, COOKR's own scripts and any restored tracker scripts will be blocked by a strict script-src policy with no 'unsafe-inline' — the Diagnostics self-test reports this explicitly (CSP nonce: pass/warn) rather than silently assuming it works. Developer JS API cookrConsent.has('analytics') cookrConsent.require('marketing', callback) cookrConsent.whenConsented('analytics').then(fn) cookrConsent.on('consent' | 'change' | 'decline' | 'reset', handler) cookrConsent.off(event, handler) cookrConsent.getConsent() cookrConsent.getExpiry() cookrConsent.categories() cookrConsent.reset() Consent Categories

• Necessary — Always active.
• Analytics — GA, GTM, Matomo, Hotjar, Clarity, etc.
• Marketing — Meta Pixel, Google Ads, TikTok, LinkedIn, etc.
• External Media — YouTube, Vimeo, Google Maps, etc.

Does COOKR require an external cloud service? No. COOKR runs entirely on your WordPress installation. Does visitor consent data leave the server? No. Consent data is stored locally on your site. Is the Auto-Blocker enabled by default? No. Enable and test it after installation, particularly when using caching or JavaScript optimization plugins. Which services can be blocked? Any third-party script or iframe matching configured domains, when present in the server-rendered page as a standard external <script src> or <iframe> element. Examples: Google Tag Manager, Meta Pixel, YouTube embeds, TikTok Analytics. What about tags Google Tag Manager loads on its own? COOKR gates GTM's own <script src> load — GTM itself will not run before consent. Once a visitor consents and GTM is restored, tags that GTM subsequently injects at runtime are outside COOKR's enforcement scope; that's a tag manager configuration question, not something a markup-level blocker can see. See "Scope of Enforcement" above for the full picture. Does COOKR support Google Consent Mode v2? Yes. Enable in settings when using GTM or GA4. How do I inspect runtime activity? Enable the Runtime Inspector in settings and append ?cookr_debug=1 to any frontend URL while logged in as administrator. Does COOKR store personal data? The consent log stores a hashed IP (not the raw IP address), consent choices, and a timestamp. The raw IP address is never stored. Is COOKR compatible with strict CSP? Yes, if your site's CSP layer supplies a nonce. COOKR does not generate or send its own CSP, and it cannot see a nonce your CSP-generating plugin creates unless you connect the two: hook the cookr_csp_nonce filter once to return that nonce. COOKR then applies it consistently to its own scripts and to every dynamically-restored, consented tracker script. Without that filter hooked, a strict script-src policy with no 'unsafe-inline' will block COOKR's own scripts as well as any restored trackers — check Settings → Diagnostics, which reports the CSP nonce check explicitly rather than assuming success. Will COOKR work with caching plugins such as LiteSpeed Cache, WP Rocket, or Cloudflare? Yes, but always test after enabling script optimization features such as JavaScript combine, defer, delay, or Rocket Loader. COOKR performs script blocking server-side, but aggressive optimization plugins may alter script delivery and should be verified on your site. COOKR automatically excludes itself and the tracker scripts it blocks from LiteSpeed Cache, WP Rocket, Autoptimize, and FlyingPress's JavaScript optimization pipelines — no configuration required. Check the Compatibility Center (COOKR → Compatibility) for the current tested/verified status of your specific stack. Does COOKR require HTTPS? Yes. COOKR requires HTTPS for consent state to persist correctly across page loads. Modern browsers restrict cookie behaviour on HTTP origins — on HTTP, the consent cookie may not persist, causing the banner to reappear on every page load. HTTPS is also a legal recommendation under GDPR for any site collecting consent. What WordPress version is required? WordPress 6.2 or higher. COOKR uses WP_HTML_Tag_Processor for safe, attribute-aware script rewriting, introduced in WP 6.2.

1.9.33

• Docs: added a "Reliability" section (consent accuracy, cache safety, fail-safe enforcement) and a "Compatibility" section (named only where the Compatibility Center currently supports the claim — WP Rocket and Autoptimize verified, LiteSpeed Cache explicitly partial). Tightened the CSP-aware section's opening sentence to put the cookr_csp_nonce requirement up front rather than reading as automatic. No functional changes — every claim added here already has a corresponding live Compatibility Center status, per this week's trust-testing program.

1.9.32

• Added: Compatibility Center now includes an "Enforcement Fail-Safe" check — verifies the fail-closed fallback mechanism (added in the enforcement rearchitecture) is present and correctly wired on this installation, and reports any recorded fallback events. This is the check that licenses the product claim that COOKR never silently serves unblocked trackers on an internal failure. Also adds an informational "Update channel" row (CORE: confirms updates flow through WP.org as usual; RADR: reports the update-service's reachability — this never affects the main enforcement status, by design).

1.9.31

• Fixed: cookr_fallback_events (enforcement fail-closed fallback history, introduced in 1.9.30) was missing from the uninstall cleanup list — an orphaned option left behind on a full uninstall with "preserve data" off. Found during upgrade-safety testing.

1.9.30

• Security/privacy fix: COOKR's enforcement now fails closed instead of open. Previously, if the script/iframe rewrite pass threw for any reason (a plugin conflict, an edge case in the HTML parser, a future bug), COOKR served the original, completely unblocked page to every visitor — including ones with zero consent — with no visible signal beyond a debug-log line gated behind WP_DEBUG_LOG (off by default in production). Found via a controlled failure test, confirmed live. Replaced with a three-stage chain: the normal rewrite, an independent emergency fallback that conservatively neutralises every cross-origin <script>/<iframe> (deliberately not reusing the classifier or parser that may have just failed), and — if even that fails — a minimal privacy-safe response with zero third-party resources instead of the original page. The Runtime Inspector's own scanning is now strictly best-effort and can never affect enforcement. A persistent, WP_DEBUG-independent admin notice and a new Diagnostics check surface if this fallback is ever triggered.

1.9.29

• Fixed: CSP nonce propagation was structurally non-functional — COOKR read back a nonce from its own script handle in the same call that registered it, before any external CSP plugin could ever attach one, so the value was always empty and dynamically-restored consented scripts were silently blocked by any real strict script-src policy. Replaced with an explicit cookr_csp_nonce filter: site owners hook it once with the nonce their CSP layer already generates, and COOKR applies that single value consistently to its own scripts and to every restored tracker script. The Diagnostics self-test now reports pass/warn honestly instead of a permanent placeholder warning, and the CSP documentation no longer claims "no manual configuration required."

1.9.28

• Accessibility fixes found during a consent-decision accessibility audit: category checkboxes now expose the category name as their accessible name (aria-labelledby) with the explanatory sentence as a proper description (aria-describedby), instead of a short aria-label that silently hid it from screen readers. Fixed insufficient text contrast on the "Customise"/preferences-toggle control and the category-description text (light and dark mode). The banner dialog now carries a lang attribute matching COOKR's configured banner language (independent of the site's own <html lang>), and its title is a real heading (<h2>, referenced via aria-labelledby) instead of a plain paragraph.

1.9.27

• New: Custom Domains setting. Manually add a domain COOKR hasn't recognised yet and assign it to Analytics, Marketing, or External media — no longer requires RADR's automated scan to unlock manual domain blocking. Validates hostnames, rejects duplicates, and keeps built-in signatures separate from custom rules.

1.9.26

• Autoptimize compatibility promoted to VERIFIED. Live-tested with a fresh Autoptimize 3.1.15.1 install (free, no license required): JS and CSS optimization (minify + combine) tested individually and together, all trackers stayed blocked, zero tracker requests before consent. Documented a real, non-breaking behavioral nuance: Autoptimize still individually minifies COOKR's own excluded assets rather than leaving them fully untouched -- confirmed the served content is byte-correct and does not affect the blocking guarantee

1.9.25

• WP Rocket compatibility promoted to VERIFIED. The last open gap (post-consent network execution) was closed by re-testing in a real Chrome browser: a genuine network request fired correctly after consent for a neutral test domain, confirming the earlier "not tested" result was a limitation of the automated test tooling used, not a product defect. All 6 tested dimensions (Minify JS, Combine JS, Defer JS, Delay JS, page-cache isolation, post-consent execution) are now VERIFIED

1.9.24

• Compatibility Center: redesigned the compatibility matrix schema to support per-dimension evidence, not just one status per optimization stack. WP Rocket and LiteSpeed Cache now record real, individually-tested results for each dimension (Minify JS, Combine JS, Defer JS, Delay JS, page-cache isolation, etc.) with an honestly-derived overall status -- a stack with several verified dimensions and one still-open one now shows PARTIAL with the real breakdown visible, instead of a single, less informative badge. Backward compatible: existing code reading a stack's overall status is unaffected; entries without per-dimension data behave exactly as before

1.9.23

• Removed the full-consent server-side bypass so cacheable HTML remains consent-neutral across visitors. A server-side shortcut previously skipped the blocking rewrite entirely for a visitor with a valid, fully-granted consent cookie -- safe for that one uncached visitor, but a real cross-visitor leak the moment any full-page cache (WP Rocket, LiteSpeed, etc.) stored and replayed that exact response, serving every subsequent visitor an unblocked tracker regardless of their own consent state. Found via real page-cache testing. Server-rendered HTML is now always the blocked canonical form for every visitor; restoration for consented categories continues to happen exclusively client-side, unaffected by caching since it reads each visitor's own consent cookie in their own browser

1.9.22

• WP Rocket compatibility: the 1.9.21 fix only protected COOKR's own script, not the third-party trackers it blocks. Live testing against a real licensed WP Rocket install found Minify JS and Delay JS both strip COOKR's blocking from trackers and execute them before consent, because WP Rocket processes the page before COOKR's own blocking runs (an output-buffer ordering issue, confirmed via direct tracing). Fixed by excluding all of COOKR's known tracker domains from WP Rocket's JS pipelines. Verified: zero tracker network requests before consent with WP Rocket's full JS optimization pipeline enabled. Compatibility matrix moved to PARTIAL — known limitations (custom/self-hosted scripts, post-consent network verification, page-cache isolation) documented, not overclaimed

1.9.21

• WP Rocket compatibility: found the integration had been a complete no-op since it was written. The filter it hooked, rocket_excluded_strings, does not exist anywhere in WP Rocket's codebase — confirmed by cloning and grepping WP Rocket's actual public source, since it has no free WP.org listing or trial to install and test against directly. Replaced with the real filters (rocket_exclude_js, rocket_exclude_defer_js, rocket_delay_js_exclusions), verified against WP Rocket's own source and its official Termly integration. Code-verified, not yet live-tested; compatibility matrix status stays UNKNOWN pending a real test

1.9.20

• LiteSpeed Cache compatibility: attempted guest_mode/guest_optimization/cache_persistence/esi verification, found this test environment doesn't run genuine LiteSpeed Web Server (plain Apache), so page-level caching — what those checks actually test — can't be meaningfully verified here. Documented in the compatibility matrix; needs a real LSWS/OpenLiteSpeed environment to complete

1.9.19

• Added a Compatibility Center admin page (COOKR → Compatibility) surfacing the plugin's own internal enforcement-verification data, previously invisible: live status of the auto-blocker, Runtime Inspector, optimization-stack detection, and known conflict signatures on this specific installation, plus the full reference compatibility matrix (8 known optimizer/CDN stacks, honestly marked Verified/Partial/Not yet verified/Failed) with whichever stacks are actually detected on this site called out inline

1.9.18

• Fixed the LiteSpeed Cache/WP Rocket/FlyingPress exclusion filters hardcoding COOKR's plugin folder name in the excluded path (/wp-content/plugins/cookr/...) — a string that only matches if the plugin folder happens to be named exactly "cookr". Every real CORE install (the actual WP.org-distributed folder name, cookr-cookie-consent-script-blocking) never matched, so these three optimizers' exclusions were silently no-ops on CORE the whole time. Now resolved dynamically via COOKR_PLUGIN_URL at runtime instead
• Fixed COOKR's own banner failing to initialise under LiteSpeed Cache's "Delay JS Execution" feature specifically: LiteSpeed checks a separate exclusion list for Defer/Delay than the one COOKR was already registered on (which only ever covered Combine/Minify). Trackers stayed correctly blocked throughout, but the banner and consent JS API didn't load until the visitor scrolled or clicked. Fixed by also hooking LiteSpeed's litespeed_optm_js_defer_exc filter
• LiteSpeed Cache compatibility: verified JS Delay — all 6 protocol test cases pass (after the fixes above)

1.9.17

• LiteSpeed Cache compatibility: verified JS Defer — all 6 protocol test cases pass with JS Combine off / JS Defer on. See the Enforcement Verification Framework compatibility matrix for full detail

1.9.16

• Fixed miscategorized Google Ads conversion tags: the auto-blocker classified every script on googletagmanager.com as "analytics" regardless of which Google product it actually loaded, so a Google Ads conversion tag (gtag/js?id=AW-...) was silently gated behind Analytics consent instead of Marketing consent. The blocker now reads the tag's id parameter — AW-* is classified as marketing, G-* (GA4) remains analytics, GTM containers (GTM-*) are unchanged pending a separate design decision, since a single container can load both marketing and analytics tags
• This release also folds in the 1.9.13–1.9.15 fixes below, which were written up at the time but never reached a tagged release — this is their first time shipping to WordPress.org

1.9.15

• Fixed CORE packaging: the build script was incorrectly stripping assets/cookr-debug.js (the Debug Inspector script) from CORE builds, despite Debug Inspector being a documented, default-on feature in both CORE and RADR. CORE builds now correctly include this file. No functional change to this codebase itself — RADR was never affected, since it has always included the file directly from source

1.9.14

• Fixed banner overflowing the viewport edge on mobile (≤480px): #cookr-banner had no explicit box-sizing, so the mobile layout's width: 100% plus the banner's existing border was rendered as 100vw + border-width, causing the banner to extend ~2px past the right edge of the screen. Added box-sizing: border-box to the shared #cookr-banner, #cookr-reopen rule so the banner's total rendered width exactly matches the viewport on mobile. No visual change on desktop (320px fixed-width banner)

1.9.13

• Fixed missing CSS for the disabled "Sync with active theme" (Theme Sync) field in the admin dashboard: when Scoped Banner Styling (custom CSS / a built-in preset) is active, JavaScript already added a cookr-accent--disabled class and an "Overridden by Scoped Banner Styling" message to the Theme Sync field — matching the existing accent-colour picker behaviour — but admin.css only styled this disabled state for the accent field, not the Theme Sync field. The font pills remained fully clickable and visually normal with no indication that font sync was inactive. The disabled-state styling (38% opacity, disabled pointer events, override message) now applies to both fields
• No functional change to font sync itself — fonts synced from the active theme still only apply to the live banner when no custom CSS/preset is active (custom CSS retains full control of typography by design). This fix makes that existing, correct behaviour visible and understandable in the admin UI

1.9.12

• Fixed COOKR CRAZE built-in preset: the minimised (reopen) button was unstyled and the preferences-panel toggle switches showed the site's global accent colour (could be any colour, including red) instead of the preset's green — the preset never set --cookr-accent, so cookr.css's defaults for #cookr-reopen and .cookr-switch input:checked + .cookr-slider (both driven by var(--cookr-accent)) fell through to the global accent_color setting
• Added #cookr-banner, #cookr-reopen { --cookr-accent: #00ff88; } and #cookr-reopen svg rect { fill: #000000; stroke: #00ff88; } to the preset — toggle switches and the reopen pill/dot now render in the preset's black/green theme regardless of the global accent colour setting
• Fixed admin preview panel loading spinner: @keyframes cookr-spin only animates transform: rotate(), but the spinner's centering also used transform: translate(-50%, -50%) — animating transform between an implicit translate(...) start and a rotate(360deg) end produced a visible jump/skip instead of a clean spin. Centering now uses top/left + negative margin, leaving transform free for rotation only
• Made the admin preview banner fully static — removed the cosmetic preferences-panel click handler, and the preview banner / reopen button no longer respond to hover or click (pointer-events: none). The preview is a visual reference only, not an interactive demo
• Fixed a critical non-idempotency bug in the custom CSS sanitiser (cookr_scope_css): every settings save re-sanitises the currently saved value (the textarea is repopulated with the previously-scoped output), but the selector-mirroring logic was not idempotent — an already-mirrored selector like #cookr-banner .cookr-inner would itself pass the #cookr-/.cookr- prefix check and get re-added on each save, and the .cookr-title svg icon-colour helper would re-fire for both a selector and its mirror, with both copies persisting forward. On real-world installs this had compounded over repeated saves into 150+ duplicate copies of some rules and a single selector list repeated 18 times, ballooning the saved CSS to 220KB. Selectors within each rule and the full set of emitted rules are now deduplicated (exact-string, order-preserving), making the sanitiser idempotent — re-saving now reproduces the same output instead of growing it. Existing bloated saved CSS will collapse back to its correct minimal form on the next save

1.9.11

• Fixed critical bug in custom CSS sanitiser (cookr_scope_css): a CSS comment placed directly above a rule (e.g. /* Buttons */ followed by .cookr-btn { ... }) caused the comment text to be parsed as part of the selector, failing the #cookr-/.cookr-/:root prefix check and silently dropping the entire rule with no error shown to the admin
• CSS comments are now stripped before selector parsing — fixes silent loss of :root accent overrides and any commented/sectioned custom CSS

1.9.10

• Added font detection for classic themes that load fonts via enqueued stylesheets (e.g. Kadence default installs) — previously only customizer-saved typography and block-theme theme.json fonts were detected
• New detection path parses Google Fonts and Bunny Fonts family names from registered stylesheets on the frontend, cached in a 6-hour transient, invalidated on theme switch
• Confirmed Update URI header (added in 1.9.9) correctly prevents WordPress.org from offering false update notices on RADR installs

1.9.9

• Fixed banner close behaviour — added state-aware close button always visible in banner
• Fixed Escape key — now follows same state-aware dismiss logic as close button
• No consent overwrite when closing with stored consent and no unsaved changes
• Prompts before discarding unsaved preference changes (native confirm dialog)

1.9.8

• Fixed LiteSpeed Cache JS Combine compatibility — cookrConfig inline block now isolated to a dedicated script handle, preventing third-party inline errors from aborting COOKR initialisation
• Added automatic JS exclusion filters for LiteSpeed Cache, WP Rocket, Autoptimize, and FlyingPress — COOKR registers itself as excluded from JS combination pipelines automatically
• Updated compatibility matrix schema — added protocol, protocol_version, test_payload, verification_method, special_checks fields across all entries
• Recorded first VERIFIED enforcement baseline: WordPress Core, Protocol v1.0, all six test cases passed
• Recorded LiteSpeed Cache JS Combine finding: FAIL without exclusion, PASS with automatic exclusion

1.9.7

• Fixed PHP notice in auto-blocker iframe rewrite handling
• Fixed blocked-status reporting for detected domains
• Fixed consent log rate-limit bypass edge case
• Fixed missing policy_version storage in consent records
• Fixed remote signature update setting persistence
• Fixed language switcher save-state detection
• Added full-consent buffer shortcut optimization

1.9.6

• Compliance improvements for WP.org review
• Removed generic CDN entries from auto-blocker allowlist
• Export uses explicit allowlist for safe settings only
• Build tooling improvements

1.9.5

• WordPress.org review and compliance-related improvements
• Internal maintenance and review-related updates

1.9.2

• Initial public CORE release
• 3×3 visual position picker replaces dropdown
• Accent colour now applies to banner icon and buttons in preview
• Auto-Blocker wording updated — recommended framing, test-after-enable guidance
• Runtime Inspector enabled by default
• Preserve data on uninstall enabled by default
• Consent log default retention reduced to 100 entries
• COOKR CRAZE built-in CSS preset

1.8.2

• Added: Runtime Inspector — detects unknown third-party script and iframe domains at runtime
• Added: Persistent findings stored per domain (first seen, last seen, page count)
• Added: Runtime Inspector toggle with configurable auto-disable duration

1.2.0

• Added: Google Consent Mode v2
• Added: debug inspector
• Added: browser chrome preview in admin dashboard

1.1.0

• Plugin renamed from GDPR Cookie Consent to COOKR
• Added: WP_HTML_Tag_Processor for safe, attribute-aware script rewriting
• Added: CSP nonce propagation

1.0.0

• Initial release