Don't fuck with paste

Core reaction to “don’t fuck with paste”

• Strong consensus that blocking paste is infuriating and user‑hostile.
• People especially resent it on login, signup, banking, gov, and 2FA forms, where it fights password managers, encourages weaker/memorable passwords, and forces users to expose passwords in plaintext or write them down.
• Many see it as security theater: it demonstrably worsens real-world security while satisfying checklists and auditors.

Purported reasons for blocking paste (and criticisms)

• Claimed motivations:
  • “Security” in vague terms, or to stop malware/clipboard attacks.
  • Prevent users from pasting the same typo into both “email” and “confirm email” fields.
  • Force users to carefully type a project name before destructive actions (e.g., deleting a repo).
• Critics argue:
  • These problems are better solved by autocomplete, good error messages, undo, or confirmation flows.
  • Blocking paste and imposing baroque password rules leads to predictable user workarounds and lower security.

Browser UX abuses beyond paste

• Many complaints about hijacking standard shortcuts: Ctrl/Cmd‑F, Ctrl‑K, right‑click, scrolling, or even redefining Ctrl‑V.
• Some note limited legitimate cases (virtualized lists, web apps like docs/IDEs), but still prefer a way to get native browser behavior on demand (e.g., pressing Ctrl‑F twice).
• Suggestion: browsers should expose robust “force” options (force copy/paste, select, right‑click, native search).

Workarounds and tools

• Browser extensions: the discussed extension, its original version, and alternatives like StopTheMadness, plus Safari/Orion/Brave features and Firefox about:config flags.
• Bookmarklets and user scripts are popular as lighter‑weight, auditable, on‑demand fixes.
• OS-level tools (Hammerspoon, AutoHotkey, Keyboard Maestro, “type clipboard” scripts) bypass web restrictions by simulating keystrokes.
• Cruder methods: disabling JavaScript, using devtools to set input values, dragging text from URL bar, middle‑click paste on Linux.

Extension security and permissions

• Debate over extensions requesting broad permissions (“read and change all data”).
• Concerns: auto‑updates, possible project sale or maintainer compromise.
• Mitigations: loading unpacked extensions, using package managers, or preferring bookmarklets.
• Some argue the real problem is coarse-grained browser permission models.

Naming and tone

• Mixed views on the profanity in the project name and thread.
• Some see it as fitting anger toward hostile UIs; others note it’s hard to recommend in professional or family contexts.