- DontFuckWithPaste ist eine Google-Chrome-Erweiterung, die das Blockieren von Kopieren und Einfügen in Eingabefeldern durch Webanwendungen aufhebt
- Das Projekt geht davon aus, dass Nutzer eher zu Fehleingaben neigen, wenn sie Werte wie E-Mail-Adressen oder Daten aus Tools wie 1Password direkt eintippen müssen
- Nutzer können durch Klick auf das Erweiterungssymbol eine Website zur Blacklist hinzufügen, das automatisch erzeugte Muster bei Bedarf anpassen und dann speichern
- Wenn die Erweiterung im aktuellen Tab aktiv ist, wird das Symbol blau, sodass sich der Aktiv-/Inaktiv-Status pro Tab erkennen lässt
- Version 2 verwendet die Berechtigung
tabs, damit die Erweiterung nur auf problematischen Websites ausgeführt wird; Chromes Berechtigungsbeschreibung kann dabei weiter gefasst und beängstigender wirken als das tatsächliche Verhalten
Chrome-Erweiterung zum Entfernen von Kopier-/Einfüge-Sperren
- DontFuckWithPaste ist eine Google-Chrome-Erweiterung, die das Blockieren von Kopieren und Einfügen durch Webanwendungen aufhebt
- Für das versehentliche Einfügen einer falschen E-Mail-Adresse ist der Nutzer selbst verantwortlich; das Kopieren und Einfügen von Werten aus Tools wie 1Password kann weniger fehleranfällig sein, als jedes Zeichen manuell einzugeben
- Ziel der Erweiterung ist es, die Einschränkungen von Websites, die Kopier-/Einfüge-Ereignisse blockieren, unkompliziert zu entfernen
Verwendung
- Der einfachste Weg, eine Website zur Blacklist hinzuzufügen, ist ein Klick auf das Erweiterungssymbol
- Danach kann das automatisch erzeugte Muster bei Bedarf angepasst und anschließend
"Save"geklickt werden - Nach dem Speichern wird das Erweiterungssymbol blau angezeigt, wenn die Erweiterung im aktuellen Tab aktiv ist
Änderungen und Berechtigungen in Version 2
- Version 2 ist ein größeres Update der Erweiterung und macht es einfacher, sie nur auf Websites auszuführen, die Kopier-/Einfüge-Ereignisse falsch behandeln
- Außerdem bietet sie Sichtbarkeit darüber, ob die Erweiterung pro Tab aktiviert oder deaktiviert ist
- Um zu erkennen, wann sich der aktive Tab ändert, ist die Berechtigung
tabserforderlich- Chrome beschreibt diese Berechtigung als
"can read and change all your data on websites you visit" - Laut README wirkt diese Beschreibung beängstigend, entspricht aber nicht der tatsächlichen Funktionsweise der Erweiterung
- Chrome beschreibt diese Berechtigung als
- Da es sich um ein Open-Source-Projekt handelt, können Nutzer den Code lesen und prüfen, wie die Erweiterung funktioniert und was sie mit Nutzerdaten gerade nicht tut
- Weitere Informationen zum Upgrade auf Version 2 finden sich auf der wiki page
1 Kommentare
Meinungen auf Hacker News
Wenn man Benutzereingaben blockiert, verschlechtert das eher die Anwendungssicherheit. Wenn Passwörter nicht kopiert werden können, wechseln selbst Nutzer, die anfangs gute Passwörter verwenden, wegen des Tippaufwands zu weniger komplexen Passwörtern.
Wenn man komplexe Eingaben erzwingt und die Nutzer dann korrekt generierte Werte nicht einfügen lässt, ruiniert man auch die User Experience.
Auch Systeme, die bestimmte Zeichen zwingend verlangen, sind problematisch. Statt Regeln wie „muss Großbuchstaben, Zahlen und Sonderzeichen enthalten“ bevorzuge ich längere Passwörter, selbst wenn sie nur aus gewöhnlichen Zeichen bestehen. Denn falls man sie doch einmal manuell eintippen muss, ist das einfacher.
Noch schlimmer ist es, wenn sogar die erlaubten Sonderzeichen eingeschränkt werden. Dann muss man ein bereits generiertes Passwort erneut bearbeiten, nur um bestimmte Zeichen zu entfernen.
Wäre es wirklich so schwer, stattdessen die Passwortstärke anzuzeigen und Hinweise zu geben wie „Verwenden Sie mehr Zeichen, zum Beispiel vier Wörter“?
Nutzer verwenden die Sonderregeln dieser Oberfläche wahrscheinlich nicht oft genug, um sie sich zu merken, und werden am Ende zuerst versuchen, sie per Zwischenablage zu kopieren.
Ich stimme im Allgemeinen zu, dass man Nutzer die Funktionen verwenden lassen sollte, die sie gewohnt sind. Aber wer sich angewöhnt, Zugangsdaten zu kopieren und einzufügen, wird anfälliger für Phishing.
Die integrierten Passwortmanager von Firefox und Chrome tragen Zugangsdaten nicht versehentlich auf ähnlich aussehenden Websites ein, Nutzer aber durchaus.
Das Problem ist, dass es dafür kein alternatives Berechtigungsmodell gibt. Ich habe ein paar Erweiterungen benutzt, und oft können sie ohne vollständigen Lese-/Schreibzugriff auf alle Seiten gar nichts tun.
Zum Beispiel gibt es eine Erweiterung, mit der man ein Bild per Rechtsklick um -90/+90/180 Grad drehen kann. Eigentlich möchte man nur, dass der Browser einen informiert, wenn es ein Image-Tag gibt, aber so eine Option existiert nicht.
Am Ende muss man entweder eine seitenbezogene Allowlist in den Code einbauen, die Nutzer für jede Seite eine Allowlist erstellen lassen oder vollständige Lese-/Schreibrechte für jede vom Nutzer besuchte Webseite anfordern.
Der Autor legt so transparent wie möglich offen, welche Berechtigungen nötig sind und warum; und die Gründe liegen an Faktoren, die der Autor nicht kontrollieren kann. Die Reaktion wirkt ziemlich zynisch.
Technisch stimmt es. Später könnte alles Mögliche passieren.
Trotzdem ist so eine Haltung eher anerkennenswert als kritikwürdig.
Ich weiß nicht, warum der Originalbeitrag statt des Originals einen Fork verlinkt hat. Im Original gibt es eine Bookmarklet-Version, die man als Alternative verwenden kann.
https://github.com/jswanner/DontF-WithPaste?tab=readme-ov-fi...
Man kann das Problem vermeiden, indem man den Quellcode der Erweiterung herunterlädt und in Chromes Entwicklermodus für Erweiterungen „Entpackte Erweiterung laden“ verwendet. Dann kann man sicher sein, dass sich die Erweiterung nicht heimlich ändert.
Allerdings gebe ich dieser Erweiterung keine Berechtigung für alle Websites, sondern aktiviere sie nur siteweise.
Deshalb verwende ich für Installation und Updates von Browser-Erweiterungen einen System-Paketmanager.
Wenn die benötigte Browser-Erweiterung nicht im Paket-Repository vorhanden ist, trage ich selbst ein Paket bei und übernehme die Verantwortung für fortlaufende Prüfung und Wartung.
Um dieses Problem zu umgehen, füge ich auf dem Mac normalerweise Text in ein Feld wie das URL-Feld ein und ziehe ihn dann per Drag-and-drop dorthin.
Aber das Blockieren von Einfügen im Namen der Sicherheit ist fast das Dümmste überhaupt, gleich nach übertrieben kurzen Zeitlimits überall.
Ich wünschte, man könnte die Leute, die solche Entscheidungen treffen, einmal direkt treffen.
Ich wurde einmal gezwungen, auf einer Website, die kaum sensible Daten enthalten dürfte, eine automatische Abmeldung nach 30 Minuten zu implementieren. Der Grund war, dass ein externer Penetrationstest-Anbieter das Fehlen eines kurzen Zeitlimits als Problem markiert hatte.
Um dem Kunden ein bestandenes Penetrationstest-Ergebnis zeigen zu können, mussten wir allen Feststellungen folgen. Alle wussten, dass es eine dumme Anforderung war, aber das Management ließ keine andere Option als die Implementierung.
Das war ein dummer Ablauf, den ich vor Kurzem bei login.gov erlebt habe. Der Passwortmanager hatte ein gespeichertes Login; ich erinnerte mich nicht daran, aber es funktionierte. Danach verlangte die Website einen Code aus einer Authenticator-App, aber in meinen Authenticator-Apps gab es keinen Eintrag für login.gov.
Ich klickte auf „Auf andere Weise anmelden“, aber diese andere Methode war ebenfalls die Verwendung einer Authenticator-App. Als ich auf „Keinen Code erhalten?“ klickte, hieß es, ich müsse das Konto löschen.
Als ich auf Konto löschen klickte, wurde eine E-Mail verschickt, und in der E-Mail stand, ich solle 24 Stunden warten, bis ich eine weitere E-Mail zur Kontolöschung erhalte. Nach 24 Stunden erhielt ich eine E-Mail, mit der ich das Konto löschen konnte.
Ich weiß nicht, was in diesem Konto war. Gemessen am Verwendungszweck des Logins könnte es sensibel sein; aber wenn es so sensibel und wichtig ist, warum ist dann die destruktivste Aktion, nämlich das Löschen des Kontos, möglich? Warum kann man nur per E-Mail löschen, aber keinen Authentifizierungscode erhalten?
Nicht einmal MS Remote Desktop erlaubt Einfügen.
Wofür glauben sie eigentlich, dass Passwortmanager existieren?
Auf dem Mac verwende ich Hammerspoon und habe Cmd+Shift+V so eingerichtet, dass statt Einfügen die tatsächlichen Zeichen getippt werden. Es funktioniert immer, wenn jemand so etwas macht.
hs.hotkey.bind({"cmd", "shift"}, "V", function() hs.eventtap.keyStrokes(hs.pasteboard.getContents()) end)Keyboard Maestro ist ebenfalls eine hervorragende App für solche Aufgaben und fügt zwischen Tastendrücken auch passende Verzögerungen ein, um Fehlverhalten zu vermeiden. Grob etwa 0,05 Sekunden.
Unter Windows erledige ich dasselbe mit AHK und nutze auch dieselben Tastenkürzel. Allerdings füge ich zwischen den einzelnen Tastendrücken kleine Verzögerungen von etwa 10–50 ms ein. Sonst kann die Eingabe gelegentlich kaputtgehen.
Ich habe das auch hinzugefügt, aber Cmd+Shift+V ist nach meinem Verständnis „Einfügen ohne Formatierung“, daher verwende ich statt Shift die Option-Taste.
-- https://news.ycombinator.com/item?id=39640745hs.hotkey.bind({"cmd", "alt"}, "V", function()hs.eventtap.keyStrokes(hs.pasteboard.getContents())end)Dieser Ansatz behebt auch das übertriebene Abfangen von Eingaben in Google Sheets.
Man sollte für so etwas keinem Add-on vertrauen müssen; es sollte im Browser konfigurierbar sein.
In Firefox kann man
dom.event.clipboardevents.enabledumschalten.Es wäre schön, wenn man nur das „Einfügen“-Event selektiv abschalten könnte. In Arbeits-Tools sind Buttons wie „Klicken, um diesen Wert zu kopieren“ sehr nützlich, aber es ist schade, diese Funktion jedes Mal zu verlieren, wenn man Clipboard-Events deaktiviert, um bösartige Websites zu vermeiden.
Gefühlt macht diese Einstellung in manchen Web-Apps die Einfügefunktion kaputt. Beispiele wären bestimmte Terminal-Emulatoren oder Texteditoren.
Wenn man beim Rechtsklick Shift gedrückt hält, kann man das Menü auch erzwingen.
Früher hat diese Einstellung Kopieren/Einfügen in Google Docs kaputtgemacht. Ich habe es eine Weile nicht ausprobiert; vielleicht ist es inzwischen behoben.
Ich mag es auch nicht, wenn Websites Einfügen blockieren, daher begrüße ich diese Erweiterung. Besonders bei Dingen wie der Bestätigung von Kontonummern, Routing-Nummern oder E-Mail-Adressen; außerdem macht es Passwortmanager kaputt. Wenn man komplexe Passwortregeln implementiert, angeblich um schwache Passwörter zu verhindern, und dann Einfügen blockiert, ist das natürlich nervig.
Allerdings habe ich solche Sicherheitsmaßnahmen auch schon selbst direkt in Webanwendungen implementiert. Ich bekam die Anforderung, setzte sie um und fragte den Kunden, warum wir das tun sollten, obwohl „alle“ wissen, dass es schlecht für die User Experience ist und der Sicherheit stark entgegenwirkt.
Die Antwort war Compliance. Man musste ein Security-Audit bestehen und großen Kunden oder Versicherern nachweisen, dass man branchenübliche Sicherheitsmaßnahmen hat.
Leider interessiert sich eine Bank nicht für die 2 %, die einen Passwortmanager verwenden. Der Rest merkt sich Passwörter immer noch, vergisst sie und macht Witze darüber wie im Jahr 2003.
Es heißt zwar „wir müssen das wegen Compliance machen“, aber stimmt das wirklich?
Ich habe noch keine Compliance-Anforderung gesehen, der man vernünftigerweise nicht widersprechen könnte. Es ist nur das Ergebnis aus übermäßig eifrigen Compliance-Beratern und Teams, denen Nutzer nicht besonders wichtig sind. Die Leute hinterfragen nichts ordentlich.
Unser PCI-Compliance-Audit hat beanstandet, dass wir Autocomplete in den Feldern des Login-Formulars nicht deaktiviert hatten. Das ist nicht dasselbe wie das Deaktivieren von Einfügen, geht aber in diese Richtung.
Persönlich gebe ich Websites, die mich meinen Passwortmanager (Bitwarden) nicht verwenden lassen, einfach auf.
Wenn Workarounds gegen Einfüge-Blockaden zu weit verbreitet werden, werden dieselben Websites am Ende virtuelle Tastaturen implementieren.
Wenn das für Touchscreen-Nutzer zu einfach ist, kommt als Nächstes vielleicht eine virtuelle Maus, die auf die virtuelle Tastatur klickt. Zur Unterscheidung von Mensch und Computer könnte man dann auch noch die Mausbeschleunigung zufällig verändern.
Eine alternative Bookmarklet-Lösung, die früher hier gepostet wurde:
[1]: https://bookmarkl.ink/ashtonmeuser/6e3869d8e468e016f22a4b4de...
Wenn Einfügen nicht funktioniert, mache ich normalerweise Rechtsklick → Element untersuchen und schreibe dann in die Konsole
$0.value="value from clipboard". Das funktioniert fast überall.An Einfügen herumzupfuschen ist ähnlich wie Autocomplete abzuschalten, und der HTML5-Standard sagt ziemlich klar, wann man es überhaupt abschalten sollte: „bei besonders sensiblen Werten (z. B. Aktivierungscodes für Atomwaffen) oder Werten, die niemals wiederverwendet werden (z. B. Einmalschlüssel für Bank-Logins)“.
Mir fällt nur der Fall ein, dass Malware den Clipboard-Wert ändert und Nutzer dazu bringt, einen falschen Wert einzufügen. Aber wenn man dieses Szenario aufmacht, gibt es unzählige Möglichkeiten, wie Malware auch mit Feldern für manuelle Eingabe herumspielen kann.
Ctrl-F abzufangen ist auf derselben Ebene.
Tastenkürzel, die im Browser eine Bedeutung haben, haben in anderen Anwendungen oft eine völlig andere Bedeutung. Da solche Anwendungen immer häufiger zu Web-Apps werden, kann es zu Shortcut-Konflikten kommen.
Nehmen wir Google Docs als Beispiel: Wenn man in einem Dokument oder einer Tabelle Ctrl-F drückt, will man dann die Browser-Suche oder die Suche der App selbst? Die meisten Nutzer wollen die Suche der App. Beim Lesen einer Nachrichtenseite erwarten die meisten dagegen die Browser-Suche.
Das heißt: Zu strengen Regeln gibt es immer Ausnahmen. Beim Kopieren/Einfügen-Problem des Originaltexts gibt es allerdings keine Ausnahme. Manipuliert nicht mein Clipboard für Marketing- oder Tracking-Unsinn.
Es gibt auch halbwegs legitime Fälle, die sich rechtfertigen lassen. Wenn man zum Beispiel eine Notion-Datenbank ansieht, ist das Standard-Ctrl-F nahezu nutzlos; die Dokumentensuche muss Ergebnisse über die Notion API holen und manchmal auch Ergebnisse finden, die mit den auf dem Bildschirm angezeigten Einträgen zusammenhängen.
„Halbwegs“ sage ich, weil ich mir eigentlich wünschen würde, dass es auf ein anderes Tastenkürzel gelegt wäre. Trotzdem verstehe ich die Argumentation, dass Nutzer ein Remapping wollen könnten.
Letztlich ergibt sich das aus der Entscheidung für diese Art der Dokumentverarbeitung. An der Grenze zwischen Online-Anwendung und Webseite wird daraus eine komplizierte Debatte.
Kürzlich habe ich festgestellt, dass nach dem Abfangen durch die Seite ein weiteres Drücken von Ctrl-F das Browser-Suchfeld öffnet.
Ich weiß nicht mehr, welche Website es war, aber im abgefangenen Suchfeld gab es einen Tooltip, der darauf hinwies. Ich war neugierig, ob es auch bei der Redocly-Suche funktioniert, und habe es ausprobiert; es gab keinen Tooltip, aber es funktionierte.
Ich bin mir nicht sicher, ob das allgemein funktioniert oder ob es eine undokumentierte Funktion der Redocly-Oberfläche ist und dort nicht funktioniert, wo Entwickler nicht eigens darauf Rücksicht genommen haben.
Die Umgebung war Chrome + OSX oder Windows.
Ich verstehe nicht, warum Browser Websites erlauben, ihre eigenen Tastenkürzel zu überschreiben. Damit das richtig funktioniert, hätte es vermutlich sogar zusätzlichen Code gebraucht.
Linear fängt zum Beispiel Cmd+F ab und bietet statt der eingebauten Browsersuche, die überall gleich funktioniert, irgendetwas Minderwertiges an. Das ist dasselbe Linear, das offenbar meint, man könne unmöglich keine WYSIWYG-Markdown-Bearbeitung wollen.
Ich kann kaum glauben, dass man im Jahr 2024 Dokumentation immer noch nicht einfach grepen kann.
Hat noch jemand bemerkt, dass der Originalbeitrag einen Fork geteilt hat, der gegenüber dem ursprünglichen Repository keine nennenswerten Verbesserungen hat, und dafür 399 Upvotes bekommen hat?
Der Autor des ursprünglichen Repositorys hat einen PR für Firefox-Unterstützung abgelehnt, also hat der Besitzer des Forks geforkt, um 6 Zeilen im Manifest hinzuzufügen.
https://github.com/jswanner/DontF-WithPaste/pull/29
Allerdings gebe ich zu, dass die irrelevante Änderung an
.gitignoreim ursprünglichen PR keinen Platz hatte.Das ist für Firefox, das andere für Chrome; insofern könnte es durchaus ein ziemlich sinnvolles Upgrade sein.
Ich vermute, die Upvotes kamen eher aus Gründen wie „Ja, so etwas hasse ich auch“ als wegen „Danke für das nützliche Tool“.
Der Fork dient der Firefox-Unterstützung, und aus Sicht von jemandem, der Chrome gar nicht erst nutzt, ist das ein sinnvolles Upgrade. Das ursprüngliche Repository ist leicht zu finden, aber auf GitHub einen bestimmten Fork zu finden, ist deutlich mühsamer.
Wenn dich das so stört, behalte ich es nächstes Mal eben für mich. Dann gibt es keinen Grund, anderen auf HN etwas mitzuteilen, das sie interessant finden könnten.
Stimmt. Im Vergleich zum Parent-Repository wurden 3 Dateien geändert, und die Änderungen sind nur
.gitignoresowie URLs, die auf das Fork-Repository aktualisiert wurden.