Paste技術をむやみに扱わないでください
(github.com/aaronraimist)- DontFuckWithPasteは、Webアプリケーションが入力フィールドでコピー＆ペーストを妨げる動作を取り除く Google Chrome 拡張機能
- このプロジェクトは、メールアドレスや 1Password などのツールの値を手入力させるやり方は、かえって入力ミスの可能性を高めると考えている
- ユーザーは拡張アイコンを押してサイトをブラックリストに追加し、自動生成されたパターンを必要に応じて修正して保存できる
- 拡張機能が現在のタブで有効になると、アイコンが青色に変わり、タブごとの有効・無効状態を確認できる
- Version 2 では、問題のあるサイトでのみ拡張機能が動作するようにするため
tabs権限を使用しており、Chrome の権限説明は実際の動作より広く、怖く見えることがある
コピー＆ペーストのブロックを解除する Chrome 拡張機能
- DontFuckWithPaste は、Webアプリケーションがユーザーのコピー＆ペーストを妨げる動作を取り除く Google Chrome 拡張機能
- 入力フィールドにメールアドレスを誤って貼り付ける責任はユーザーにあり、1Password のようなツールから値をコピーして貼り付けるほうが、すべての文字を直接入力するよりエラーが少ない場合がある
- この拡張機能の目的は、コピー＆ペーストイベントをブロックする Web サイトの制限をシンプルに取り除くことにある
使い方
- サイトをブラックリストに追加する最も簡単な方法は、拡張アイコンをクリックすること
- その後、自動生成されたパターンを必要に応じて修正し、
"Save"を押せばよい - 保存後、拡張アイコンが青色で表示されていれば、現在のタブで拡張機能が有効になっている状態
Version 2 の変更点と権限
- Version 2 はこの拡張機能の主要アップデートであり、コピー＆ペーストイベントを不適切に扱うサイトでのみ拡張機能が動作するようにしやすくなった
- タブごとに拡張機能が有効か無効かを確認できる可視性も提供する
- アクティブタブが切り替わるタイミングを知るために
tabs権限が必要- Chrome はこの権限を
"can read and change all your data on websites you visit"と説明している - README では、この説明は怖く見えるものの、拡張機能が実際にそのように動作するわけではないと述べている
- Chrome はこの権限を
- オープンソースプロジェクトのため、ユーザーはコードを読んで、拡張機能がどのように動作し、ユーザーデータに対して何をしないのかを確認できる
- Version 2 へのアップグレードに関する追加情報は wiki page で確認できる
1件のコメント
Hacker News の意見
ユーザー入力を妨げると、かえってアプリケーションのセキュリティが悪化する。パスワードをコピーできなくなると、最初は良いパスワードを使っていたユーザーでも、入力の負担からより単純なパスワードに変えてしまう
複雑な入力を強制しておきながら、ユーザーが適切に生成した値を貼り付けられないようにすると、ユーザー体験も台無しになる
特定の文字を必ず使わせるシステムも問題だ。「大文字、数字、特殊文字を必ず含める」といったルールより、普通の文字だけでもより長いパスワードを生成するほうを好む。たまに手入力しなければならないときに、そのほうが簡単だからだ
さらに悪いのは、使える特殊文字の種類まで制限する場合だ。すでに生成したパスワードから特定の文字だけを削除するよう、再編集しなければならない
いっそパスワード強度を表示して、「もっと多くの文字を使ってください。たとえば4つの単語を使えます」のように案内するのは、そんなに難しいことなのかと思う
ユーザーはそのインターフェイス固有のルールを頻繁に使うわけではないので、覚えていない可能性が高く、結局まずクリップボードへのコピーを試すことになるだろう
ユーザーが慣れた機能を使えるようにすべきだという点にはおおむね同意するが、認証情報をコピー＆ペーストする習慣があると、フィッシングにより弱くなる
Firefox と Chrome の内蔵パスワード管理ツールは、見た目の似たサイトに誤って認証情報を入れることはないが、ユーザーは十分にそうしてしまい得る
これを行うための代替的な権限モデルがないのが問題だ。拡張機能をいくつか使ってみたが、全ページに対する完全な読み書きアクセスなしでは何もできないことが多い
たとえば、画像を右クリックして -90/+90/180 度回転する拡張機能がある。欲しいのは、画像タグがあるときにブラウザが知らせてくれることだけなのに、そういう選択肢はない
結局、コードにページごとの許可リストを埋め込むか、ユーザーにページごとに許可リストを作らせるか、ユーザーが訪れるすべてのウェブページへの完全な読み書き権限を要求するしかない
作者は必要な権限とその理由をできるだけ透明に説明しており、その理由も作者が制御できない要因によるものなのに、あまりに冷笑的な反応に見える
技術的には正しい。あとで何でもできる
それでも、こういう姿勢は批判するより評価してよいものだ
なぜ元記事がオリジナルではなくフォークにリンクしているのかは分からない。オリジナルには代替として使えるブックマークレット版がある
https://github.com/jswanner/DontF-WithPaste?tab=readme-ov-fi...
拡張機能のソースをダウンロードしたうえで、Chrome 拡張機能のデベロッパーモードで「パッケージ化されていない拡張機能を読み込む」を使えば、その問題は回避できる。そうすれば拡張機能がこっそり変更されないと確信できる
ただし、この拡張機能には全サイト権限を与えず、サイトごとにだけ有効にして使っている
だからブラウザ拡張機能のインストールと更新にはシステムのパッケージマネージャを使っている
パッケージリポジトリに必要なブラウザ拡張機能がなければ、自分でパッケージを提供し、継続的な検証と保守の責任を負う
この問題を回避するため、Mac ではたいてい URL フィールドのような場所に貼り付けたテキストをドラッグ＆ドロップする
しかし、セキュリティという名目で貼り付けを禁止するのは、どこでも過度に短いタイムアウト制限のすぐ手前に来るほど、最悪に愚かなことだ
こういう決定を下す人たちに直接会えるものなら会ってみたい
機密データがあるとは考えにくいウェブサイトに、30分の自動ログアウトを実装するよう強いられたことがある。外部の侵入テスト業者が、短いタイムアウトがない点を問題として指摘したためだ
顧客に合格した侵入テスト結果を見せるには、すべての発見事項に従うしかなかった。誰もが馬鹿げた要求だと分かっていたが、経営陣は実装以外の選択肢を与えなかった
少し前に login.gov で経験した愚かなフローだ。パスワードマネージャには保存済みのログインがあり、覚えてはいなかったが動作した。その後、サイトが認証アプリのコードを要求したが、認証アプリには login.gov の項目がなかった
「別の方法でログイン」ボタンを押したところ、その別の方法も認証アプリの使用だった。「コードを受け取れない場合は？」を押すと、アカウントを削除しなければならないと表示された
アカウント削除を押すとメールが送られ、そのメールには別のアカウント削除メールを受け取るまで24時間待つよう書かれていた。24時間後、アカウントを削除できるメールを受け取った
そのアカウントに何が入っていたのかは分からない。ログイン用途からすると機密性がありそうにも見えるが、そんなに機密で重要なら、なぜ最も破壊的なアカウント削除は可能なのか？ なぜメールだけで削除はできるのに、認証コードを受け取ることはできないのか？
MS Remote Desktop でさえ貼り付けを許可しない
パスワードマネージャは何のために存在すると思っているのか？
Mac で Hammerspoon を使い、Cmd+Shift+V のショートカットが貼り付けではなく実際の文字をタイプするよう設定している。誰かがこういうことをするたびに、いつも機能する
hs.hotkey.bind({"cmd", "shift"}, "V", function() hs.eventtap.keyStrokes(hs.pasteboard.getContents()) end)Keyboard Maestro もこうした作業に優れたアプリで、異常な動作を防ぐためにキー入力の間に適切な遅延も入れてくれます。だいたい 0.05 秒ほどです
Windows では AHK で同じことをしており、ショートカットキーも同じにしています。ただし各キー入力の間に 10〜50ms 程度の小さな遅延を入れています。そうしないと入力がたまに壊れることがあります
私も追加しましたが、Cmd+Shift+V は記憶では「書式なしで貼り付け」なので、shift の代わりに option を使っています
-- https://news.ycombinator.com/item?id=39640745hs.hotkey.bind({"cmd", "alt"}, "V", function()hs.eventtap.keyStrokes(hs.pasteboard.getContents())end)この方法は Google Sheets の過剰な 入力の横取り も解決してくれます
こういうことにアドオンを信頼しなければならない必要はなく、ブラウザ側で設定できるべきです
Firefox では
dom.event.clipboardevents.enabledを切り替えられます「貼り付け」イベントだけを選択的にオフにできるとよいです。業務ツールの「クリックしてこの値をコピー」のようなボタンは非常に便利なのに、悪意あるサイトを避けるためにクリップボードイベントをオフにするたびに、その機能が使えなくなるのは残念です
体感では、この設定は一部の Web アプリで 貼り付け機能 を壊します。たとえば特定のターミナルエミュレーターやテキストエディタです
右クリックするときに Shift を押していれば、メニューを強制的に開くこともできます
以前はこの設定が Google Docs のコピー／貼り付けを壊していました。しばらく試していないので、今は直っているかもしれません
私もサイトが貼り付けを妨げるのが嫌いなので、この拡張機能は歓迎です。口座番号・ルーティング番号やメールアドレス確認のような場所では特にそうですし、パスワードマネージャーも壊します。弱いパスワードを防ぐとして複雑なパスワードルールを実装しているのに貼り付けを禁止するのは、当然ながら苛立たしいものです
ただし、こうしたセキュリティ対策を Web アプリケーションに直接実装したこともあります。要件として受けて実装し、「誰もが」これがユーザー体験に悪く、セキュリティにも大きく逆効果だと分かっているのに、なぜやる必要があるのかと顧客に尋ねました
答えは コンプライアンス でした。セキュリティ監査に通り、大口顧客や保険会社に業界標準のセキュリティ対策を備えていると証明する必要があったからです
残念ながら銀行は、パスワードマネージャーを使う 2% を気にしません。残りの人たちは今でもパスワードを覚え、忘れ、2003 年のようにそれを笑い話にしています
「コンプライアンスのために必要だ」と言いますが、本当にそうでしょうか？
合理的に反論できないコンプライアンス要件を見た記憶はありません。過度に熱心なコンプライアンスコンサルタントと、ユーザーをあまり気にしないチームが出会った結果にすぎません。人々は何もきちんと問い詰めません
私たちの PCI コンプライアンス 監査では、ログインフォームのフィールドでオートコンプリートを無効にしていないと指摘されました。貼り付けの無効化と同じではありませんが、その方向に向かっています
個人的には、パスワードマネージャー（Bitwarden）を使えなくするサイトはそのまま諦めます
貼り付けブロックの回避策があまりに広まると、同じサイトは結局 仮想キーボード を実装するでしょう
タッチスクリーンユーザーにとってそれが簡単すぎるなら、次は仮想キーボードをクリックする仮想マウスかもしれません。人間とコンピュータを区別するとして、マウス加速度もランダムに変えられるでしょう
以前ここに投稿されていた代替の ブックマークレット です
[1]: https://bookmarkl.ink/ashtonmeuser/6e3869d8e468e016f22a4b4de...
貼り付けできないときは、たいてい右クリック → 要素を検証の後、コンソールに
$0.value="value from clipboard"と書きます。ほぼどこでも動きます貼り付けに手を出すのは自動入力をオフにするのと似ており、HTML5 標準はいつだけオフにすべきかをかなり明確に述べています: 「特に機密性の高い値（例: 核兵器の起動コード）か、絶対に再利用されない値（例: 銀行ログイン用のワンタイムキー）」
思いつくのは、マルウェアがクリップボードの値を書き換えて、ユーザーに間違った値を貼り付けさせるケースだけです。しかしそのシナリオを認めるなら、マルウェアが手入力フィールドにいたずらする方法もいくらでもあります
Ctrl-F の横取り も同じレベルです
ブラウザではある意味を持つショートカットが、別のアプリケーションではまったく別の意味を持つことがよくあります。そうしたアプリケーションが Web アプリになることが増えるにつれ、ショートカットの衝突が起こり得ます
Google Docs を例にすると、文書やスプレッドシートで Ctrl-F を押したとき、ブラウザの検索を望みますか、それともアプリ自体の検索を望みますか？ 大多数のユーザーはアプリの検索を望みます。ニュースサイトを読んでいるときは、ほとんどの場合ブラウザ検索を期待するでしょう
つまり、厳格なルールには常に例外があるということです。ただし元記事のコピー／貼り付け問題については例外はありません。マーケティングやトラッキングのくだらない目的で私のクリップボードを操作しないでください
正当化できる半合法的なケースもあります。たとえば Notion データベースを見るとき、標準の Ctrl-F はほとんど役に立たず、文書検索が Notion API 経由で結果を取得する必要があり、場合によっては画面に表示された項目に関連する結果も探す必要があります
「半」と言ったのは、実際には別のショートカットに割り当ててほしいからです。それでも、ユーザーが再割り当てを望むかもしれないという論理は理解できます
結局、そもそもそのような文書処理方式を選んだ判断に由来します。オンラインアプリケーションと Web ページの境界では、複雑な議論になります
最近、横取りされた後でも Ctrl-F をもう一度押すとブラウザの検索ボックスが出ることに気づきました
どのサイトだったかは覚えていませんが、横取りされた検索ボックスにこのことを知らせるツールチップがありました。Redocly の検索でもできるか気になって試したところ、ツールチップはありませんでしたが動きました
これが普遍的に動作するのか、それとも Redocly インターフェースの文書化されていない機能で、開発者が特に配慮していない場所では動かないのかは確信がありません
環境は Chrome + OSX または Windows でした
ブラウザが、なぜウェブサイトに独自ショートカットで上書きすることを許しているのか理解できない。きちんと動くようにするには、むしろ追加のコードが必要だったはずだと思う
たとえば Linear は Cmd+F を横取りして、どこでも同じように動くブラウザ内蔵検索の代わりに、ひどい何かを提供している。これは、WYSIWYG の Markdown 編集を望まないはずがないと思っている、あの Linear だ
2024年にもなって、ドキュメントをただ grep できないなんて信じられない
元記事が、元のリポジトリと比べて意味のある改善がないフォークを共有して、それが 399 upvote を得ていることに、ほかの人も気づいた？
元のリポジトリの作者が Firefox 対応の PR を拒否したので、フォークの所有者がマニフェストを6行追加するためにフォークしたものだ
https://github.com/jswanner/DontF-WithPaste/pull/29
ただし、関係のない
.gitignoreの変更が元の PR に入る理由はなかった、という点は認めるこれは Firefox 用で、もう一方は Chrome 用だから、もしかするとかなり意味のあるアップグレードかもしれない
upvote は「便利なツールをありがとう」というより、「そうそう、自分もああいうの嫌い」という理由でもらったものに近い気がする
フォークは Firefox 対応用で、そもそも Chrome を使っていない立場からすると意味のあるアップグレードだと思う。元のリポジトリは簡単に見つけられるが、GitHub で特定のフォークを探すのはずっと面倒だ
それがそんなに不快なら、次からは自分だけで知っておくことにする。HN のほかの人たちに興味深いものを知らせる理由はなさそうだ
その通り。親リポジトリと比べて変更されたファイルは3つで、変更内容は
.gitignoreと、フォーク先リポジトリに更新された URL だけだ