# Consent Is a Gate Not a Notice ## Claim A consent affordance that doesn't block the action it describes is documentation of what already happened, not consent to let it happen. <!-- atomicity: 1 idea ✓ --> ## Scope & conditions - Holds wherever the user-facing artifact — a checkbox, a Terms & Conditions box, a banner — renders alongside or after the action it's meant to authorize, rather than gating the action until the user affirmatively responds. - Does not hold where the action is genuinely reversible at no cost and the notice is immediate: a post-action toast with a working one-click undo is a defensible consent mechanism, because the user retains real control after the fact. - Breaks down as a bright line at the edges — a very short, unmissable delay between notice and action isn't automatically a violation, but a non-expiring, non-revocable-by-the-user credential created before any affordance renders clearly fails the test. - The distinction is enforceable in a way that arguing over loaded labels ("backdoor," "spyware") is not: a gate either blocks until response or it doesn't, and that's checkable in the code. ## Evidence > [!quote] ID:rw_rankmath_h2 > "There is a 'Terms & Conditions' box, but it does not stop the password from being created or sent." Rank Math 1.0.277 shipped a Support Agent that, per developer Sybre Waaijer, creates a WordPress Application Password inheriting the opening administrator's role and transmits it to group.one's servers the moment an admin connected to a rankmath.com account opens Help & Support — with the T&C box present but non-blocking, and the transfer reportedly beginning before the box renders. WordPress.org's own Guideline 7 requires "explicit and authorized consent" for external server contact, naming an opt-in checkbox as the expected mechanism — which is a gate, not a notice. The distinction between an affordance and a gate is what turns a contested "is this a backdoor" argument into an enforceable Guideline 7 question nobody has to agree on a label to act on. ## Links - [[3. Resources/Permanent Notes/Consent Gating Must Be Verified Not Assumed]] — because extends; that note makes the parallel point for cookie-consent banners on the front end (a banner that displays but doesn't enforce the gate is functionally the same as having none) — same mechanism, different surface. - [[3. Resources/Permanent Notes/Agents in Plugins Have a Trust Direction Toward the Product or the User]] — because applies-in; this is the specific failure mode that occurs when a vendor chooses the "agent inside the product" trust direction without building the gate that direction requires. - [[3. Resources/MOCs/WordPress Hosting Security Stack MOC]] — because applies-in; a checkable audit criterion for any plugin requesting elevated access — does the consent affordance block, or only inform. - [[3. Resources/MOCs/WordPress Platform Design MOC]] — applies-in: the MOC lists this note under Synthesis additions. ## Tests / falsifiers - Grep any plugin under review for calls to `wp_create_application_password()` or similar credential-creation functions and trace whether a blocking UI step precedes the call in every code path. A gate that can be bypassed by any path is not a gate. - Find a case where WordPress.org's Plugin Review team ruled that a non-blocking affordance satisfied Guideline 7's "explicit and authorized consent" — if such a ruling exists, the claim as an enforcement standard needs revision, though the underlying distinction would still hold as a design principle. ## Source - [[3. Resources/Readwise/Articles/Rank Math WordPress Plugin Accused of Secretly Taking Admin Access]] — Roger Montti, Search Engine Journal, 2026-08-30. The sole technical source is a competing plugin developer; the mechanism is independently checkable in the plugin's source (`vendor/groupone/wap-client/includes/class-app-password-manager.php`) and is not disputed — the contested part is only the "backdoor" label, which this note deliberately avoids relying on.