권한 메시지는 사용자의 개인 정보 보호 및 보안에 잠재적으로 위험한 강력한 기능을 보호하기 위한 웹의 기본 메커니즘입니다. 권한 메시지를 통해 브라우저는 사용자가 요청하는 웹사이트가 해당 기능에 액세스하도록 허용할 의도가 있는지 확인합니다. 권한 메시지는 미디어 캡처(카메라 및 마이크), 위치정보, 저장용량 액세스, MIDI, 알림을 비롯한 여러 API에 사용됩니다(자세한 내용은 MDN의 Permissions API 문서 참고).
이 가이드에서는 Chrome 사용 통계 및 사용자 조사를 기반으로 사용자에게 권한 메시지를 표시하기 위한 권장사항을 간략하게 설명합니다. 이러한 권장사항을 따르면 사용자에게 불필요한 메시지가 더 적게 표시되므로 개발자가 '차단' 결정을 더 적게 내릴 수 있습니다. 이 도움말은 권한 제한 API를 사용하는 코드 패턴과 사용자가 차단된 상태에서 복구할 수 있도록 지원하기 위한 권장사항으로 마무리됩니다.
프롬프트 권장사항
사용자 상호작용 후 사용자가 요청 이유와 이를 허용함으로써 얻게 되는 이점을 이해할 수 있는 순간에 권한을 요청해야 합니다. 가능한 경우 사용자가 동일한 기능을 수행하는 다른 방법을 사용할 수 있도록 허용해야 합니다. 일반적인 가이드라인으로, 권한을 요청할 때를 신중하게 선택하여 권한을 덜 자주 요청하면 사용자가 복구하기 어려운 차단 상태가 될 가능성이 줄어듭니다. 다음 권장사항에서는 이러한 각 제안사항에 대해 자세히 설명합니다.
페이지 로드 시 또는 사용자 상호작용 없이 묻지 않음
페이지 로드 시 사용자에게 권한을 요청하는 것은 고객이 오프라인 매장에 들어갈 때 민감한 정보를 요청하는 것과 같습니다. 뉴스레터 가입 및 쿠키 동의를 묻는 여러 메시지 중에서 권한 메시지가 표시되면 매우 거슬릴 수 있습니다. 사용자는 요청하는 이유와 어떤 이점이 있는지를 이해하지 못합니다.
웹 애플리케이션이 특정 기능에 액세스하지 않고는 작동할 수 없는 경우에도 사용자에게 필요한 이유를 이해할 수 있는 기회를 제공해야 합니다. 예를 들어 권한 메시지를 자체 프롬프트로 시작하여 필요성을 설명하고 사용자에게 선택권을 제공하는 경우입니다 (예: 가능한 경우 동일한 기능을 실행할 수 있는 대체 수단을 제공). 페이지 로드 시 권한을 요청하는 것보다 나은 시점이 없다면 이 가이드의 뒷부분에 몇 가지 예시가 나와 있습니다.
권한을 요청하기에 좋지 않은 또 다른 상황은 이전 사용자 상호작용이 없는 경우(일시적인 사용자 활성화라고도 함)입니다. Chrome 원격 분석에 따르면 데스크톱 Chrome의 권한 메시지 중 77%가 이러한 매우 기본적인 사용자 의도 신호 없이 표시되며, 그 결과 이러한 메시지의 12%만 허용됩니다. 사용자 상호작용 후 비율을 30%까지 늘립니다. 따라서 사용자가 어떤 형태로든 페이지와 상호작용한 후에만 권한을 요청하세요.
사용자가 질문의 이유를 이해할 수 있을 때만 질문하세요.
권한 결정은 종종 개인 정보 보호 결정입니다. 문맥적 무결성 프레임워크에 따르면 개인 정보 보호 결정은 문맥에 따라 크게 달라집니다. 액세스가 필요한 이유를 이해하는 것이 이 작업의 주요 측면으로 간주될 수 있습니다. 따라서 사용자에게 가치를 제공하는 데 필요한 기능만 요청해야 하며, 사용자가 실제로 가치를 얻을 것이라는 데 동의할 가능성이 높은 기능만 요청해야 합니다. 또한 기능이 유용한 이유가 사용자에게 명확한 시점에 권한을 요청해야 합니다. 사용자는 사용 맥락을 최대한 쉽게 이해할 수 있어야 합니다.
Google의 사용자 연구에 따르면 사용자가 사이트에서 액세스를 요청하는 이유를 이해하고 이점을 인지할 때 액세스를 허용할 가능성이 훨씬 더 높습니다. 또한 사용자는 액세스를 허용하면 얻을 수 있는 가치를 더 잘 이해하기 위해 먼저 익숙하지 않은 사이트를 탐색할 것으로 기대하는 것으로 나타났습니다. 그동안 권한 메시지를 닫거나 무시하는 경우가 많습니다. 일회성 권한의 경우 먼저 한 번의 방문을 허용할 수 있습니다. 애플리케이션은 이러한 동작을 지원해야 합니다.
가능한 경우 동일한 기능을 수행하는 다른 방법을 제공합니다.
일부 기능의 결과는 사용자에게 유용하지 않을 수 있습니다. 예를 들어 GPS 센서가 없는 데스크톱 기기의 위치정보는 사용자가 VPN에 연결되어 있으므로 잘못된 위치를 반환할 수 있습니다. 다른 사용자는 이러한 이벤트를 직접 제어하고 키 조합으로 수동으로 트리거하는 것을 선호하므로 클립보드 액세스 권한을 제공하고 싶지 않을 수 있습니다. 이러한 경우 동일한 결과를 얻을 수 있는 대체 수단을 제공하는 것이 중요합니다. 예를 들어 위치정보 액세스 권한을 요청하는 경우 사용자가 직접 우편번호나 주소를 입력할 수 있는 텍스트 필드를 제공합니다. 클립보드를 사용하면 복사할 요소를 키 조합이나 컨텍스트 메뉴를 통해 선택하고 복사할 수도 있습니다. 알림을 통해 사용자에게 푸시 알림 대신 이메일을 수신할 수 있는 옵션을 제공합니다.
유용한 패턴은 액세스가 유용할 수 있는 이유를 설명할 때 대체 UI를 사용하는 것입니다. 위치정보 API를 트리거하는 버튼 옆에 위치를 입력하는 옵션이 표시되면 사용자는 주소를 입력해도 된다는 점을 알고 있으므로 앞으로 진행될 상황을 자신이 제어할 수 있다고 생각합니다. 마찬가지로 푸시 또는 이메일을 통해 알림을 받거나 카메라 및 마이크 액세스를 허용하지 않고 회의에 참여하는 중에서 선택할 수 있는 경우 사용자는 자신이 선택하는 옵션의 장단점을 더 자연스럽게 이해할 수 있습니다.
차단 상태가 되면 복구하기가 어렵습니다.
사용자가 권한 제한 기능에 대한 액세스를 영구적으로 허용하지 않기로 결정하면 브라우저는 이 결정을 따릅니다. 액세스 권한을 계속 요청할 수 있다면 악의적인 사이트에서 사용자에게 계속 메시지를 표시할 수 있습니다. 따라서 기능의 차단된 상태에서 복구하려면 의도적으로 사용자가 약간의 노력을 기울여야 합니다. 따라서 많은 사용자가 액세스를 허용하지 않을 가능성이 높은 상황에서는 사용자에게 권한을 요청하지 마세요.
이를 위한 일반적인 방법은 이른바 사전 프롬프트를 사용하여 사용자에게 무슨 일이 일어날지, 애플리케이션에 요청할 기능이 필요한 이유를 설명하는 것입니다. 사용자가 이러한 사전 메시지에 긍정적으로 반응하는 경우에만 브라우저의 권한 메시지를 트리거해야 합니다. 사용자가 이러한 상태에서 합법적으로 복구해야 하는 경우가 있습니다. 자세한 내용은 사용자가 차단 상태에서 복구할 수 있도록 지원하기 섹션을 참고하세요.
서드 파티 콘텐츠에 주의하기
예상치 못한 권한 메시지 소스가 있습니다. 사이트에 서드 파티 스크립트를 포함하면 의도하지 않은 권한 메시지가 표시될 수 있습니다. 특히 이러한 메시지가 이미 설명된 권장사항을 따르지 않는 경우 웹사이트 사용자 환경에 영향을 줄 수 있습니다. 사용자 환경을 계속 관리하려면 자체 코드에 추가하는 서드 파티 라이브러리 및 스크립트의 문서를 주의 깊게 읽어야 합니다.
권한을 요청해야 하는 경우
다음은 이미 설명한 권장사항에 따라 권한을 요청하는 것이 효과적인 몇 가지 상황의 예입니다.
- 사용자가 주소를 수동으로 입력하는 양식 입력란 옆에 있는 '내 위치 사용' 버튼을 클릭한 후
- 사용자가 동영상 채널 또는 게시물을 구독하고 업데이트가 휴대전화나 데스크톱에 이메일이나 알림으로 전송될 수 있음을 설명하는 대화상자에서 확인 버튼을 클릭한 후
- 사용자가 영상 통화에 참여할 준비를 하는 페이지에 도착한 후 사전 프롬프트에서 내 모습이 보이고 내 목소리가 들리기를 원하는지 긍정적으로 답변합니다(이 Google Meet의 사례 연구 참고).
권한 요청 코드 패턴
API를 사용하기 위한 권한을 얻는 것은 API에 따라 다양한 방법을 통해 이루어집니다. 일부 (일반적으로 이전) API는 사용자가 처음 API를 사용하려고 할 때 브라우저에서 자동으로 권한을 요청하는 모델을 사용합니다. 예를 들어 Geolocation API에서 navigator.geolocation.getCurrentPosition()
를 호출할 때는
try {
navigator.geolocation.getCurrentPosition((pos) => console.log(pos));
} catch (error) {
console.error(error);
}
다른 API는 먼저 정적 메서드를 사용하여 권한을 명시적으로 요청해야 하는 모델을 사용합니다. 알림을 허용하는 Notification.requestPermission()
또는 Device Orientation Events API의 일부인 덜 일반적인 DeviceOrientationEvent.requestPermission()
가 좋은 예입니다. 일부 브라우저는 지정된 API에 자동으로 권한을 부여할 수 있습니다. 예를 들어 Chrome은 항상 기기 방향에 대한 액세스를 허용하지만 Safari는 메시지를 표시합니다.
const result = await DeviceOrientationEvent.requestPermission();
console.log(`The user's decision when prompted to use the Device Orientation
Events API was: ${result}.`);
if (result === 'granted') {
/* Use the API. */
}
권한 상태를 확인하는 방법
특정 API를 사용할 수 있는지 확인하려면 Permissions API의 navigator.permissions.query()
메서드를 사용합니다.
const result = await navigator.permissions.query({ name: 'geolocation' });
console.log(`The result of querying for the Geolocation API is:
${result.state}.`);
if (result.state === 'granted') {
// Use the API.
}
사용자가 차단된 상태에서 복구할 수 있도록 지원
사용자가 액세스 문제를 해결할 수 있도록 Permissions API를 사용하여 액세스가 차단되었음을 감지하고 설정을 변경하는 방법에 관한 가이드를 제공합니다. 예를 들어 사용자가 권한 제한 기능과 연결된 UI 요소와 상호작용할 때는 이전 섹션에 설명된 패턴을 사용하고 문제 해결 대화상자를 엽니다. 권한 상태를 변경하는 정확한 단계는 브라우저마다 다르므로 사용자 에이전트 문자열과 제품에서 가장 일반적으로 사용되는 브라우저를 기반으로 일치하는 설명을 제공하는 것이 좋습니다.
Chrome에서 사용자는 주소 표시줄 왼쪽에 있는 '조정' 아이콘을 클릭하여 사이트 설정으로 이동해야 합니다. 여기에서 각 권한을 사용 설정할 수 있습니다. 경우에 따라 기능을 사용하기 전에 페이지를 새로고침해야 할 수 있습니다. 이 경우 창 상단에 메시지 막대가 표시되며 해당 버튼을 클릭하면 새로고침을 제안합니다.
권한을 제어하기 위한 유사한 UI는 다른 브라우저에도 있습니다(예: Firefox에서 작동 방식 보기).