권한 대화상자의 가장 큰 문제는 앱이 구체적으로 무엇을 하려다 권한을 요청했는지 기술적인 설명이 없다는 것임. 허용과 거부가 실제로 무엇을 의미하는지도 모르는데 어떻게 선택할 수 있겠는가?
iOS에 클립보드 접근 권한 요청이 도입됐을 때도 같은 일을 겪었음. 내가 만든 앱은 클립보드에 관련 URL이 있으면 자동으로 리디렉션을 처리했고, 수년 동안 사용자들이 좋아하던 기능이었음.
그런데 붙여넣기 전에 권한을 묻기 시작하면서 개인정보를 침해한다는 항의가 들어오기 시작함. 모호한 시스템 문구 대신 실제 동작을 설명하거나 감지 패턴을 지정할 수 있었다면 훨씬 나았을 것임.
사소한 경고를 쏟아내면 진짜 위험도 잡음으로 취급해 무시하게 되므로, 오히려 보안·개인정보 보호에 대한 경각심을 해친다고 느낌.
단순한 대화상자 자체보다는, 사전 설명이나 동의 없이 API를 호출하는 앱의 권한 요청 흐름이 문제임. 초기 설정 화면에서 권한의 이점을 설명하고, 권한 요청 버튼 옆에 ‘나중에’ 선택지를 두는 등 잘 처리하는 앱도 많음.
웹의 소리 나는 동영상 자동 재생처럼, 클릭 이벤트 처리기 밖에서 호출하면 API를 차단하는 방법도 있겠음. 기존 앱과의 호환성은 깨지겠지만, 악의적인 화면 설계까지 막지는 못해도 앱 시작과 동시에 무심코 권한을 요청하는 나쁜 사용성은 줄일 수 있음.
보통은 일단 거부하고, 기능이 안 되면 앱이 알려주기를 기다림. 그런데 CVS 앱에 Bluetooth 접근 권한이 필요한 이유는 무엇인가?
샌드박스 앱의 성가신 권한 대화상자를 해결하려고, 샌드박스도 없고 검증도 안 된 앱에 손쉬운 사용 권한을 주라니 역설적임.
결국 ‘이 소프트웨어가 원하는 모든 동작을 허용하고 모든 위험을 감수하겠다’는 버튼을 원하는 것인가? 업데이트할 때마다 다시 판단할 것인가?
특정 IP 주소 대역을 허용 목록에 등록하면 로컬 네트워크 권한이 필요 없어짐. 팝업도 사라질 것 같지만 확실하지는 않음. 자세한 내용은 https://developer.apple.com/documentation/technotes/tn3179-u...에서 확인할 수 있으며, 명령은 다음과 같음. sudo defaults write com.apple.network.local-network AllowedEthernetLocalNetworkAddresses -array "169.254.0.0/16" sudo defaults write com.apple.network.local-network AllowedWiFiLocalNetworkAddresses -array "169.254.0.0/16"
특정 소프트웨어가 필요하다고 해서 모든 기능까지 원하는 것은 아님. 일부 기능만 원해도 괜찮음.
간단히 포크해서 만들 수 있을 것 같지만, 꽤 무섭게 느껴짐.
자동으로 닫기보다는 왜 권한 요청이 떴는지 정확히 알려주는 도구가 더 필요함. 운영체제가 업데이트될 때마다 요청을 유발하는 동작이 늘어나는 듯하고, 이제는 종료할 때 요청하는 앱까지 있어 이해하기 어려움.
시스템에 ‘위험한’ 접근을 허용하는 모든 API에는 개발자가 권한이 필요한 이유를 설명하는 문자열 인자를 넣을 수 있어야 함. 맥락 없이 Bluetooth 사용 여부만 묻기보다, 개발자가 사용자를 설득하게 하는 편이 나음.
이런 도구가 필요하다는 사실이 macOS의 현주소를 잘 보여줌.
Linux도 별반 낫지 않음. Chromium이나 이를 내장한 앱을 실행할 때, 왜 xdg-portal-something에 wallet 접근을 허용해야 하는가?
다른 앱의 데이터에 접근하려는 요청도 자동으로 닫는 기능이 있으면 좋겠음. Adobe 프로그램은 실행할 때마다 묻고, Claude Code도 매일 뜬금없이 요청함.
‘허용 안 함’을 아무리 눌러도 기억하지 않으면서, 실수로 ‘허용’을 한 번 누르면 영원히 기억하고 다시는 묻지 않음.
Claude Code는 홈 디렉터리 전체에 재귀적으로 find나 grep을 실행할 때 이런 문제가 생김. 전역 CLAUDE.md에 그러지 말라는 지침을 넣으면 해결될 수도 있음.
일반적으로 명령줄·개발 도구는 제대로 서명된 Mac 앱 번들로 배포되지 않아, 운영체제가 권한을 연결할 안정적인 식별 정보가 없는 경우가 많음. 그래서 허용을 눌러도 나중에 권한이 다시 사라질 수 있음.
이런 작은 brew 패키지가 악성인지 판단하는 방법으로 통용되는 기준이 있는가? 이 패키지는 아마 괜찮겠지만, 직접 소스를 검토하거나 에이전트에게 맡기지 않고는 어떻게 알아낼지 모르겠음.
지금 악성이 아니어도 나중에 악성으로 바뀌지 않는다는 보장은 없음. 기본 제공 도구를 우선 활용하고, 꼭 필요한 것만 추가로 설치하는 편이 나음.
바로 그 이유로 요즘은 설치 전에 Claude에 저장소 보안 검토를 맡기고 있음.
독립적인 검증을 거치지 않고 컴퓨터에 들이는 모든 실행 코드, 심지어 데이터에도 적용되는 질문임. 성가신 팝업을 없애는 이점이 쉽게 침해될 수 있는 배포 방식의 위험을 감수할 만큼 큰지 따져야 함.
그래서 이런 작은 오픈소스 프로젝트를 좋아함. 원본을 믿을지 고민하는 대신 직접 포크하고, Claude에 코드를 검토시킨 뒤 내 포크를 실행함.
Chromium 브라우저가 실행할 때 앱 번들을 임시 폴더로 복사하고, macOS가 그 임의 경로에 로컬 네트워크 권한을 연결한다는 설명이라면, 반복되는 권한 요청을 비롯해 수많은 이상 동작이 이해됨. Chrome Helper의 알림 허용 요청이나 Teams 등 자동 업데이트 앱도 마찬가지임.
하지만 프린터·스캐너 유틸리티, 미디어 서버, LAN 탐색 도구 외에는 이 권한이 필요 없다는 설명은 틀렸음. 브라우저와 미디어 플레이어의 Chromecast 멀티캐스트 탐색, Spotify, Steam과 거의 모든 LAN 멀티플레이 게임에도 필요함. Steam과 Spotify 역시 자동 업데이트를 사용함.
Apple이 첫 번째 문제를 해결해야 하며, 가능하면 개발자가 별도 보조 실행 파일을 배포하지 않아도 되는 방식이어야 함. Finder 사이드바에 네트워크에서 탐색되는 위치가 있으면 파일 선택창을 여는 것만으로도 요청이 뜰 가능성이 있지만, 직접 확인하지는 못함.
macOS 서명 로직을 직접 구현해 봤는데, 그 설명은 잘못된 것 같음. TCC는 보통 경로가 아니라 앱 번들의 지정 요구사항(designated requirement) 에 권한을 연결하며, 이는 대체로 코드 서명 인증서의 신원으로 이어짐. macOS는 앱을 파일처럼 자유롭게 옮기도록 설계되어 있음.
직접 TCC 데이터베이스를 확인해도 대부분 경로에 연결되어 있지 않았고, Chrome도 예상대로 번들 ID와 지정 요구사항을 사용함. 로컬 네트워크 권한만 별도 엔진을 쓰는 게 아니라면 원인을 잘못 짚은 것임.
Chrome 항목의 서명 조건을 해석하면, Google의 팀 ID로 서명된 모든 Chrome 채널에 권한이 적용됨.
Chromecast나 Spotify의 해당 기능을 쓰지도, 원하지도 않음. 관련 기능을 켜지 않았다면 권한도 묻지 않아야 함. 기능을 활성화하거나 실제로 사용하려는 순간이 권한을 요청할 때임.
임시 폴더를 기준으로 권한을 연결한다면 설계가 심각하게 잘못된 것 같음. 사용자가 지정하지 않은 위치에서 앱을 실행하는 Google·Chrome이 문제인지, 그런 우회책이 필요하게 만들고 원래 설치한 앱과 권한 요청을 연결하지 못하는 Apple이 문제인지 모르겠음.
운영체제가 방해되는 대화상자를 모두 억제하고 별도 수신함에 모아두면 안 될까? 어떤 요청에 답하고 어떤 요청을 무시할지 한꺼번에 결정하고 싶음.
LAN의 스테이징 서버나 다른 컴퓨터에서 웹사이트를 테스트하는 경우를 아무도 얘기하지 않아 의외임. Safari는 허용하는데 Chrome은 이 시스템을 거쳐 권한을 요청함. Chrome에서 로컬 웹사이트가 차단되면 곤란하므로 이런 요청은 놓치지 않고 허용하려고 함.
이미 수년 전에 해결된 문제이며, 애초에 인증서를 만들어 HTTPS로 접속했어야 함. Safari가 허용하는 것도 좋은 일은 아님.