Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

Rule proposal: form-prefill-sanitize — extend checkout-checkbox-sanitize to text/email/select prefills

Abierto
  • ¿Algo no está bien?
#121 1 comentario 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 3 días

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
5/5
Tiempo estimado
Más de una semana
Aptitud para principiantes
38/100
Tipo de issue
Nueva funcionalidad
Claridad
Bastante claro
Estado de actividad
Tranquilo
Stack tecnológico
typescript
Área
frontend, security

Línea de trabajo

Start by reading the existing checkout-checkbox-sanitize and cart-addon-annotate rules and reuse their checkout URL gate. Define the new rule around DOMContentLoaded, the listed control types, hidden-input allowlist and denylist, focus checks, select field restrictions, and host kill-switch; done means covered behavior is tested without touching protected fields or non-checkout forms.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

enhancement rule-proposal
Category

New defense rule (extension of the checkout-checkbox-sanitize family)

What problem does this solve?

checkout-checkbox-sanitize clears pre-checked checkboxes on checkout pages so the agent doesn't inherit silent opt-ins. The same dark pattern — Mathur et al.'s Preselection — exists for non-checkbox inputs:

  • Pre-populated <select> defaults that pick the costliest shipping speed
  • Pre-filled hidden inputs carrying affiliate / referral / promo IDs that bias pricing or attribution
  • Pre-filled email/phone fields nudging the user toward marketing signup
  • Pre-selected radio defaults on tipping prompts ("18% / 20% / 22% / Custom" with 22% pre-checked)

The agent is then expected to re-select what it actually wants, same contract as the existing checkbox rule.

Proposed solution

On the same checkout-shaped URL gate, walk form controls and:

  • Clear pre-populated <input type="text|email|tel|number"> values when the page state suggests pre-fill (value present without user input — detectable on initial DOM).
  • Reset <select> to its first option (or a blank option if one exists) when the default differs from the natural-first choice.
  • Reset <input type="radio"> groups to unchecked when a default is server-supplied.
  • Clear value on <input type="hidden"> whose name matches a curated affiliate/referral/promo pattern (*aff*, *ref*, *promo*, *utm_*, coupon_id, discount_code) — but only on payment/order pages.

Out of scope for v1: role="textbox" / contenteditable widgets, complex date pickers, anything inside a payment-processor iframe.

Alternatives considered
  • Bundle into checkout-checkbox-sanitize instead of a new rule. Reasonable; the toggle becomes a bigger hammer. Splitting keeps user control finer-grained because text-field clearing has higher FP risk than checkbox clearing.
  • Synthetic blur/change event after clearing. Some sites recalc totals on input events; consider v2 if sites silently re-prefill on input without it.
Controlling false positives
  • Strict URL gate. Payment/order paths only (/cart, /checkout, /basket, /bag, /payment, /order) — never login or arbitrary forms. Reuse the exact gate of cart-addon-annotate and checkout-checkbox-sanitize so the surface is identical to a rule that's already in production.
  • Hard denylist for safety-critical hidden inputs. Never clear <input type="hidden"> whose name matches CSRF/cart/session shapes: _csrf, csrf_token, authenticity_token, cart_id, order_id, session*, nonce, state, _token, anything containing signature. Failure mode here is the form silently rejecting submit, which is worse than the original dark pattern.
  • Allowlist for hidden-input clearing. Only clear hidden inputs whose name matches the affiliate/promo pattern set above. Anything outside the allowlist is preserved.
  • <select>: only reset when the default value is NOT the first option. If the first option is selected (natural default — common pattern is <option value="">Select…</option> or <option>Standard shipping</option> first), the rule does nothing. Avoids clobbering legitimate first-option defaults.
  • Timing. Run on DOMContentLoaded, before browser autofill. Browser autofill that runs after the rule is preserved — meaning the user's password manager and saved addresses still work for inputs the rule has already cleared. Document the ordering explicitly so the contract is clear.
  • Geofencing-aware select defaults. Country/state preselection based on geo is usually legitimate. Mitigation: only reset <select> when the default deviates from the first option AND the field name is in a sneaking-prone set (shipping speed, tip percent, delivery slot, donation amount, insurance plan). Don't touch country/state/region selects.
  • Per-host kill-switch. Loyalty-program checkouts where saved details reappear by design (Amazon 1-Click, Apple Pay flows) can be denylisted by host. These flows are the user's intent.
  • No-op on inputs the user has actually focused. If document.activeElement or :focus-visible matched a field at any point, skip clearing it on rescan.
  • Graceful-failure mode. The worst user-facing outcome is "I need to retype" — recoverable. Document this so a user can clearly attribute the friction to the rule and toggle it off.
Prior art / references
  • Mathur et al. (CSCW 2019), Dark Patterns at Scale. — Preselection category; already cited.
  • Brignull, deceptive.design — Preselection.
  • WHATWG HTML autocomplete attribute spec — informs which fields are legitimate autofill targets vs. server-pushed prefills.
  • Adjacent OSS: Consent-O-Matic sets values to opt out on consent forms — same mechanic, different intent.

Tagged Impact L–M / Complexity M.

Lenguaje dominante
TypeScript
Estrellas
35
Forks
4
Merge medio
3 d 7 h
PR fusionados (30 d)
30

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de pixiebrix/agent-browser-shield

Todos los issues de pixiebrix/agent-browser-shield

Issues similares

Más issues de TypeScript

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.