페이스트(Paste) 기술을 함부로 다루지 마세요

• 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에서 확인할 수 있음

[GN⁺]

Hacker News 의견들

• 사용자 입력을 막으면 오히려 애플리케이션 보안이 나빠짐. 비밀번호를 복사할 수 없게 되면 처음엔 좋은 비밀번호를 쓰던 사용자도 타이핑 부담 때문에 덜 복잡한 비밀번호로 바꾸게 됨
  복잡한 입력을 강제해 놓고 사용자가 제대로 생성한 값을 붙여넣지 못하게 하면 사용자 경험도 망가짐

  • 특정 문자를 반드시 쓰게 하는 시스템도 문제임. “대문자, 숫자, 특수문자를 반드시 포함” 같은 규칙보다, 평범한 문자만 쓰더라도 더 긴 비밀번호를 생성하는 편을 선호함. 가끔 직접 쳐야 할 때 더 쉽기 때문임
    더 나쁜 건 허용되는 특수문자 종류까지 제한하는 경우임. 이미 생성한 비밀번호에서 특정 문자만 지우도록 다시 편집해야 함
    차라리 비밀번호 강도를 보여주고 “문자를 더 많이 쓰세요, 예를 들어 네 단어를 쓸 수 있습니다”처럼 안내하는 게 그렇게 어려운 일인가 싶음

  • 사용자는 그 인터페이스의 특수 규칙을 자주 쓰지 않아서 기억하지 못할 가능성이 크고, 결국 먼저 클립보드 복사를 시도하게 될 것임

  • 사용자가 익숙한 기능을 쓰게 해야 한다는 데는 대체로 동의하지만, 자격 증명을 복사해 붙여넣는 습관이 있으면 피싱에 더 취약해짐
    Firefox와 Chrome의 내장 비밀번호 관리 도구는 닮은꼴 사이트에 실수로 자격 증명을 넣지 않지만, 사용자는 충분히 그럴 수 있음

• 최대한 매끄러운 경험을 제공하려면 확장 프로그램이 활성 탭이 바뀌는 시점을 알아야 합니다. 그 이벤트를 알기 위해서는 tabs 권한이 필요하고, Chrome은 이를 “방문하는 웹사이트의 모든 데이터를 읽고 변경할 수 있음”이라고 설명합니다. 이 설명은 매우 무섭지만, 이 확장 프로그램이 실제로 하는 일은 절대 아닙니다. 오픈소스 프로젝트이므로 언제든 전체 코드를 읽고 이 확장 프로그램이 어떻게 동작하는지, 사용자 데이터로 무엇을 하지 않는지 확인할 수 있습니다
  문제는 코드를 읽었거나 누군가 읽었으리라 믿더라도, 향후 업데이트에서도 계속 그렇다는 보장이 없다는 점임. 작성자의 양심이 시간이 지나며 약해질 수도 있고, 확장 프로그램을 팔 수도 있음
  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)

  • Windows에서는 AutoHotkey로 같은 걸 함. 원격 연결 GUI가 원격 클립보드를 기본으로 쓰는 경우나, 붙여넣기를 지원하지 않는 레거시 데스크톱 애플리케이션 컨트롤에서도 유용했음

  • Keyboard Maestro도 이런 작업에 훌륭한 앱이고, 이상 동작을 막기 위해 키 입력 사이에 적당한 지연도 넣어줌. 대략 0.05초 정도임

  • Windows에서 AHK로 같은 작업을 하고, 단축키도 같게 씀. 다만 각 키 입력 사이에 10~50ms 정도의 작은 지연을 넣음. 그렇지 않으면 입력이 가끔 망가질 수 있음

  • 나도 추가했지만, Cmd+Shift+V는 기억상 “서식 없이 붙여넣기”라서 shift 대신 option을 사용함
    -- 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를 토글할 수 있음

  • “붙여넣기” 이벤트만 선택적으로 끌 수 있으면 좋겠음. 업무 도구들에서 “클릭해서 이 값을 복사” 같은 버튼은 매우 유용한데, 악성 사이트를 피하려고 클립보드 이벤트를 끌 때마다 그 기능을 못 쓰는 게 아쉬움

  • 체감상 이 설정은 일부 웹 앱에서 붙여넣기 기능을 깨뜨림. 예를 들면 특정 터미널 에뮬레이터나 텍스트 편집기임

  • 우클릭할 때 Shift를 누르고 있으면 메뉴를 강제로 열 수도 있음

  • 예전에는 이 설정이 Google Docs의 복사/붙여넣기를 깨뜨렸음. 한동안 안 해봐서 지금은 고쳐졌을 수도 있음

• 나도 사이트가 붙여넣기를 막는 걸 싫어해서 이 확장 프로그램은 반가움. 계좌번호·라우팅 번호나 이메일 주소 확인 같은 곳에서 특히 그렇고, 비밀번호 관리자도 망가뜨림. 약한 비밀번호를 막겠다며 복잡한 비밀번호 규칙을 구현했는데 붙여넣기를 막는 건 당연히 짜증남
  하지만 이런 보안 조치를 웹 애플리케이션에 직접 구현한 적도 있음. 요구사항을 받아서 구현했고, “모두가” 이런 게 사용자 경험에 나쁘고 보안에도 크게 역효과가 난다는 걸 아는데 왜 해야 하느냐고 고객에게 물었음
  답은 컴플라이언스였음. 보안 감사를 통과하고, 대형 고객이나 보험사에 업계 표준 보안 조치를 갖췄다고 증명해야 했기 때문임
  안타깝지만 은행은 비밀번호 관리자를 쓰는 2%를 신경 쓰지 않음. 나머지는 여전히 비밀번호를 외우고, 잊어버리고, 2003년처럼 그걸 농담으로 삼음

  • “컴플라이언스 때문에 해야 한다”고 하지만 정말 그런가?
    합리적으로 반박할 수 없는 컴플라이언스 요구사항은 본 기억이 없음. 과도하게 열성적인 컴플라이언스 컨설턴트와 사용자를 별로 신경 쓰지 않는 팀이 만난 결과일 뿐임. 사람들은 아무것도 제대로 따져 묻지 않음

  • 우리 PCI 컴플라이언스 감사는 로그인 폼 필드에서 자동 완성을 비활성화하지 않았다고 지적함. 붙여넣기 비활성화와 같지는 않지만 그 방향으로 가고 있음
    개인적으로는 비밀번호 관리자(Bitwarden)를 못 쓰게 하는 사이트는 그냥 포기함

  • 붙여넣기 차단 우회책이 너무 널리 퍼지면 같은 사이트들이 결국 가상 키보드를 구현할 것임
    터치스크린 사용자에게 그게 너무 쉽다면 다음은 가상 키보드를 클릭하는 가상 마우스일지도 모름. 사람과 컴퓨터를 구분한다며 마우스 가속도도 무작위로 바꿀 수 있겠음

• 예전에 여기 올라왔던 대안 북마클릿임
  [1]: https://bookmarkl.ink/ashtonmeuser/6e3869d8e468e016f22a4b4de...

  • 북마클릿은 정말 과소평가되어 있음. 이 문제에는 단순하고, 더 중요하게는 읽을 수 있는 수정책임

• 붙여넣기가 안 될 때는 보통 우클릭 → 요소 검사 후 콘솔에 $0.value="value from clipboard"를 씀. 거의 어디서나 동작함
  붙여넣기를 건드리는 건 자동 채우기를 끄는 것과 비슷하고, HTML5 표준은 언제만 꺼야 하는지 꽤 분명하게 말함: “특히 민감한 값(예: 핵무기 활성화 코드)이거나, 절대 재사용되지 않을 값(예: 은행 로그인용 일회용 키)”

  • 그 부분은 보안을 해치는 표준의 실수처럼 보임. 근거가 뭔가? 사람 손가락이 비밀번호 관리자보다 오류가 적다는 건가?
    생각나는 건 악성코드가 클립보드 값을 바꿔서 사용자가 잘못된 값을 붙여넣게 속이는 경우뿐임. 하지만 그 시나리오를 열면 악성코드가 수동 입력 필드에 장난칠 방법도 온갖 가지가 있음

• Ctrl-F 가로채기도 같은 급임

  • 브라우저에서는 한 의미인 단축키가 다른 애플리케이션에서는 전혀 다른 의미인 경우가 많음. 그런 애플리케이션들이 웹 앱이 되는 일이 흔해지면서 단축키 충돌이 생길 수 있음
    Google Docs를 예로 들면, 문서나 스프레드시트에서 Ctrl-F를 눌렀을 때 브라우저 찾기를 원하나, 앱 자체 찾기를 원하나? 대다수 사용자는 앱의 찾기를 원함. 뉴스 사이트를 읽을 때는 대부분 브라우저 검색을 기대할 것임
    엄격한 규칙에는 늘 예외가 있다는 뜻임. 다만 원문의 복사/붙여넣기 문제만큼은 예외 없음. 마케팅·추적 헛짓거리로 내 클립보드를 조작하지 말 것

  • 정당화할 수 있는 반쯤 합법적인 경우도 있음. 예를 들어 Notion 데이터베이스를 볼 때 표준 Ctrl-F는 거의 쓸모없고, 문서 검색이 Notion API를 통해 결과를 가져와야 하며 때로는 화면에 표시된 항목과 관련된 결과도 찾아야 함
    “반쯤”이라고 한 건 사실 다른 단축키로 매핑했으면 좋겠기 때문임. 그래도 사용자가 재매핑을 원할 수 있다는 논리는 이해됨
    결국 애초에 그런 문서 처리 방식을 택한 결정에서 비롯됨. 온라인 애플리케이션과 웹페이지 사이의 경계에서는 복잡한 논쟁이 됨

  • 최근에 가로채인 뒤 Ctrl-F를 한 번 더 누르면 브라우저 검색 상자가 뜬다는 걸 알게 됨
    어떤 사이트였는지는 기억 안 나지만, 가로챈 검색 상자에 이 사실을 알려주는 툴팁이 있었음. Redocly 검색에도 될지 궁금해서 해봤고, 툴팁은 없었지만 동작했음
    이게 보편적으로 동작하는지, 아니면 Redocly 인터페이스의 문서화되지 않은 기능이고 개발자가 특별히 배려하지 않은 곳에서는 안 되는지는 확신하지 못함
    환경은 Chrome + OSX 또는 Windows였음

  • 브라우저가 왜 웹사이트가 자체 단축키를 덮어쓰도록 허용하는지 이해가 안 됨. 제대로 동작하게 하려면 오히려 추가 코드가 필요했을 것 같음
    예를 들어 Linear는 Cmd+F를 가로채서, 어디서나 똑같이 동작하는 브라우저 내장 검색 대신 형편없는 무언가를 제공함. 이건 WYSIWYG Markdown 편집을 원하지 않을 수 없다고 생각하는 그 Linear임

  • Stripe의 API 문서가 이걸 하는데 정말 짜증남. 내 M2 MacBook Pro를 몇 초 동안 멈춰 세움
    2024년인데도 문서를 그냥 grep할 수 없다는 게 믿기지 않음

• 원글이 원본 저장소에 비해 의미 있는 개선이 없는 포크를 공유했는데 399 업보트를 받은 걸 다른 사람들도 눈치챘나?

  • 원본 저장소 작성자가 Firefox 지원 PR을 거절했고, 그래서 포크 소유자가 매니페스트 6줄을 추가하려고 포크한 것임
    https://github.com/jswanner/DontF-WithPaste/pull/29
    다만 관련 없는 .gitignore 변경은 원래 PR에 들어갈 이유가 없었다는 건 인정함

  • 이건 Firefox용이고 다른 건 Chrome용이니, 어쩌면 꽤 의미 있는 업그레이드일 수 있음

  • 업보트는 “유용한 도구 고마워요”보다는 “맞아, 나도 저런 거 싫어”에 더 가까운 이유로 받은 것 같음

  • 포크는 Firefox 지원용이고, 애초에 Chrome을 쓰지 않는 입장에서는 의미 있는 업그레이드라고 봄. 원본 저장소는 쉽게 볼 수 있지만 GitHub에서 특정 포크를 찾는 건 훨씬 귀찮음
    그게 그렇게 불쾌하다면 다음부터는 혼자만 알고 있겠음. HN의 다른 사람들에게 흥미로운 걸 알릴 이유가 없겠음

  • 맞음. 부모 저장소와 비교해 바뀐 파일은 3개이고, 변경 사항은 .gitignore와 포크 저장소로 업데이트된 URL뿐임