CrispGuard의 가림은 로컬에서 처리되나 — 스크린샷이나 녹화에서 확장 자체가 내용을 흘릴 수 있나

CrispGuard는 브라우저 안에서 가림을 그립니다. 키워드는 막대로, 이미지는 자리표시자 블록으로, 영역은 오버레이가 되며 그 어느 것도 서버를 필요로 하지 않습니다. 다만 동작하는 층은 페이지 층이고 운영체제 층이 아니므로, 브라우저 렌더링을 우회하는 캡처에는 가림이 담기지 않을 수 있습니다. 보안 제품이 아니며 화면을 암호화하지도 않습니다.

CrispGuard가 실제로 무엇을 가릴 수 있는지는 제품 페이지에 세 가지 오버레이 형태로 정리되어 있습니다. 이 글의 범위는 더 좁습니다. 가림이 어디서 일어나고, 그 위치가 무엇을 지키며 무엇을 지키지 않는지입니다.

CrispGuard의 데이터 경로 — 브라우저에 남는 것과 밖으로 나가는 것

가림은 확장의 콘텐츠 스크립트, 즉 이미 열려 있는 페이지 안에서 실행됩니다. 텍스트 대조, 이미지 교체, 오버레이 그리기는 모두 로컬 렌더링 단계에서 일어나며, 이 경로 어디에도 페이지를 서버로 올리는 단계가 없습니다.

CrispGuard는 Chrome 확장이며, 실제로 일하는 부분은 콘텐츠 스크립트입니다. 브라우저가 지금 보고 있는 페이지에 주입하는 코드입니다. 문서에 이미 있는 텍스트와 이미지를 읽고, 사용자가 설정한 키워드 목록과 대조한 뒤, 브라우저가 그리려는 내용을 다시 씁니다. 일치한 키워드는 채워진 막대, 단색 블록, 또는 이모지가 됩니다. 일치한 이미지는 자리표시자 블록이 됩니다. 선택한 영역에는 오버레이가 얹힙니다. 아래의 페이지는 그대로 동작합니다. 링크는 열리고, 폼은 전송되고, 스크롤은 영향을 받지 않습니다.

이 단계들은 모두 이미 내려받은 문서에 대한 로컬 작업입니다. 대조 대상은 확장과 함께 저장된 목록이며 서버의 모델이 아니고, 이 경로 어디에도 가림을 위해 페이지를 어딘가로 보내는 단계가 없습니다.

다만 이것은 가림 경로에 대한 주장이고, 무엇을 덮지 않는지 정확히 말할 필요가 있습니다. "로컬 가림"과 "네트워크 요청이 전혀 없음"은 서로 다른 주장입니다. 뒤쪽이 더 강하고 검증도 가능합니다. 이 글은 앞의 것을 뒤의 것으로 승격하지 않습니다. 스토어의 기능 설명에 따르면 가림 판정과 그리기는 사용자의 기기에서 이루어집니다. 확장이 네트워크에서 무엇과 통신하는지(라이선스 확인 등)는 개인정보 처리방침이 정하며, 판단 전에 읽어야 할 문서는 그것입니다. 설계 목표는 가능한 한 많은 데이터를 브라우저 안에 두는 것이고, 구체적인 네트워크 동작은 마케팅 페이지가 아니라 개인정보 처리방침에 적힌 문제입니다.

비교할 만한 대상은 더 강한 주장을 공개한 제품입니다. ContextBlur의 개인정보 처리방침은 100% 로컬 처리와 네트워크 요청 없음을 명시하고, 자동 블러는 사용자가 "Run auto-blur now"를 눌렀을 때만 실행되며, 저장하는 것은 CSS 선택자뿐이고 페이지 내용은 저장하지 않는다고 밝힙니다. 거기서 무엇을 더 읽든, 한 가지 유용한 사실은 확인됩니다. 이 분야에서 "로컬에서 처리한다"는 것은 공급자가 공개하고 검증 요구를 받을 수 있는 주장이며, CrispGuard만의 이야기가 아닙니다. 어느 공급자의 말이든, 이 제품의 말이라도, 자체 설명만으로 믿을 일은 아닙니다.

여기에 경계를 하나 더 붙입니다. 가림이 바꾸는 것은 페이지가 보이는 방식입니다. 페이지를 암호화하지 않고, 브라우저 자체 프로세스로부터 숨기지도 않으며, 잠금 해제된 기기에 접근할 수 있는 사람이 개발자 도구를 열어 DOM을 직접 읽는 것을 막지도 않습니다. CrispGuard는 공유 공간을 위한 프라이버시 편의 기능이며 보안 제품이 아니고, 그렇게 설명되어서도 안 됩니다.

스크린샷이나 화면 녹화를 할 때 가림은 어떻게 되나 — 덮는 것과 덮지 못하는 것

결정하는 것은 캡처 경로뿐입니다. 브라우저가 렌더링한 페이지를 읽는 도구라면 가림은 대개 그 이미지에 포함됩니다. 운영체제의 프레임 버퍼를 읽거나 카메라로 화면을 찍는다면, 확장이 그곳에 가림을 넣을 수는 없습니다.

메커니즘이 결과를 설명합니다. 브라우저 확장은 페이지 렌더링 파이프라인 안에 살면서 DOM과 거기에 적용된 스타일을 고치고, 브라우저가 결과를 그립니다. 캡처 도구는 두 갈래입니다. 하나는 브라우저에 지금 무엇을 보여주는지 물어봅니다. 확장이 이미 바꾼 렌더링 결과를 읽는 것입니다. 다른 하나는 운영체제의 프레임 버퍼, 즉 화면 전체를 합성한 이미지를 읽고 페이지에는 전혀 묻지 않습니다.

플랫폼이 협조할 때 두 번째 갈래가 무엇을 할 수 있는지는 모바일이 보여줍니다. Android의 FLAG_SECURE는 플랫폼 보안 계층에서 스크린샷을 차단하며, 운영체제가 캡처 자체를 거부합니다. Chrome 확장에는 그에 해당하는 계층이 없습니다. 확장이 Windows, macOS, 또는 캡처 장치에 "이 프레임을 거부하라"고 요구할 수 있는 API는 없습니다.

CrispGuard의 가림은 페이지 층의 가시성 제어이며 스크린샷 차단이 아닙니다. 하드웨어 수준에서 캡처를 막아야 한다면 운영체제나 플랫폼이 제공하는 안전한 표시 기법을 쓰십시오. 브라우저 확장이 아닙니다.

실무적 결론은 둘입니다. 첫째, 시험해 보지 않은 캡처에서는 가림이 빠져 있다고 가정하십시오. 둘째, 시험은 저렴합니다. 실제로 쓰는 도구로, 실제로 가려 둔 페이지를 한 번 캡처해 결과를 보면 됩니다.

사이트 잠금 PIN은 어떻게 저장되나 — 직접 확인할 수 있는 신뢰 신호

사이트 잠금 PIN은 솔트가 붙은 해시로 저장되며 평문으로 저장되지 않습니다. 확장의 로컬 저장소를 읽어도 잠금 해제 입력란에 넣을 수 있는 값은 나오지 않습니다. 설정 화면은 평소와 같고, PIN은 잠금 해제할 때만 묻습니다.

사이트 잠금은 PRO 기능으로, 잠근 사이트의 보호를 풀기 전에 PIN을 요구합니다. 확장이 보관하는 것은 그 PIN의 솔트 해시 — PIN을 무작위 값과 함께 단방향 함수에 통과시킨 값 — 이며 PIN 자체가 아닙니다. 따라서 로컬 저장소를 읽어도 바로 쓸 수 있는 비밀은 얻지 못합니다. 솔트도 의미가 있습니다. 같은 PIN을 쓰는 두 설치가 서로 다른 저장값을 만들어 내므로, 저장된 데이터로 두 PIN이 같다는 사실이 드러나지 않습니다.

이 작은 선택은 검증 가능하기 때문에 따져 볼 가치가 있습니다. PIN을 평문으로 저장하는 제품은 저장을 어떻게 생각하는지 말해 줍니다. 해시를 저장하는 제품은 그 저장소가 언젠가 누군가에게 읽힐 것이라고 전제했다는 것을 말해 줍니다. 어느 한쪽만으로 제품이 믿을 만해지지는 않지만, 여는 모든 페이지에 앉아 있는 도구라면 두 번째를 보고 싶습니다.

해시가 하지 못하는 일도 중요합니다. 지키는 것은 저장된 값이지 잠금이 풀린 상태가 아닙니다. 사이트가 이미 풀려 있고 뒤에 누군가 서 있다면 그가 읽는 것은 페이지이고 해시가 아닙니다. 짧은 숫자 PIN은 시도 횟수가 충분하면 맞힐 수 있고, 해시는 몇 번까지 시도할 수 있는지에 대해 아무 말도 하지 않습니다. 해시는 "이 파일을 읽은 공격자가 무엇을 얻는가"라는 한 가지 질문에만 답하며, 그 답은 잘 합니다.

화면 프라이버시 확장을 믿을지 판단하고 있다면, 무엇을 확인해야 하나

다섯 가지 확인으로 대부분 정리됩니다. 개인정보 처리방침이 페이지 내용 전송에 대해 뭐라고 하는지, 가림이 실제 어느 층에서 일어나는지, 어떤 권한을 요구했는지, 자동 감지가 클릭을 기다리는지, 제품이 자기 한계를 인정하는지입니다.

어느 것도 기술적 배경을 요구하지 않습니다. 방침 하나와 권한 목록 하나를 읽으면 됩니다. 여는 모든 페이지를 읽을 수 있는 능력을 도구에 넘기기 전에 그 정도 수고는 합당합니다.

1. 개인정보 처리방침에 페이지 내용, 스크린샷, 방문 기록을 전송하지 않는다고 그대로 적혀 있는가. 이 세 가지를 지목한 방침은 반박 가능한 약속이고, "개인정보를 존중합니다"만 적은 방침은 그렇지 않습니다. 반박할 수 없는 말은 나중에 검증할 수도 없습니다.
2. 가림이 콘텐츠 스크립트나 페이지 층에서 이루어지는가, 아니면 내용이 먼저 서버에 도달해야 하는가. 답은 "로컬"이 구조의 성질인지 설명문의 한 단어인지를 가릅니다. 네트워크가 끊겨도 성립하는 것은 앞쪽뿐입니다.
3. 가림과 무관한 권한 — 클립보드, 요청 가로채기, 기능에 비해 과도한 사이트 접근 — 을 요구하지 않는가. 권한은 현재 버전이 쓰든 쓰지 않든 존재하는 능력입니다. 그래서 목록은 "일어날 수 있는 일"을 말하며, "지금 일어나는 일"만 말하지 않습니다.
4. 자동 감지가 사용자가 직접 실행할 때만 도는가. 기본으로 모든 페이지를 훑는 기능은 클릭을 기다리는 기능과 프라이버시 태도가 다릅니다. 화면에 보이는 결과가 같아도 같지 않습니다.
5. 제품이 한계를 밝히는가("보안 제품이 아니다", "OS 수준 스크린샷은 막지 못한다"). 아니면 캡처 차단을 약속하는가. 경계를 말로 짚는 공급자는 대개 그 경계가 어디인지 생각해 본 쪽입니다. 모든 것을 약속하는 공급자는 틀렸거나 다른 것을 팔고 있습니다.

이것은 점수표가 아니며, 이 글이 CrispGuard를 대신해 채워 주지도 않습니다. 공개 문서로 확인할 수 없는 항목은 미확인으로 두고 개인정보 처리방침을 읽으십시오. 그것이 이 질문에 대한 정직한 답이고, 다음 릴리스 이후에도 참으로 남는 유일한 답입니다.

자주 묻는 질문

CrispGuard가 페이지 내용을 서버로 보내나요?

가림 경로에서는 그럴 필요가 없습니다. 대조는 콘텐츠 스크립트 안에서 확장과 함께 저장된 키워드 목록을 대상으로 이루어지고, 교체는 페이지 자체에 그려지므로 그 경로 어디에서도 페이지를 업로드하지 않습니다. 라이선스 확인 같은 다른 네트워크 요청이 있는지는 개인정보 처리방침이 정하며, 확인해야 할 문서는 그것입니다.

운영체제 스크린샷 도구로 찍었는데 가림이 남아 있나요?

보장되지 않습니다. 운영체제 스크린샷은 운영체제의 프레임 버퍼를 읽고, 확장은 브라우저가 렌더링한 것만 바꾸므로, 남는지는 가림이 켜져 있는지가 아니라 캡처 경로에 달려 있습니다. 브라우저의 렌더링 결과를 거치는 캡처라면 보통 가림도 포함됩니다.

화면 녹화 도구로 찍으면 가림이 담기나요?

녹화 도구의 캡처 방식에 따릅니다. 렌더링된 페이지나 브라우저 컴포지터를 읽는 도구는 보통 오버레이를 포함하지만, 운영체제 수준에서 화면을 가져오는 도구는 완전히 우회할 수 있습니다. CrispGuard의 설정으로 바꿀 수 있는 일이 아닙니다. 제약은 확장이 아니라 캡처 경로에 있습니다.

사이트 잠금 PIN을 잊으면 확장이 평문으로 보여주나요?

아니요. 저장되는 것은 PIN의 솔트 해시뿐이므로 확장의 로컬 저장소를 읽어도 PIN은 드러나지 않습니다. 이는 저장된 것을 지키는 이야기이고, 보이는 것을 지키는 이야기가 아닙니다. 이미 잠금이 풀려 있고 누군가 화면을 보고 있다면 PIN은 무관합니다.

화면 프라이버시 확장이 정보 보호 필름을 대신할 수 있나요?

아니요. 프라이버시 필름은 물리적 화면의 시야각을 좁혀 옆 사람이 아예 읽을 수 없게 하지만, 확장은 브라우저 안의 픽셀만 바꿉니다. 필름은 화면에 있는 모든 것 — 다른 앱, 알림, 화상 통화 — 을 가리지만, 브라우저 확장은 거기까지 닿지 못합니다. 위의 경계 문단이 말하는 것이 그것입니다. 페이지 층의 제어는 스크린샷 차단이 아닙니다.

정말로 스크린샷을 막아야 한다면 무엇을 써야 하나요?

플랫폼 기법이지 브라우저 확장이 아닙니다. Android의 FLAG_SECURE, DRM으로 보호되는 재생 경로, 캡처를 비활성화하는 관리 기기 정책은 모두 운영체제나 플랫폼 층에서 동작합니다. 스크린샷이 실제로 지나가는 층이 바로 그곳입니다. 대부분의 공유 공간 상황에서는 프라이버시 필름과 화면을 돌려 두는 것이 현실적인 답입니다.

← 전체 글