อย่ายุ่งกับเทคนิค Paste แบบส่งเดช

 (github.com/aaronraimist)
1 คะแนน โดย GN⁺ 2024-03-09 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • DontFuckWithPaste เป็นส่วนขยายของ Google Chrome ที่ลบพฤติกรรมของเว็บแอปพลิเคชันที่บล็อก การคัดลอกและวาง ในช่องกรอกข้อมูล
  • โครงการนี้มองว่าการบังคับให้พิมพ์ค่าอย่างอีเมลแอดเดรสหรือค่าจากเครื่องมืออย่าง 1Password ด้วยตนเอง กลับยิ่งเพิ่มโอกาสของ การกรอกผิด
  • ผู้ใช้สามารถกดไอคอนส่วนขยายเพื่อเพิ่มเว็บไซต์เข้า บัญชีดำ แล้วแก้ไขแพตเทิร์นที่สร้างอัตโนมัติได้หากต้องการ ก่อนบันทึก
  • เมื่อส่วนขยายทำงานอยู่ในแท็บปัจจุบัน ไอคอนจะเปลี่ยนเป็น สีน้ำเงิน เพื่อให้ตรวจสอบสถานะเปิด-ปิดในแต่ละแท็บได้
  • Version 2 ใช้สิทธิ์ tabs เพื่อให้ส่วนขยายทำงานเฉพาะบนเว็บไซต์ที่มีปัญหา และคำอธิบายสิทธิ์ของ Chrome อาจดูครอบคลุมเกินจริงและน่ากลัวกว่าการทำงานจริง

ส่วนขยาย Chrome ที่ลบการบล็อกการคัดลอกและวาง

  • DontFuckWithPaste เป็นส่วนขยายของ Google Chrome ที่ลบพฤติกรรมของเว็บแอปพลิเคชันที่บล็อก การคัดลอกและวาง ของผู้ใช้
  • ความรับผิดชอบในการวางอีเมลแอดเดรสผิดลงในช่องกรอกข้อมูลเป็นของผู้ใช้เอง และการคัดลอกแล้ววางค่าจากเครื่องมืออย่าง 1Password อาจมีข้อผิดพลาดน้อยกว่าการพิมพ์ตัวอักษรทุกตัวด้วยตนเอง
  • จุดประสงค์ของส่วนขยายคือการลบข้อจำกัดของเว็บไซต์ที่บล็อกอีเวนต์คัดลอกและวางอย่างตรงไปตรงมา

วิธีใช้งาน

  • วิธีที่ง่ายที่สุดในการเพิ่มเว็บไซต์เข้าไปในบัญชีดำคือการคลิก ไอคอนส่วนขยาย
  • จากนั้นสามารถแก้ไขแพตเทิร์นที่สร้างอัตโนมัติได้หากต้องการ แล้วกด "Save"
  • หลังจากบันทึกแล้ว หากไอคอนส่วนขยายแสดงเป็น สีน้ำเงิน แปลว่าส่วนขยายกำลังทำงานอยู่ในแท็บปัจจุบัน

การเปลี่ยนแปลงและสิทธิ์ของ Version 2

  • Version 2 เป็นอัปเดตหลักของส่วนขยาย และทำให้สร้างเงื่อนไขให้ส่วนขยายทำงานเฉพาะบนเว็บไซต์ที่จัดการอีเวนต์คัดลอกและวางได้ไม่ดีได้ง่ายขึ้น
  • ยังเพิ่ม การมองเห็นสถานะ ว่าในแต่ละแท็บส่วนขยายกำลังเปิดใช้งานหรือปิดใช้งานอยู่
  • จำเป็นต้องมีสิทธิ์ tabs เพื่อให้รู้ว่าแท็บที่ใช้งานอยู่เปลี่ยนไปเมื่อใด
    • Chrome อธิบายสิทธิ์นี้ว่า "can read and change all your data on websites you visit"
    • README ระบุว่าคำอธิบายนี้ดูน่ากลัว แต่ส่วนขยายไม่ได้ทำงานเช่นนั้นจริง
  • เนื่องจากเป็นโครงการโอเพนซอร์ส ผู้ใช้จึงสามารถอ่านโค้ดเพื่อตรวจสอบได้ว่าส่วนขยายทำงานอย่างไร และไม่ได้ทำอะไรกับข้อมูลผู้ใช้บ้าง
  • ข้อมูลเพิ่มเติมเกี่ยวกับการอัปเกรด Version 2 ดูได้ที่ wiki page

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2024-03-09
ความคิดเห็นใน Hacker News

  • การบล็อกการป้อนข้อมูลของผู้ใช้กลับทำให้ ความปลอดภัยของแอปพลิเคชัน แย่ลงเสียอีก ถ้าห้ามคัดลอกรหัสผ่าน ผู้ใช้ที่เดิมใช้รหัสผ่านที่ดีอยู่แล้วก็อาจเปลี่ยนไปใช้รหัสผ่านที่ซับซ้อนน้อยลงเพราะพิมพ์ลำบาก
    ถ้าบังคับให้กรอกข้อมูลที่ซับซ้อน แต่กลับไม่ยอมให้ผู้ใช้วางค่าที่สร้างมาอย่างถูกต้องได้ ประสบการณ์ผู้ใช้ก็พังด้วย

    • ระบบที่บังคับให้ต้องใช้ตัวอักษรบางประเภทก็มีปัญหาเหมือนกัน แทนที่จะตั้งกฎแบบ “ต้องมีตัวพิมพ์ใหญ่ ตัวเลข และอักขระพิเศษ” ฉันชอบให้สร้างรหัสผ่านที่ยาวกว่าแม้จะใช้แค่ตัวอักษรธรรมดา เพราะถ้าต้องพิมพ์เองเป็นครั้งคราวก็ง่ายกว่า
      ที่แย่กว่านั้นคือบางกรณียังจำกัดชนิดของอักขระพิเศษที่อนุญาตอีก ต้องกลับไปแก้รหัสผ่านที่สร้างไว้แล้วเพื่อลบตัวอักษรบางตัวออก
      สู้แสดง ความแข็งแกร่งของรหัสผ่าน แล้วแนะนำว่า “เพิ่มจำนวนตัวอักษรอีกหน่อย เช่น ใช้สี่คำก็ได้” จะยากอะไรนักหนา

    • ผู้ใช้มักไม่ได้ใช้กฎพิเศษของอินเทอร์เฟซนั้นบ่อยพอจะจำได้ สุดท้ายก็มีแนวโน้มจะลอง คัดลอกจากคลิปบอร์ด ก่อนอยู่ดี

    • โดยรวมก็เห็นด้วยว่าควรปล่อยให้ผู้ใช้ใช้ฟังก์ชันที่คุ้นเคย แต่ถ้ามีนิสัยคัดลอกและวางข้อมูลรับรอง ก็จะเสี่ยงต่อ ฟิชชิง มากขึ้น
      เครื่องมือจัดการรหัสผ่านที่มากับ Firefox และ Chrome จะไม่ใส่ข้อมูลรับรองผิดให้เว็บปลอมหน้าตาคล้ายกัน แต่ผู้ใช้อาจทำพลาดแบบนั้นได้

  • เพื่อให้ประสบการณ์ลื่นไหลที่สุด ส่วนขยายจำเป็นต้องรู้ว่าตอนไหนแท็บที่ใช้งานอยู่มีการเปลี่ยนแปลง และการรับเหตุการณ์นั้นต้องใช้สิทธิ์ tabs ซึ่ง Chrome อธิบายว่า “สามารถอ่านและเปลี่ยนแปลงข้อมูลทั้งหมดของคุณบนเว็บไซต์ที่คุณเข้าชม” คำอธิบายนี้น่ากลัวมาก แต่ไม่ใช่สิ่งที่ส่วนขยายนี้ทำเลยแม้แต่น้อย เนื่องจากเป็นโครงการโอเพนซอร์ส คุณจึงอ่านโค้ดทั้งหมดได้ทุกเมื่อเพื่อตรวจสอบว่าส่วนขยายนี้ทำงานอย่างไร และมันไม่ทำอะไรกับข้อมูลผู้ใช้บ้าง
    ปัญหาคือ ต่อให้คุณอ่านโค้ดเองหรือเชื่อว่ามีคนอ่านแล้ว ก็ไม่มีอะไรรับประกันว่า การอัปเดตในอนาคต จะยังเป็นแบบเดิม ผู้เขียนอาจมีมโนธรรมลดลงเมื่อเวลาผ่านไป หรืออาจขายส่วนขยายไปก็ได้
    เท่าที่รู้ ส่วนขยาย Chrome จะอัปเดตอัตโนมัติ และถึงไม่เป็นแบบนั้น ก็ต้องจำไว้ว่าไม่ควรถือว่าการอัปเดตของส่วนขยายนี้ปลอดภัยเสมอไป

    • ปัญหาคือไม่มี โมเดลสิทธิ์ทางเลือก สำหรับทำเรื่องนี้ ฉันลองใช้ส่วนขยายมาหลายตัวแล้ว และบ่อยครั้งมันทำอะไรไม่ได้เลยถ้าไม่มีสิทธิ์อ่าน/เขียนเต็มรูปแบบกับทุกหน้า
      ตัวอย่างเช่น มีส่วนขยายที่คลิกขวารูปภาพแล้วหมุนได้ -90/+90/180 องศา สิ่งที่ต้องการจริง ๆ ก็แค่ให้เบราว์เซอร์แจ้งเมื่อมีแท็กรูปภาพอยู่ แต่ไม่มีตัวเลือกแบบนั้น
      สุดท้ายก็ต้องฝัง allowlist รายหน้าไว้ในโค้ด หรือให้ผู้ใช้สร้าง allowlist แยกทีละหน้า หรือไม่ก็ร้องขอสิทธิ์อ่าน/เขียนเต็มรูปแบบกับทุกเว็บเพจที่ผู้ใช้เข้าชม

    • ผู้เขียนก็อธิบายอย่างโปร่งใสที่สุดแล้วว่าต้องใช้สิทธิ์อะไรและเพราะอะไร แถมเหตุผลนั้นก็เกิดจากปัจจัยที่ผู้เขียนควบคุมไม่ได้ด้วย การตอบสนองแบบนี้ดูค่อนข้างมองร้ายเกินไป
      ในเชิงเทคนิคก็จริง ว่าภายหลังอาจทำอะไรก็ได้
      แต่ถึงอย่างนั้น ท่าทีแบบนี้ก็ดูน่าชื่นชมมากกว่าจะถูกตำหนิ

    • ไม่รู้ว่าทำไมโพสต์ต้นฉบับถึงลิงก์ไปที่ฟอร์กแทนของเดิม ของเดิมมี เวอร์ชัน bookmarklet ให้ใช้เป็นทางเลือกด้วย
      https://github.com/jswanner/DontF-WithPaste?tab=readme-ov-fi...

    • ถ้าดาวน์โหลดซอร์สของส่วนขยายมา แล้วใช้ “Load unpacked extension” ในโหมดนักพัฒนาส่วนขยายของ Chrome ก็เลี่ยงปัญหานั้นได้ อย่างน้อยก็มั่นใจได้ว่าส่วนขยายจะไม่ถูกเปลี่ยนแบบลับ ๆ
      แต่สำหรับส่วนขยายนี้ ฉันก็ยังไม่ให้สิทธิ์ทุกเว็บไซต์อยู่ดี เปิดใช้เฉพาะรายเว็บไซต์เท่านั้น

    • นั่นจึงเป็นเหตุผลว่าทำไมฉันถึงใช้ ตัวจัดการแพ็กเกจของระบบ สำหรับติดตั้งและอัปเดตส่วนขยายเบราว์เซอร์
      ถ้าในคลังแพ็กเกจไม่มีส่วนขยายเบราว์เซอร์ที่ต้องการ ฉันก็แพ็กเกจเอง ส่งเข้าคลัง และรับผิดชอบการตรวจสอบกับการดูแลรักษาอย่างต่อเนื่อง

  • ปกติฉันเลี่ยงปัญหานี้ด้วยการ ลากแล้ววาง ข้อความที่วางลงไปในช่องอย่าง URL field บน Mac
    แต่การบล็อกการวางโดยอ้างเรื่องความปลอดภัยนั้นเป็นความคิดที่โง่สุด ๆ พอ ๆ กับการตั้งเวลาจำกัดที่สั้นเกินไปไม่ว่าจะที่ไหนก็ตาม
    ถ้าได้เจอคนที่ตัดสินใจแบบนี้ด้วยตัวเองคงดี

    • ครั้งหนึ่งฉันเคยถูกบังคับให้ทำ ออกจากระบบอัตโนมัติใน 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)

    • บน Windows ก็ทำแบบเดียวกันด้วย AutoHotkey มันยังมีประโยชน์กับกรณีที่ GUI ของการเชื่อมต่อระยะไกลใช้คลิปบอร์ดระยะไกลเป็นค่าเริ่มต้น หรือกับคอนโทรลของแอปเดสก์ท็อปรุ่นเก่าที่ไม่รองรับการวางด้วย

  • Keyboard Maestro ก็เป็นแอปที่ยอดเยี่ยมสำหรับงานแบบนี้ และยังใส่ดีเลย์ระหว่างการกดปุ่มเล็กน้อยเพื่อป้องกันการทำงานผิดปกติด้วย ประมาณ 0.05 วินาที

    • บน Windows ก็ทำงานแบบเดียวกันด้วย AHK และใช้คีย์ลัดเหมือนกัน เพียงแต่ใส่ดีเลย์สั้นๆ ราว 10~50ms ระหว่างการกดแต่ละปุ่ม ไม่อย่างนั้นบางครั้งการป้อนข้อมูลอาจเพี้ยนได้

    • ฉันก็เพิ่มเหมือนกัน แต่เท่าที่จำได้ Cmd+Shift+V คือ “วางโดยไม่เอารูปแบบ” เลยใช้ option แทน shift
      -- https://news.ycombinator.com/item?id=39640745
      hs.hotkey.bind({"cmd", "alt"}, "V", function()
      hs.eventtap.keyStrokes(hs.pasteboard.getContents())
      end)

    • วิธีนี้ยังแก้ปัญหา การดักจับอินพุต ที่มากเกินไปของ Google Sheets ได้ด้วย

  • เรื่องแบบนี้ไม่ควรต้องไปเชื่อใจแอดออน และควรตั้งค่าได้จากในเบราว์เซอร์
    ใน Firefox สามารถสลับ dom.event.clipboardevents.enabled ได้

    • ถ้าปิดได้เฉพาะอีเวนต์ “paste” ก็น่าจะดี เครื่องมือทำงานหลายตัวมีปุ่มอย่าง “คลิกเพื่อคัดลอกค่านี้” ที่มีประโยชน์มาก แต่พอต้องปิด clipboard event เพื่อเลี่ยงเว็บอันตราย ก็เสียดายที่ใช้ฟีเจอร์นั้นไม่ได้ทุกครั้ง

    • เท่าที่รู้สึก การตั้งค่านี้ทำให้ ฟังก์ชันวาง พังในบางเว็บแอป เช่น terminal emulator หรือ text editor บางตัว

    • ตอนคลิกขวา ถ้ากด Shift ค้างไว้ก็อาจบังคับให้เมนูเปิดได้

    • เมื่อก่อนการตั้งค่านี้เคยทำให้การคัดลอก/วางใน Google Docs พัง ไม่ได้ลองมาสักพักแล้ว ตอนนี้อาจแก้ไปแล้วก็ได้

  • ฉันก็ไม่ชอบเหมือนกันเวลาเว็บบล็อกการวาง เลยยินดีต้อนรับส่วนขยายนี้ โดยเฉพาะในที่ที่ต้องยืนยันเลขบัญชี·routing number หรืออีเมล และมันยังทำให้ password manager พังด้วย ตั้งกฎรหัสผ่านซับซ้อนโดยอ้างว่าจะกันรหัสผ่านอ่อนแอ แต่กลับบล็อกการวางก็ชวนหงุดหงิดตามคาด
    แต่ฉันเองก็เคยทำมาตรการความปลอดภัยแบบนี้ลงในเว็บแอปโดยตรงเหมือนกัน ได้ requirement มาก็ทำ แล้วก็ถามลูกค้าว่าทำไมต้องทำ ทั้งที่ “ทุกคน” ก็รู้ว่าสิ่งนี้ทั้งทำลายประสบการณ์ผู้ใช้และแทบย้อนแย้งกับความปลอดภัยเอง
    คำตอบคือ compliance เพราะต้องผ่าน security audit และพิสูจน์ให้ลูกค้ารายใหญ่หรือบริษัทประกันเห็นว่ามีมาตรการความปลอดภัยตามมาตรฐานอุตสาหกรรม
    น่าเสียดายที่ธนาคารไม่ได้สนใจ 2% ที่ใช้ password manager ส่วนที่เหลือยังคงจำรหัสผ่าน ลืมรหัสผ่าน และเอาเรื่องนี้มาล้อกันเหมือนยังเป็นปี 2003

    • เขาว่า “ต้องทำเพราะ compliance” แต่จริงหรือ?
      ฉันไม่เคยเห็นข้อกำหนดด้าน compliance ที่โต้แย้งอย่างมีเหตุผลไม่ได้เลย มันเป็นแค่ผลจากการเจอ consultant ด้าน compliance ที่เอาจริงเกินเหตุ กับทีมที่ไม่ค่อยแคร์ผู้ใช้ คนส่วนใหญ่ก็ไม่เคยตั้งคำถามให้จริงจัง

    • การตรวจ PCI compliance ของเราชี้ว่าฟอร์มล็อกอินไม่ได้ปิด autocomplete ในช่องกรอก แม้จะไม่เหมือนกับการปิดการวางเสียทีเดียว แต่มันก็ไปในทิศทางนั้น
      ส่วนตัวแล้ว ถ้าเว็บไหนทำให้ใช้ password manager อย่าง Bitwarden ไม่ได้ ฉันก็เลิกใช้เว็บนั้นไปเลย

    • ถ้าวิธีเลี่ยงการบล็อกการวางแพร่หลายมากเกินไป สุดท้ายเว็บพวกนั้นก็คงไปทำ คีย์บอร์ดเสมือน กัน
      ถ้าสำหรับผู้ใช้จอสัมผัสมันยังง่ายเกินไป ลำดับต่อไปอาจเป็นเมาส์เสมือนสำหรับคลิกคีย์บอร์ดเสมือนก็ได้ แล้วอาจสุ่ม mouse acceleration เพื่อแยกมนุษย์กับคอมพิวเตอร์อีก

  • นี่คือ bookmarklet ทางเลือกที่เคยมีคนโพสต์ไว้ที่นี่ก่อนหน้านี้
    [1]: https://bookmarkl.ink/ashtonmeuser/6e3869d8e468e016f22a4b4de...

    • bookmarklet นี่ถูกประเมินค่าต่ำไปมาก สำหรับปัญหานี้มันเรียบง่าย และที่สำคัญกว่านั้นคือเป็น วิธีแก้ที่อ่านรู้เรื่อง

  • เวลาวางไม่ได้ ปกติฉันจะคลิกขวา → Inspect Element แล้วพิมพ์ $0.value="value from clipboard" ในคอนโซล ใช้ได้แทบทุกที่
    การไปยุ่งกับการวางก็คล้ายกับการปิด autofill และมาตรฐาน HTML5 ก็บอกค่อนข้างชัดว่าควรปิดเฉพาะเมื่อไร: “โดยเฉพาะกับค่าที่อ่อนไหวมาก (เช่น รหัสเปิดใช้งานอาวุธนิวเคลียร์) หรือค่าที่จะไม่มีวันใช้ซ้ำ (เช่น คีย์ใช้ครั้งเดียวสำหรับล็อกอินธนาคาร)”

    • ตรงนั้นดูเหมือนเป็นความผิดพลาดของมาตรฐานที่บั่นทอนความปลอดภัย เหตุผลคืออะไร? นิ้วคนพิมพ์ผิดน้อยกว่า password manager งั้นหรือ?
      สิ่งเดียวที่พอนึกออกคือกรณีมัลแวร์เปลี่ยนค่าบนคลิปบอร์ดเพื่อหลอกให้ผู้ใช้วางค่าผิด แต่ถ้าเปิดรับสถานการณ์นั้น มัลแวร์ก็มีสารพัดวิธีจะแทรกแซงช่องกรอกแบบพิมพ์เองอยู่แล้ว

  • การดัก Ctrl-F ก็อยู่ระดับเดียวกัน

    • คีย์ลัดที่มีความหมายอย่างหนึ่งในเบราว์เซอร์ มักมีความหมายต่างออกไปโดยสิ้นเชิงในแอปอื่นๆ พอแอปพวกนั้นกลายเป็นเว็บแอปกันมากขึ้น ก็เกิดการชนกันของคีย์ลัดได้
      ยก Google Docs เป็นตัวอย่าง เวลาอยู่ในเอกสารหรือสเปรดชีตแล้วกด Ctrl-F คุณต้องการการค้นหาของเบราว์เซอร์ หรือการค้นหาของตัวแอปเอง? ผู้ใช้ส่วนใหญ่ต้องการการค้นหาของแอป แต่เวลาอ่านเว็บข่าว คนส่วนใหญ่ก็คงคาดหวังการค้นหาของเบราว์เซอร์
      นั่นหมายความว่ากฎที่เข้มงวดก็มีข้อยกเว้นเสมอ เพียงแต่ปัญหาคัดลอก/วางในต้นฉบับนี้ไม่มีข้อยกเว้น อย่ามายุ่งกับคลิปบอร์ดของฉันด้วยเรื่องการตลาด·การติดตามไร้สาระ

    • ก็มีกรณีที่พอจะอ้างเหตุผลได้อยู่บ้างแบบครึ่งๆ กลางๆ เช่น เวลาดูฐานข้อมูลใน Notion, Ctrl-F มาตรฐานแทบไม่มีประโยชน์ และการค้นหาเอกสารต้องดึงผลผ่าน Notion API บางครั้งยังต้องหาผลที่เกี่ยวข้องกับรายการที่แสดงบนหน้าจอด้วย
      ที่บอกว่า “ครึ่งๆ กลางๆ” ก็เพราะจริงๆ แล้วฉันอยากให้แมปเป็นคีย์ลัดอื่นมากกว่า ถึงอย่างนั้นก็พอเข้าใจเหตุผลว่าทำไมผู้ใช้อาจอยากรีแมปได้
      สุดท้ายมันก็มาจากการตัดสินใจตั้งแต่แรกว่าจะจัดการเอกสารแบบนั้น บริเวณรอยต่อระหว่างแอปออนไลน์กับหน้าเว็บนี่แหละที่กลายเป็นข้อถกเถียงซับซ้อน

    • ไม่นานมานี้ฉันเพิ่งรู้ว่าหลังจากโดนดัก Ctrl-F ไปแล้ว ถ้ากด Ctrl-F อีกครั้ง กล่องค้นหาของเบราว์เซอร์จะโผล่มา
      จำไม่ได้ว่าเป็นเว็บไหน แต่มี tooltip ในกล่องค้นหาที่ถูกดักไว้บอกเรื่องนี้อยู่ ฉันเลยลองกับ Redocly search ด้วยความสงสัยว่าจะได้ไหม แม้ไม่มี tooltip แต่มันก็ใช้ได้
      ฉันไม่แน่ใจว่านี่เป็นพฤติกรรมทั่วไปหรือเปล่า หรือเป็นฟีเจอร์ที่ไม่ได้เขียนไว้ของอินเทอร์เฟซ Redocly และจะใช้ไม่ได้ในที่ที่นักพัฒนาไม่ได้ตั้งใจรองรับเป็นพิเศษ
      สภาพแวดล้อมคือ Chrome + OSX หรือ Windows

  • ไม่เข้าใจว่าทำไมเบราว์เซอร์ถึงยอมให้เว็บไซต์เขียนทับคีย์ลัดของตัวเองได้ ถ้าจะให้มันทำงานถูกต้องจริง ๆ เหมือนน่าจะต้องเขียนโค้ดเพิ่มต่างหาก
    ตัวอย่างเช่น Linear ดัก Cmd+F แล้วเอาอะไรห่วย ๆ มาให้แทนการค้นหาในตัวเบราว์เซอร์ที่ทำงานเหมือนกันทุกที่ นี่คือ Linear เจ้าเดียวกับที่ดูเหมือนจะคิดว่าทุกคนต้องการแก้ไข Markdown แบบ WYSIWYG

    • เอกสาร API ของ Stripe ก็ทำแบบนี้ด้วย น่าหงุดหงิดมาก ทำให้ M2 MacBook Pro ของฉันค้างไปหลายวินาที
      นี่มันปี 2024 แล้ว แต่ยังไม่น่าเชื่อว่าฉันยังไม่สามารถ grep เอกสารได้ตรง ๆ

  • มีคนอื่นสังเกตไหมว่าต้นฉบับโพสต์นี้แชร์ฟอร์กที่แทบไม่มีการปรับปรุงอย่างมีนัยสำคัญเมื่อเทียบกับรีโพซิทอรีต้นทาง แต่กลับได้ 399 โหวตบวก?

    • ผู้เขียนรีโพซิทอรีต้นทางปฏิเสธ PR สำหรับรองรับ Firefox ดังนั้นเจ้าของฟอร์กเลยฟอร์กมาเพื่อเพิ่มแค่ 6 บรรทัดใน manifest
      https://github.com/jswanner/DontF-WithPaste/pull/29
      แต่ก็ยอมรับว่าการเปลี่ยน .gitignore ที่ไม่เกี่ยวข้องไม่มีเหตุผลจะต้องอยู่ใน PR เดิม

    • อันนี้สำหรับ Firefox ส่วนอีกอันสำหรับ Chrome เพราะงั้นมันอาจนับเป็นการอัปเกรดที่มีความหมายพอสมควรก็ได้

    • เหมือนว่าจะได้โหวตบวกเพราะความรู้สึกแบบ “ใช่ ฉันก็เกลียดอะไรแบบนี้เหมือนกัน” มากกว่า “ขอบคุณสำหรับเครื่องมือที่มีประโยชน์”

    • ฟอร์กนี้ไว้รองรับ Firefox และจากมุมของคนที่ไม่ได้ใช้ Chrome ตั้งแต่แรก ฉันมองว่ามันเป็นการอัปเกรดที่มีความหมาย รีโพซิทอรีต้นทางหาเจอได้ง่ายอยู่แล้ว แต่การหาเฉพาะฟอร์กหนึ่งบน GitHub น่ารำคาญกว่ามาก
      ถ้ามันน่ารังเกียจขนาดนั้น คราวหน้าฉันก็คงเก็บไว้รู้คนเดียว ไม่มีเหตุผลจะต้องบอกอะไรที่คนอื่นบน HN อาจสนใจ

    • ใช่ ไฟล์ที่เปลี่ยนเมื่อเทียบกับรีโพซิทอรีแม่มี 3 ไฟล์ และสิ่งที่เปลี่ยนก็มีแค่ .gitignore กับ URL ที่อัปเดตให้ชี้ไปยังรีโพซิทอรีฟอร์ก