1 điểm bởi GN⁺ 2024-03-09 | 1 bình luận | Chia sẻ qua WhatsApp
  • DontFuckWithPaste là một tiện ích mở rộng của Google Chrome giúp gỡ bỏ hành vi các ứng dụng web chặn sao chép và dán trong các trường nhập liệu
  • Dự án cho rằng việc buộc người dùng tự nhập trực tiếp các giá trị như địa chỉ email hay dữ liệu từ những công cụ như 1Password lại làm tăng khả năng nhập sai
  • Người dùng có thể nhấn vào biểu tượng tiện ích để thêm trang vào danh sách chặn, chỉnh sửa mẫu được tạo tự động nếu cần rồi lưu lại
  • Khi tiện ích được kích hoạt trên tab hiện tại, biểu tượng sẽ chuyển sang màu xanh lam để có thể nhận biết trạng thái bật/tắt theo từng tab
  • Version 2 sử dụng quyền tabs để tiện ích chỉ chạy trên các trang có vấn đề, và phần mô tả quyền của Chrome có thể trông rộng hơn và đáng sợ hơn so với cách nó thực sự hoạt động

Tiện ích Chrome gỡ bỏ chặn sao chép·dán

  • DontFuckWithPaste là một tiện ích mở rộng của Google Chrome giúp gỡ bỏ hành vi các ứng dụng web chặn sao chép và dán của người dùng
  • Trách nhiệm nếu dán sai địa chỉ email trong trường nhập liệu thuộc về người dùng, và việc sao chép rồi dán giá trị từ những công cụ như 1Password có thể ít lỗi hơn so với tự gõ từng ký tự
  • Mục đích của tiện ích là đơn giản gỡ bỏ các hạn chế trên những website chặn các sự kiện sao chép·dán

Cách sử dụng

  • Cách dễ nhất để thêm một trang vào danh sách chặn là nhấp vào biểu tượng tiện ích
  • Sau đó có thể chỉnh sửa mẫu được tạo tự động nếu cần rồi nhấn "Save"
  • Sau khi lưu, nếu biểu tượng tiện ích hiển thị màu xanh lam thì tiện ích đang được kích hoạt trên tab hiện tại

Thay đổi và quyền trong Version 2

  • Version 2 là một bản cập nhật lớn của tiện ích, giúp dễ dàng hơn trong việc khiến tiện ích chỉ chạy trên những trang xử lý sai các sự kiện sao chép·dán
  • Nó cũng cung cấp khả năng hiển thị để biết tiện ích đang bật hay tắt theo từng tab
  • Cần quyền tabs để biết thời điểm tab đang hoạt động thay đổi
    • Chrome mô tả quyền này là "can read and change all your data on websites you visit"
    • README cho biết cách mô tả này nghe có vẻ đáng sợ, nhưng tiện ích thực tế không hoạt động theo kiểu đó
  • Vì là dự án mã nguồn mở, người dùng có thể đọc mã để kiểm tra tiện ích hoạt động như thế nào và nó không làm gì với dữ liệu người dùng
  • Có thể xem thêm thông tin về nâng cấp Version 2 tại wiki page

1 bình luận

 
GN⁺ 2024-03-09
Ý kiến trên Hacker News
  • Chặn đầu vào của người dùng thực ra lại làm bảo mật ứng dụng tệ hơn. Nếu không thể sao chép mật khẩu, ngay cả những người ban đầu dùng mật khẩu tốt cũng sẽ đổi sang mật khẩu kém phức tạp hơn vì ngại gõ
    Nếu đã ép nhập liệu phức tạp mà lại không cho người dùng dán giá trị họ đã tạo đúng cách, trải nghiệm người dùng cũng bị phá hỏng

    • Các hệ thống bắt buộc phải dùng một số ký tự nhất định cũng có vấn đề. Thay vì các quy tắc kiểu “bắt buộc có chữ hoa, số, ký tự đặc biệt”, tôi thích tạo mật khẩu dài hơn dù chỉ dùng các ký tự thông thường. Vì thỉnh thoảng khi phải gõ tay thì như vậy dễ hơn
      Tệ hơn nữa là trường hợp còn giới hạn cả những loại ký tự đặc biệt được phép dùng. Bạn phải sửa lại mật khẩu đã tạo sẵn chỉ để xóa một số ký tự nhất định
      Tôi tự hỏi liệu việc hiển thị độ mạnh mật khẩu rồi hướng dẫn kiểu “hãy dùng nhiều ký tự hơn, chẳng hạn có thể dùng bốn từ” có khó đến vậy không

    • Người dùng rất có thể không nhớ các quy tắc đặc biệt của giao diện đó vì họ không dùng thường xuyên, và cuối cùng trước tiên sẽ thử sao chép vào clipboard

    • Nhìn chung tôi đồng ý rằng nên để người dùng sử dụng các chức năng quen thuộc, nhưng nếu có thói quen sao chép và dán thông tin xác thực thì sẽ dễ bị phishing hơn
      Công cụ quản lý mật khẩu tích hợp của Firefox và Chrome sẽ không vô tình điền thông tin xác thực vào các trang giống giả mạo, nhưng người dùng thì hoàn toàn có thể làm vậy

  • Để mang lại trải nghiệm mượt mà nhất có thể, tiện ích mở rộng cần biết khi nào tab đang hoạt động thay đổi. Để biết sự kiện đó thì cần quyền tabs, và Chrome mô tả quyền này là “có thể đọc và thay đổi tất cả dữ liệu của bạn trên các trang web bạn truy cập”. Mô tả này nghe rất đáng sợ, nhưng đó tuyệt đối không phải là điều tiện ích mở rộng này thực sự làm. Vì đây là dự án mã nguồn mở, bạn luôn có thể đọc toàn bộ mã để kiểm tra tiện ích mở rộng này hoạt động ra sao và nó không làm gì với dữ liệu người dùng
    Vấn đề là dù bạn đã đọc mã, hoặc tin rằng ai đó đã đọc, cũng không có gì đảm bảo rằng các bản cập nhật trong tương lai vẫn sẽ như vậy. Lương tâm của tác giả có thể yếu đi theo thời gian, hoặc họ có thể bán tiện ích mở rộng
    Theo tôi biết, tiện ích mở rộng Chrome được tự động cập nhật, và ngay cả nếu không phải vậy, ta cũng cần nhớ rằng không nên giả định các bản cập nhật của tiện ích này là an toàn

    • Vấn đề là không có mô hình quyền thay thế để làm việc này. Tôi đã dùng thử vài tiện ích mở rộng, và nhiều trường hợp gần như không làm được gì nếu không có quyền đọc/ghi đầy đủ trên mọi trang
      Ví dụ có một tiện ích mở rộng cho phép nhấp chuột phải vào ảnh để xoay -90/+90/180 độ. Điều mong muốn chỉ là trình duyệt báo cho biết khi có thẻ ảnh, nhưng không có lựa chọn như vậy
      Cuối cùng hoặc phải nhúng danh sách cho phép theo từng trang vào mã, hoặc bắt người dùng tự tạo danh sách cho phép cho từng trang, hoặc yêu cầu quyền đọc/ghi đầy đủ trên mọi trang web người dùng truy cập

    • Tác giả đang minh bạch hết mức về những quyền cần thiết và lý do, mà lý do đó lại xuất phát từ yếu tố ngoài tầm kiểm soát của tác giả, nên phản ứng như vậy có vẻ quá hoài nghi
      Về mặt kỹ thuật thì đúng. Sau này họ có thể làm bất cứ thứ gì
      Nhưng thái độ như thế này đáng được ghi nhận hơn là chỉ trích

    • Không rõ vì sao bài gốc lại liên kết tới bản fork thay vì bản gốc. Bản gốc có phiên bản bookmarklet có thể dùng thay thế
      https://github.com/jswanner/DontF-WithPaste?tab=readme-ov-fi...

    • Có thể tránh vấn đề đó bằng cách tải mã nguồn tiện ích mở rộng xuống rồi dùng “Load unpacked extension” trong chế độ nhà phát triển của Chrome extension. Khi đó bạn có thể chắc chắn rằng tiện ích mở rộng không bị âm thầm thay đổi
      Tuy nhiên với tiện ích này, tôi không cấp quyền trên mọi trang, mà chỉ bật theo từng trang

    • Vì vậy tôi dùng trình quản lý gói hệ thống để cài đặt và cập nhật tiện ích mở rộng trình duyệt
      Nếu kho gói không có tiện ích trình duyệt cần thiết, tôi tự đóng góp gói và chịu trách nhiệm xác minh cũng như bảo trì liên tục

  • Để обход qua vấn đề này, trên Mac tôi thường kéo và thả văn bản đã dán vào một chỗ như ô URL
    Nhưng chặn dán dưới danh nghĩa bảo mật là một việc ngu ngốc tột độ, có thể xếp ngay trước các giới hạn thời gian quá ngắn ở bất kỳ đâu
    Giá mà tôi có thể gặp trực tiếp những người đưa ra các quyết định kiểu này

    • Tôi từng bị buộc phải triển khai tự động đăng xuất sau 30 phút cho một website khó có thể coi là chứa dữ liệu nhạy cảm. Lý do là một đơn vị kiểm thử xâm nhập bên ngoài đã đánh dấu việc không có giới hạn thời gian ngắn là vấn đề
      Muốn cho khách hàng thấy kết quả kiểm thử xâm nhập đã đạt, chúng tôi không còn cách nào ngoài làm theo mọi phát hiện. Ai cũng biết đó là yêu cầu ngớ ngẩn, nhưng ban lãnh đạo không cho lựa chọn nào ngoài triển khai

    • Đây là một luồng ngớ ngẩn tôi gặp trên login.gov cách đây không lâu. Trình quản lý mật khẩu có thông tin đăng nhập đã lưu, tôi không nhớ nhưng nó hoạt động. Sau đó trang yêu cầu mã từ ứng dụng xác thực, nhưng trong các ứng dụng xác thực không có mục login.gov
      Tôi bấm nút “đăng nhập bằng cách khác”, nhưng cách khác đó cũng là dùng ứng dụng xác thực. Bấm “nếu không nhận được mã thì sao?” thì nó nói phải xóa tài khoản
      Khi bấm xóa tài khoản, họ gửi email, và trong email lại nói phải chờ 24 giờ để nhận một email xóa tài khoản khác. Sau 24 giờ tôi nhận được email cho phép xóa tài khoản
      Tôi không biết trong tài khoản đó có gì. Xét mục đích đăng nhập thì có vẻ có thể nhạy cảm, nhưng nếu nhạy cảm và quan trọng đến vậy, tại sao lại cho phép hành động phá hủy nhất là xóa tài khoản? Tại sao chỉ bằng email thì xóa được, nhưng nhận mã xác thực thì không?

    • Ngay cả MS Remote Desktop cũng không cho phép dán
      Họ nghĩ trình quản lý mật khẩu tồn tại để làm gì?

  • Trên Mac tôi dùng Hammerspoon và thiết lập phím tắt Cmd+Shift+V để gõ các ký tự thực tế thay vì dán. Mỗi khi ai đó làm trò này, nó luôn hoạt động
    hs.hotkey.bind({"cmd", "shift"}, "V", function() hs.eventtap.keyStrokes(hs.pasteboard.getContents()) end)

    • Trên Windows tôi làm điều tương tự bằng AutoHotkey. Nó cũng hữu ích trong các trường hợp GUI kết nối từ xa mặc định dùng clipboard từ xa, hoặc trong các control của ứng dụng desktop legacy không hỗ trợ dán
  • Keyboard Maestro cũng là một ứng dụng rất tốt cho việc này, và còn chèn độ trễ phù hợp giữa các lần nhấn phím để tránh hành vi bất thường. Khoảng 0,05 giây

    • Trên Windows, tôi làm việc tương tự bằng AHK và dùng cùng phím tắt. Chỉ khác là tôi chèn một độ trễ nhỏ, khoảng 10–50ms, giữa mỗi lần nhấn phím. Nếu không, đôi khi đầu vào có thể bị lỗi

    • Tôi cũng đã thêm cách này, nhưng theo trí nhớ thì Cmd+Shift+V là “dán không kèm định dạng”, nên tôi dùng option thay vì shift
      -- https://news.ycombinator.com/item?id=39640745
      hs.hotkey.bind({"cmd", "alt"}, "V", function()
      hs.eventtap.keyStrokes(hs.pasteboard.getContents())
      end)

    • Cách này cũng xử lý được việc Google Sheets chặn/giành quyền nhập liệu quá mức

  • Không nên phải tin tưởng add-on cho những việc như thế này; trình duyệt nên cho phép cấu hình
    Trong Firefox có thể bật/tắt dom.event.clipboardevents.enabled

    • Sẽ tốt hơn nếu có thể chỉ tắt riêng sự kiện “dán”. Trong các công cụ làm việc, những nút kiểu “nhấp để sao chép giá trị này” rất hữu ích, nên mỗi lần tắt sự kiện clipboard để tránh trang độc hại thì lại không dùng được chức năng đó, khá đáng tiếc

    • Theo cảm nhận, thiết lập này làm hỏng chức năng dán trong một số web app, chẳng hạn một số terminal emulator hoặc trình soạn thảo văn bản

    • Khi nhấp chuột phải, nếu giữ Shift thì cũng có thể buộc menu mở ra

    • Trước đây thiết lập này làm hỏng chức năng sao chép/dán của Google Docs. Lâu rồi tôi chưa thử, nên có thể giờ đã được sửa

  • Tôi cũng ghét việc các trang web chặn dán, nên tiện ích mở rộng này thật đáng hoan nghênh. Đặc biệt ở những chỗ như xác nhận số tài khoản, routing number hoặc địa chỉ email, và nó cũng làm hỏng trình quản lý mật khẩu. Việc triển khai các quy tắc mật khẩu phức tạp với lý do ngăn mật khẩu yếu mà lại chặn dán thì tất nhiên là gây bực bội
    Nhưng tôi cũng từng trực tiếp triển khai biện pháp bảo mật kiểu này trong một ứng dụng web. Tôi nhận yêu cầu rồi làm, đồng thời hỏi khách hàng tại sao phải làm khi “ai cũng” biết nó tệ cho trải nghiệm người dùng và còn phản tác dụng lớn về bảo mật
    Câu trả lời là tuân thủ. Vì họ cần vượt qua kiểm toán bảo mật và chứng minh với khách hàng lớn hoặc công ty bảo hiểm rằng họ có các biện pháp bảo mật tiêu chuẩn ngành
    Đáng tiếc là ngân hàng không quan tâm đến 2% người dùng trình quản lý mật khẩu. Phần còn lại vẫn ghi nhớ mật khẩu, quên mật khẩu, rồi đem chuyện đó ra đùa như năm 2003

    • Người ta nói “phải làm vì tuân thủ”, nhưng có thật vậy không?
      Tôi chưa từng thấy yêu cầu tuân thủ nào không thể phản biện một cách hợp lý. Đó chỉ là kết quả của việc một tư vấn tuân thủ quá nhiệt tình gặp một đội không mấy quan tâm đến người dùng. Mọi người chẳng đặt câu hỏi nghiêm túc về bất cứ điều gì

    • Đợt kiểm toán tuân thủ PCI của chúng tôi đã bắt lỗi vì không tắt tự động hoàn thành trong các trường của form đăng nhập. Không giống hẳn với tắt dán, nhưng đang đi theo hướng đó
      Cá nhân tôi thì trang nào không cho dùng trình quản lý mật khẩu (Bitwarden) là tôi bỏ luôn

    • Nếu các cách vượt chặn dán trở nên quá phổ biến, cuối cùng chính những trang đó sẽ triển khai bàn phím ảo
      Nếu điều đó quá dễ với người dùng màn hình cảm ứng, bước tiếp theo có lẽ sẽ là một con chuột ảo để nhấp bàn phím ảo. Để phân biệt người với máy tính, họ còn có thể thay đổi ngẫu nhiên gia tốc chuột

  • Đây là một bookmarklet thay thế từng được đăng ở đây trước đây
    [1]: https://bookmarkl.ink/ashtonmeuser/6e3869d8e468e016f22a4b4de...

    • Bookmarklet thật sự bị đánh giá thấp. Với vấn đề này, đó là một bản sửa đơn giản và quan trọng hơn là có thể đọc được
  • Khi không dán được, tôi thường nhấp phải → Inspect element rồi gõ $0.value="value from clipboard" trong console. Gần như chỗ nào cũng chạy
    Việc can thiệp vào dán giống như tắt tự động điền, và chuẩn HTML5 nói khá rõ khi nào mới nên tắt: “giá trị đặc biệt nhạy cảm (ví dụ: mã kích hoạt vũ khí hạt nhân), hoặc giá trị sẽ không bao giờ được dùng lại (ví dụ: khóa dùng một lần để đăng nhập ngân hàng)”

    • Đoạn đó trông như một sai lầm trong chuẩn, gây hại cho bảo mật. Cơ sở là gì? Ngón tay người dùng ít lỗi hơn trình quản lý mật khẩu sao?
      Điều duy nhất tôi nghĩ tới là trường hợp mã độc thay đổi giá trị clipboard để lừa người dùng dán sai giá trị. Nhưng nếu mở ra kịch bản đó, mã độc cũng có đủ mọi cách để nghịch các trường nhập thủ công
  • Chặn/giành Ctrl-F cũng cùng một hạng

    • Một phím tắt có một ý nghĩa trong trình duyệt nhưng lại có ý nghĩa hoàn toàn khác trong ứng dụng khác là chuyện rất phổ biến. Khi những ứng dụng như vậy ngày càng thường xuyên trở thành web app, xung đột phím tắt có thể xảy ra
      Lấy Google Docs làm ví dụ: khi nhấn Ctrl-F trong tài liệu hoặc bảng tính, bạn muốn tìm kiếm của trình duyệt hay tìm kiếm của chính ứng dụng? Đại đa số người dùng muốn tìm kiếm của ứng dụng. Khi đọc trang tin tức, hầu hết sẽ kỳ vọng tìm kiếm của trình duyệt
      Nghĩa là các quy tắc nghiêm ngặt luôn có ngoại lệ. Tuy vậy, riêng vấn đề sao chép/dán trong bài gốc thì không có ngoại lệ. Đừng thao túng clipboard của tôi vì những trò marketing/theo dõi vớ vẩn

    • Cũng có những trường hợp nửa hợp pháp có thể biện minh được. Ví dụ khi xem cơ sở dữ liệu Notion, Ctrl-F chuẩn gần như vô dụng; tìm kiếm tài liệu phải lấy kết quả qua Notion API, và đôi khi còn phải tìm các kết quả liên quan đến những mục đang hiển thị trên màn hình
      Tôi nói “nửa” vì thật ra tôi muốn nó được gán sang phím tắt khác. Dù vậy, tôi hiểu lập luận rằng người dùng có thể muốn ánh xạ lại
      Rốt cuộc, nó bắt nguồn từ quyết định chọn cách xử lý tài liệu như vậy ngay từ đầu. Ở ranh giới giữa ứng dụng trực tuyến và trang web, đây trở thành một cuộc tranh luận phức tạp

    • Gần đây tôi phát hiện rằng sau khi bị chặn/giành, nếu nhấn Ctrl-F thêm một lần nữa thì ô tìm kiếm của trình duyệt sẽ hiện ra
      Tôi không nhớ đó là trang nào, nhưng trong ô tìm kiếm đã chặn/giành phím có tooltip cho biết điều này. Tôi thử xem có hoạt động với tìm kiếm Redocly không; không có tooltip, nhưng vẫn hoạt động
      Tôi không chắc đây là hành vi phổ biến, hay chỉ là một tính năng không được tài liệu hóa của giao diện Redocly và sẽ không hoạt động ở những nơi nhà phát triển không đặc biệt quan tâm
      Môi trường là Chrome + OSX hoặc Windows

  • Tôi không hiểu vì sao trình duyệt lại cho phép website ghi đè phím tắt của chính trình duyệt. Tôi nghĩ muốn làm cho nó hoạt động được như vậy thì hẳn còn phải viết thêm code
    Ví dụ, Linear chặn Cmd+F và thay vì tính năng tìm kiếm tích hợp sẵn của trình duyệt vốn hoạt động giống nhau ở mọi nơi, họ lại đưa ra một thứ rất tệ. Đây cũng chính là Linear, nơi dường như nghĩ rằng không ai có thể không muốn chỉnh sửa Markdown kiểu WYSIWYG

    • Tài liệu API của Stripe làm chuyện này và thật sự rất khó chịu. Nó làm chiếc M2 MacBook Pro của tôi đơ trong vài giây
      Thật khó tin là đã năm 2024 rồi mà vẫn không thể chỉ grep tài liệu
  • Có ai khác để ý là bài gốc đã chia sẻ một fork không có cải tiến đáng kể nào so với kho gốc mà vẫn nhận được 399 upvote không?

    • Tác giả kho gốc đã từ chối PR hỗ trợ Firefox, nên chủ fork mới fork để thêm 6 dòng manifest
      https://github.com/jswanner/DontF-WithPaste/pull/29
      Dù vậy, tôi thừa nhận thay đổi .gitignore không liên quan thì vốn không có lý do gì để nằm trong PR ban đầu

    • Cái này là cho Firefox, còn cái kia là cho Chrome, nên có lẽ đây có thể là một nâng cấp khá có ý nghĩa

    • Tôi nghĩ số upvote đó nhận được vì lý do gần với “đúng vậy, tôi cũng ghét mấy thứ như thế” hơn là “cảm ơn vì công cụ hữu ích”

    • Fork này là để hỗ trợ Firefox, và với người vốn không dùng Chrome thì tôi xem đó là một nâng cấp có ý nghĩa. Kho gốc thì dễ thấy, nhưng tìm một fork cụ thể trên GitHub thì phiền hơn nhiều
      Nếu chuyện đó khó chịu đến vậy thì lần sau tôi sẽ chỉ giữ cho riêng mình. Chắc chẳng có lý do gì để cho những người khác trên HN biết điều họ có thể thấy thú vị

    • Đúng vậy. So với kho cha, chỉ có 3 tệp thay đổi, và các thay đổi chỉ là .gitignore cùng URL được cập nhật sang kho fork