Don't fuck with paste

Web developers increasingly block copy‑paste, hijack keyboard shortcuts, or disable right‑click in the name of “security,” but many users see these measures as hostile, counterproductive, and often harmful to real security practices like using password managers. Commenters highlight tools such as browser extensions, bookmarklets, and system‑level scripts that restore normal clipboard behavior, while also noting the privacy risks of powerful extensions and arguing that browsers should offer built‑in controls for overriding sites. Much of the frustration is driven by compliance checklists and overzealous security policies that prioritize passing audits over usability and genuine protection.

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.