Overview

데이터 업데이트

Google 세이프 브라우징 v5가 v4 (특히 v4 업데이트 API)에 비해 크게 개선된 한 가지 사항은 데이터 최신성과 적용 범위입니다. 보호 기능은 클라이언트가 유지하는 로컬 데이터베이스에 크게 의존하므로 로컬 데이터베이스 업데이트의 지연과 크기가 보호 누락의 주요 원인입니다. v4에서는 일반적인 클라이언트가 최신 버전의 위협 목록을 입수하는 데 20~50분이 소요됩니다. 유감스럽게도 피싱 공격은 빠르게 확산됩니다. 2021년 기준으로 공격을 수행하는 사이트의 60% 가 10분 이내에 지속됩니다. FireEye의 분석에 따르면 피싱 방지를 위한 누락의 약 25~30% 가 이러한 데이터 비활성으로 인해 발생합니다. 또한 일부 기기는 Google 세이프 브라우징 위협 목록 전체를 관리할 수 없습니다. 세이프 브라우징 위협 목록은 시간이 지날수록 계속 증가하고 있습니다.

v5에서는 실시간 보호라는 작업 모드가 도입되었습니다. 이렇게 하면 위의 데이터 비활성 문제를 회피할 수 있습니다. v4에서 클라이언트는 로컬 데이터베이스를 다운로드하고 유지관리하고, 로컬로 다운로드된 위협 목록을 대상으로 검사를 수행한 다음, 부분적으로 일치하는 접두사가 있는 경우 전체 해시를 다운로드하기 위한 요청을 수행해야 합니다. v5에서는 클라이언트가 위협 목록의 로컬 데이터베이스를 계속 다운로드하고 유지해야 하지만, 이제 클라이언트가 정상일 가능성이 있는 사이트 목록 (글로벌 캐시라고 함)을 다운로드하고, 이 글로벌 캐시에 대한 로컬 검사와 로컬 위협 목록 검사를 모두 수행해야 하며, 마지막으로 위협 목록에 대한 부분적인 접두사 일치가 있거나 글로벌 캐시에 전체 해시를 다운로드하기 위해 일치하지 않는 요청이 있을 때 작업을 수행해야 합니다. (고객이 요구하는 로컬 처리에 대한 자세한 내용은 아래 제공된 절차를 참조하세요.) 이는 기본 설정 허용에서 기본 확인으로의 전환을 나타내며, 이는 웹에서 위협이 더 빠르게 전파되는 것을 고려하여 보호 기능을 개선할 수 있습니다. 다시 말해, 이 프로토콜은 실시간에 가까운 보호를 제공하도록 고안된 프로토콜로, 고객이 최신 Google 세이프 브라우징 데이터를 활용할 수 있도록 하는 것을 목표로 합니다.

IP 개인정보 보호

Google 세이프 브라우징 (v4 또는 v5)은 요청을 처리하는 과정에서 사용자의 ID와 관련된 어떠한 항목도 처리하지 않습니다. 쿠키는 전송되면 무시됩니다. Google은 요청의 원래 IP 주소를 알고 있지만 Google은 필수적인 네트워킹 요구사항 (즉, 응답 전송)과 DoS 방지 목적으로만 IP 주소를 사용합니다.

v5와 동시에 Safe Browsing Oblivious HTTP Gateway API라고 하는 호환 API가 도입됩니다. 이는 Oblivious HTTP를 통해 Google로부터 최종 사용자의 IP 주소를 숨깁니다. 이 방식은 충돌하지 않는 서드 파티가 암호화된 버전의 사용자 요청을 처리한 다음 이를 Google에 전달하는 방식으로 작동합니다. 따라서 타사는 IP 주소에만 액세스할 수 있고 Google은 요청의 콘텐츠에만 액세스할 수 있습니다. 서드 파티는 Oblivious HTTP Relay (예: Fastly에서 제공하는 서비스)를, Google은 Oblivious HTTP Gateway를 운영합니다. 이는 선택적 컴패니언 API입니다. Google 세이프 브라우징과 함께 사용하는 경우 최종 사용자의 IP 주소가 더 이상 Google에 전송되지 않습니다.

허용되는 사용

Safe Browsing API는 비상업용 (즉, '판매 또는 수익 창출용이 아님') 전용입니다. 상업적 목적의 해결 방법이 필요한 경우 Web Risk를 참고하세요.

가격 책정

모든 Google Safe Browsing API는 무료입니다.

할당량

Safe Browsing API를 사용 설정하면 개발자에게 기본 사용 할당량이 할당됩니다. 현재 할당 및 사용량은 Google Developer Console에서 확인할 수 있습니다. 현재 할당된 할당량을 초과하여 사용할 것으로 예상되는 경우 Play Console의 할당량 인터페이스에서 추가 할당량을 요청할 수 있습니다. Google은 이러한 요청을 검토하며, 서비스 가용성이 모든 사용자의 요구를 충족할 수 있도록 할당량 상향 조정을 신청하려면 연락해 주시기 바랍니다.

적절한 URL

Google 세이프 브라우징은 브라우저의 주소 표시줄에 표시되는 URL에 대해 작동하도록 설계되었습니다. 이는 하위 리소스 (예: HTML 파일에서 참조하는 JavaScript나 이미지 또는 JavaScript에 의해 시작된 WebSocket URL)를 확인하는 데 사용하도록 설계되지 않았습니다. 이러한 하위 리소스 URL은 Google 세이프 브라우징과 대조할 수 없습니다.

URL을 방문하면 리디렉션 (예: HTTP 301)되는 경우 리디렉션된 URL을 Google 세이프 브라우징과 대조하는 것이 좋습니다. History.pushState와 같은 클라이언트 측 URL 조작으로 인해 새 URL이 Google 세이프 브라우징과 대조되지 않습니다.

사용자 경고

Google 세이프 브라우징을 사용하여 사용자에게 특정 웹페이지의 위험에 관해 경고하는 경우 다음 가이드라인이 적용됩니다.

이 가이드라인은 페이지가 안전하지 않은 웹 리소스임을 100% 확실히 알 수 없으며 경고는 단지 잠재적인 위험을 식별할 뿐임을 명확히 하여 사용자와 Google 모두를 오해로부터 보호하는 데 도움이 됩니다.

• 사용자에게 표시되는 경고에서 문제의 페이지가 안전하지 않은 웹 리소스라는 믿음을 사용자에게 유도해서는 안 됩니다. 식별된 페이지 또는 페이지가 사용자에게 초래할 수 있는 잠재적인 위험을 언급할 때는 의심됨, 잠재적, 가능성, 가능성과 같은 표현을 사용하여 경고를 표시해야 합니다.
• 경고를 받은 사용자는 다양한 위협에 관한 Google의 정의를 검토하여 자세한 내용을 알 수 있어야 합니다. 다음 링크를 사용하는 것이 좋습니다.
  • 소셜 엔지니어링: https://developers.google.com/search/docs/monitor-debug/security/social-engineering
  • 멀웨어 및 원치 않는 소프트웨어: https://developers.google.com/search/docs/monitor-debug/security/malware
  • 잠재적으로 위험한 애플리케이션 (Android만 해당): https://developers.google.com/android/play-protect/potentially-harmful-applications
• 세이프 브라우징 서비스에서 위험한 것으로 식별된 페이지에 대한 경고를 표시하는 경우, 세이프 브라우징 권고 링크와 함께 'Google에서 제공하는 권고사항' 행을 포함하여 Google을 저작자로 표시해야 합니다. 제품이 다른 소스를 기반으로도 경고를 표시하는 경우 Google 이외의 데이터에서 파생된 경고에 Google 기여 분석을 포함해서는 안 됩니다.

• 제품 설명서를 통해 사용자에게 Google 세이프 브라우징이 제공하는 보호 기능이 완벽하지 않음을 명시해야 합니다. 거짓양성 (위험한 사이트로 신고된 안전 사이트)과 거짓음성 (위험한 사이트로 신고되지 않은 사이트)이 모두 발생할 가능성이 있음을 알려야 합니다. 다음 표현을 사용하는 것이 좋습니다.

  Google에서는 안전하지 않은 웹 리소스에 관한 가장 정확한 최신 정보를 제공하기 위해 노력하고 있습니다. 그러나 Google은 정보가 포괄적이고 오류가 없음을 보증할 수 없습니다. 일부 위험한 사이트는 식별되지 않을 수 있으며 일부 안전한 사이트는 오류로 식별될 수 있습니다.

실시간 모드

클라이언트가 실시간 모드에서 Google 세이프 브라우징 v5를 사용하기로 선택하는 경우 클라이언트는 로컬 데이터베이스에 (i) 호스트-접미사/경로-접두사 URL 표현식의 SHA256 해시로 형식이 지정된 정상 사이트의 글로벌 캐시, (ii) 호스트-접미사/경로-접두사 URL 표현식의 SHA256 해시 접두사로 형식이 지정된 위협 목록 집합을 유지합니다. 클라이언트가 특정 URL을 확인하려고 할 때마다 전역 캐시를 사용하여 로컬 검사를 수행하는 것을 개괄적으로 설명합니다. 이 검사를 통과하면 로컬 위협 목록 검사가 수행됩니다. 그렇지 않으면 클라이언트는 아래에 설명된 대로 실시간 해시 확인을 계속 진행합니다.

클라이언트는 로컬 데이터베이스 외에 로컬 캐시를 유지합니다. 이러한 로컬 캐시는 영구 저장소에 있을 필요가 없으며 메모리 부족 시 삭제될 수 있습니다.

절차의 자세한 사양은 아래에서 확인할 수 있습니다.

로컬 목록 모드

클라이언트가 이 모드에서 Google 세이프 브라우징 v5를 사용하도록 선택하는 경우 클라이언트 동작은 v5의 개선된 API 노출 영역을 사용한다는 점을 제외하면 v4 업데이트 API와 유사합니다. 클라이언트는 로컬 데이터베이스에 호스트 접미사/경로 접두사 URL 표현식의 SHA256 해시 접두사로 형식이 지정된 일련의 위협 목록을 유지합니다. 클라이언트가 특정 URL을 확인하기를 원할 때마다 로컬 위협 목록을 사용하여 검사를 수행합니다. 일치하는 항목이 있는 경우에만 클라이언트는 서버에 연결하여 확인을 계속합니다.

위와 마찬가지로 클라이언트는 영구 저장소에 있을 필요가 없는 로컬 캐시도 유지합니다.

저장용량 없음 실시간 모드

클라이언트가 저장용량 없음 실시간 모드에서 Google 세이프 브라우징 v5를 사용하기로 선택하는 경우 어떠한 로컬 데이터베이스도 유지할 필요가 없습니다. 클라이언트는 특정 URL을 확인하려는 경우 항상 서버에 연결하여 검사를 수행합니다. 이 모드는 v4 Lookup API의 클라이언트가 구현할 수 있는 것과 유사합니다.

URL 표준화

URL을 확인하기 전에 클라이언트는 해당 URL에 대해 어느 정도 표준화를 수행해야 합니다.

먼저 클라이언트가 URL을 파싱하고 RFC 2396에 따라 유효하게 만들었다고 가정합니다. URL에 국제화된 도메인 이름 (IDN)이 사용되는 경우 클라이언트는 URL을 ASCII 퓨니코드 표현으로 변환해야 합니다. URL에는 경로 구성요소가 포함되어야 합니다. 즉, 도메인 다음에 슬래시가 하나 이상 있어야 합니다 (http://google.com 대신 http://google.com/).

먼저 URL에서 탭 (0x09), CR (0x0d) 및 LF (0x0a) 문자를 삭제합니다. 이러한 문자의 이스케이프 시퀀스를 삭제하지 마세요 (예: %0a).

둘째, URL이 프래그먼트로 끝나면 프래그먼트를 제거합니다. 예를 들어 http://google.com/#frag를 http://google.com/로 단축합니다.

셋째, 더 이상 퍼센트 이스케이프 처리되지 않을 때까지 URL을 반복적으로 퍼센트 이스케이프 취소합니다. 이 경우 URL이 유효하지 않게 될 수 있습니다.

호스트 이름을 정규화하려면 다음 안내를 따르세요.

URL에서 호스트 이름을 추출한 후 다음을 수행합니다.

1. 모든 선행 및 후행 점은 삭제합니다.
2. 연속된 점을 단일 점으로 바꿉니다.
3. 호스트 이름을 IPv4 주소로 파싱할 수 있는 경우 점 4개로 구분된 십진수 값으로 정규화합니다. 클라이언트는 8진수, 16진수 및 4개 미만의 구성요소를 포함하여 모든 법적 IP 주소 인코딩을 처리해야 합니다.
4. 호스트 이름을 대괄호로 묶은 IPv6 주소로 파싱할 수 있는 경우 구성요소에서 불필요한 선행 0을 삭제하고 이중 콜론 구문을 사용하여 0 구성요소를 축소하여 정규화합니다. 예를 들어 [2001:0db8:0000::1]는 [2001:db8::1]로 변환해야 합니다. 호스트 이름이 다음 두 가지 특수 IPv6 주소 유형 중 하나인 경우 IPv4로 변환합니다.
   • 1.2.3.4로 변환되어야 하는 IPv4 매핑된 IPv6 주소(예: [::ffff:1.2.3.4])
   • 잘 알려진 접두사 64:ff9b::/96을 사용하는 NAT64 주소(예: [64:ff9b::1.2.3.4]). 1.2.3.4로 변환해야 합니다.
5. 전체 문자열을 소문자로 표기합니다.

경로를 정규화하려면 다음 단계를 따르세요.

1. /./를 /로 바꾸고 앞의 경로 구성요소와 함께 /../를 삭제하여 경로의 /../ 및 /./ 시퀀스를 확인합니다.
2. 연속된 슬래시 실행을 단일 슬래시 문자로 바꿉니다.

이러한 경로 표준화를 쿼리 매개변수에 적용하지 마세요.

URL에서 ASCII 32 <= 127, # 또는 %인 모든 문자를 퍼센트 이스케이프 처리합니다. 이스케이프는 대문자 16진수를 사용해야합니다.

호스트-접미사 경로-접두사 표현식

URL이 표준화되면 다음 단계는 접미사/접두사 표현식을 만드는 것입니다. 각 접미사/접두사 표현식은 호스트 접미사 (또는 전체 호스트)와 경로 접두사 (또는 전체 경로)로 구성됩니다.

클라이언트는 최대 30개의 서로 다른 호스트 접미사와 경로 접두사 조합을 형성합니다. 이러한 조합에서는 URL의 호스트 및 경로 구성요소만 사용합니다. 스키마, 사용자 이름, 비밀번호, 포트는 삭제됩니다. URL에 검색어 매개변수가 포함된 경우, 하나 이상의 조합에 전체 경로와 검색어 매개변수가 포함됩니다.

호스트의 경우 클라이언트는 최대 5개의 다른 문자열을 시도합니다. 각 필터는 다음과 같습니다.

• 호스트 이름이 IPv4 또는 IPv6 리터럴이 아닌 경우 eTLD+1 도메인으로 시작하고 연속적인 선행 구성요소를 추가하여 최대 4개의 호스트 이름을 구성합니다. eTLD+1은 공개 접미사 목록을 바탕으로 판단해야 합니다. 예를 들어 a.b.example.com의 eTLD+1 도메인은 example.com의 eTLD+1 도메인과 하나의 추가 호스트 구성요소 b.example.com가 있는 호스트가 됩니다.
• URL의 정확한 호스트 이름입니다. 앞의 예에 따라 a.b.example.com가 확인됩니다.

경로의 경우 클라이언트는 최대 6개의 다른 문자열을 시도합니다. 각 유형은 다음과 같습니다.

• 쿼리 매개변수를 포함한 URL의 정확한 경로입니다.
• 쿼리 매개변수가 없는 URL의 정확한 경로입니다.
• 루트 (/)에서 시작하여 후행 슬래시를 포함하여 경로 구성요소를 연속적으로 추가하여 형성된 4개의 경로입니다.

다음 예시는 확인 동작을 보여줍니다.

URL http://a.b.com/1/2.html?param=1에 대해 클라이언트는 다음과 같은 가능한 문자열을 시도합니다.

a.b.com/1/2.html?param=1
a.b.com/1/2.html
a.b.com/
a.b.com/1/
b.com/1/2.html?param=1
b.com/1/2.html
b.com/
b.com/1/

URL http://a.b.c.d.e.f.com/1.html에 대해 클라이언트는 다음과 같은 가능한 문자열을 시도합니다.

a.b.c.d.e.f.com/1.html
a.b.c.d.e.f.com/
c.d.e.f.com/1.html
c.d.e.f.com/
d.e.f.com/1.html
d.e.f.com/
e.f.com/1.html
e.f.com/
f.com/1.html
f.com/

참고: 마지막 5개의 호스트 이름과 전체 호스트 이름만 사용하므로 b.c.d.e.f.com은 건너뜁니다.

URL http://1.2.3.4/1/에 대해 클라이언트는 다음과 같은 가능한 문자열을 시도합니다.

1.2.3.4/1/
1.2.3.4/

URL http://example.co.uk/1에 대해 클라이언트는 다음과 같은 가능한 문자열을 시도합니다.

example.co.uk/1
example.co.uk/

해싱

Google 세이프 브라우징은 SHA256만 해시 함수로 사용합니다. 위의 표현식에 이 해시 함수를 적용해야 합니다.

전체 32바이트 해시는 상황에 따라 4바이트, 8바이트 또는 16바이트로 잘립니다.

• hashes.search 메서드를 사용할 때는 현재 요청의 해시를 정확히 4바이트로 잘라야 합니다. 이 요청에서 추가 바이트를 전송하면 사용자 개인 정보가 침해될 수 있습니다.

• hashList.get 메서드 또는 hashLists.batchGet 메서드를 사용하여 로컬 데이터베이스의 목록을 다운로드할 때 서버에서 전송하는 해시 길이는 목록의 특성과 desired_hash_length 매개변수로 전달되는 해시 길이에 대한 클라이언트의 환경설정 모두에 영향을 받습니다.

실시간 URL 확인 절차

이 절차는 클라이언트가 실시간 작업 모드를 선택할 때 사용됩니다.

이 절차는 단일 URL u를 사용하고 SAFE, UNSAFE 또는 UNSURE를 반환합니다. SAFE가 반환되면 URL은 Google 세이프 브라우징에서 안전한 것으로 간주됩니다. UNSAFE가 반환되면 해당 URL은 Google 세이프 브라우징에서 잠재적으로 안전하지 않은 것으로 간주되며 최종 사용자에게 경고를 표시하거나, 수신된 메시지를 스팸 폴더로 옮기거나, 계속하기 전에 사용자에게 추가 확인을 요청하는 등 적절한 조치를 취해야 합니다. UNSURE가 반환되면 나중에 다음 로컬 확인 절차를 사용해야 합니다.

1. expressions를 URL u에서 생성된 접미사/접두사 표현식의 목록이라고 가정합니다.
2. expressionHashes를 목록이라고 가정합니다. 여기서 요소는 expressions에 있는 각 표현식의 SHA256 해시입니다.
3. expressionHashes의 각 hash에 대해 다음을 실행합니다.
   1. 전역 캐시에서 hash를 찾을 수 있으면 UNSURE를 반환합니다.
4. expressionHashPrefixes를 목록이라고 가정해 보겠습니다. 여기서 요소는 expressionHashes에 있는 각 해시의 처음 4바이트입니다.
5. expressionHashPrefixes의 각 expressionHashPrefix에 대해 다음을 실행합니다.
   1. 로컬 캐시에서 expressionHashPrefix를 찾습니다.
   2. 캐시된 항목이 발견된 경우:
      1. 현재 시간이 만료 시간보다 큰지 확인합니다.
      2. 금액이 더 큰 경우:
         1. 찾은 캐시된 항목을 로컬 캐시에서 삭제합니다.
         2. 루프를 계속 진행합니다.
      3. 이보다 크지 않은 경우:
         1. 이 특정 expressionHashPrefix를 expressionHashPrefixes에서 삭제합니다.
         2. expressionHashes 내의 상응하는 전체 해시가 캐시된 항목에서 찾을 수 있는지 확인합니다.
         3. 발견되면 UNSAFE를 반환합니다.
         4. 찾을 수 없는 경우 루프를 계속 진행합니다.
   3. 캐시된 항목을 찾을 수 없는 경우 루프를 계속 진행합니다.
6. RPC SearchHashes 또는 REST 메서드 hashes.search를 사용하여 expressionHashPrefixes를 Google 세이프 브라우징 v5 서버로 전송합니다. 네트워크 오류, HTTP 오류 등의 오류가 발생하면 UNSURE를 반환합니다. 그렇지 않은 경우 응답은 SB 서버에서 수신한 response라고 가정합니다. 이 목록은 위협의 특성 (소셜 엔지니어링, 멀웨어 등) 및 캐시 만료 시간 expiration을 식별하는 일부 보조 정보와 함께 전체 해시의 목록입니다.
7. response의 각 fullHash에 대해 다음을 실행합니다.
   1. expiration와 함께 fullHash를 로컬 캐시에 삽입합니다.
8. response의 각 fullHash에 대해 다음을 실행합니다.
   1. isFound를 expressionHashes에서 fullHash를 찾은 결과라고 가정합니다.
   2. isFound가 False인 경우 루프를 계속 진행합니다.
   3. isFound가 True이면 UNSAFE를 반환합니다.
9. SAFE를 반환합니다.

LocalThreat List URL 확인 절차

이 절차는 클라이언트가 로컬 목록 작업 모드를 선택할 때 사용됩니다. 클라이언트가 위의 RealTimeCheck 프로시져에서 UNSURE 값을 반환할 때도 사용됩니다.

이 절차는 단일 URL u를 사용하고 SAFE 또는 UNSAFE를 반환합니다.

1. expressions를 URL u에서 생성된 접미사/접두사 표현식의 목록이라고 가정합니다.
2. expressionHashes를 목록이라고 가정합니다. 여기서 요소는 expressions에 있는 각 표현식의 SHA256 해시입니다.
3. expressionHashPrefixes를 목록이라고 가정해 보겠습니다. 여기서 요소는 expressionHashes에 있는 각 해시의 처음 4바이트입니다.
4. expressionHashPrefixes의 각 expressionHashPrefix에 대해 다음을 실행합니다.
   1. 로컬 캐시에서 expressionHashPrefix를 찾습니다.
   2. 캐시된 항목이 발견된 경우:
      1. 현재 시간이 만료 시간보다 큰지 확인합니다.
      2. 금액이 더 큰 경우:
         1. 찾은 캐시된 항목을 로컬 캐시에서 삭제합니다.
         2. 루프를 계속 진행합니다.
      3. 이보다 크지 않은 경우:
         1. 이 특정 expressionHashPrefix를 expressionHashPrefixes에서 삭제합니다.
         2. expressionHashes 내의 상응하는 전체 해시가 캐시된 항목에서 찾을 수 있는지 확인합니다.
         3. 발견되면 UNSAFE를 반환합니다.
         4. 찾을 수 없는 경우 루프를 계속 진행합니다.
   3. 캐시된 항목을 찾을 수 없는 경우 루프를 계속 진행합니다.
5. expressionHashPrefixes의 각 expressionHashPrefix에 대해 다음을 실행합니다.
   1. 로컬 위협 목록 데이터베이스에서 expressionHashPrefix를 찾습니다.
   2. 로컬 위협 목록 데이터베이스에서 expressionHashPrefix를 찾을 수 없는 경우 expressionHashPrefixes에서 삭제합니다.
6. RPC SearchHashes 또는 REST 메서드 hashes.search를 사용하여 expressionHashPrefixes를 Google 세이프 브라우징 v5 서버로 전송합니다. 네트워크 오류, HTTP 오류 등의 오류가 발생하면 SAFE를 반환합니다. 그렇지 않은 경우 응답은 SB 서버에서 수신한 response라고 가정합니다. 이 목록은 위협의 특성 (소셜 엔지니어링, 멀웨어 등) 및 캐시 만료 시간 expiration을 식별하는 일부 보조 정보와 함께 전체 해시의 목록입니다.
7. response의 각 fullHash에 대해 다음을 실행합니다.
   1. expiration와 함께 fullHash를 로컬 캐시에 삽입합니다.
8. response의 각 fullHash에 대해 다음을 실행합니다.
   1. isFound를 expressionHashes에서 fullHash를 찾은 결과라고 가정합니다.
   2. isFound가 False인 경우 루프를 계속 진행합니다.
   3. isFound가 True이면 UNSAFE를 반환합니다.
9. SAFE를 반환합니다.

로컬 데이터베이스가 없는 실시간 URL 확인 절차

이 절차는 클라이언트가 스토리지 없는 실시간 작업 모드를 선택할 때 사용됩니다.

이 절차는 단일 URL u를 사용하고 SAFE 또는 UNSAFE를 반환합니다.

1. expressions를 URL u에서 생성된 접미사/접두사 표현식의 목록이라고 가정합니다.
2. expressionHashes를 목록이라고 가정합니다. 여기서 요소는 expressions에 있는 각 표현식의 SHA256 해시입니다.
3. expressionHashPrefixes를 목록이라고 가정해 보겠습니다. 여기서 요소는 expressionHashes에 있는 각 해시의 처음 4바이트입니다.
4. expressionHashPrefixes의 각 expressionHashPrefix에 대해 다음을 실행합니다.
   1. 로컬 캐시에서 expressionHashPrefix를 찾습니다.
   2. 캐시된 항목이 발견된 경우:
      1. 현재 시간이 만료 시간보다 큰지 확인합니다.
      2. 금액이 더 큰 경우:
         1. 찾은 캐시된 항목을 로컬 캐시에서 삭제합니다.
         2. 루프를 계속 진행합니다.
      3. 이보다 크지 않은 경우:
         1. 이 특정 expressionHashPrefix를 expressionHashPrefixes에서 삭제합니다.
         2. expressionHashes 내의 상응하는 전체 해시가 캐시된 항목에서 찾을 수 있는지 확인합니다.
         3. 발견되면 UNSAFE를 반환합니다.
         4. 찾을 수 없는 경우 루프를 계속 진행합니다.
   3. 캐시된 항목을 찾을 수 없는 경우 루프를 계속 진행합니다.
5. RPC SearchHashes 또는 REST 메서드 hashes.search를 사용하여 expressionHashPrefixes를 Google 세이프 브라우징 v5 서버로 전송합니다. 네트워크 오류, HTTP 오류 등의 오류가 발생하면 SAFE를 반환합니다. 그렇지 않은 경우 응답은 SB 서버에서 수신한 response라고 가정합니다. 이 목록은 위협의 특성 (소셜 엔지니어링, 멀웨어 등) 및 캐시 만료 시간 expiration을 식별하는 일부 보조 정보와 함께 전체 해시의 목록입니다.
6. response의 각 fullHash에 대해 다음을 실행합니다.
   1. expiration와 함께 fullHash를 로컬 캐시에 삽입합니다.
7. response의 각 fullHash에 대해 다음을 실행합니다.
   1. isFound를 expressionHashes에서 fullHash를 찾은 결과라고 가정합니다.
   2. isFound가 False인 경우 루프를 계속 진행합니다.
   3. isFound가 True이면 UNSAFE를 반환합니다.
8. SAFE를 반환합니다.

데이터베이스 업데이트

클라이언트는 정기적으로 hashList.get 메서드 또는 hashLists.batchGet 메서드를 호출하여 데이터베이스를 업데이트합니다. 일반적인 클라이언트는 한 번에 여러 목록을 업데이트하려고 하므로 hashLists.batchGet 메서드를 사용하는 것이 좋습니다.

목록은 고유한 이름으로 식별됩니다. 이름은 몇 자 길이의 짧은 ASCII 문자열입니다.

목록이 위협 유형, 플랫폼 유형, 위협 항목 유형의 튜플로 식별되는 V4와 달리 v5 목록에서는 단순히 이름으로 식별됩니다. 이는 여러 v5 리스트가 동일한 위협 유형을 공유할 수 있는 경우 유연성을 제공합니다. 플랫폼 유형과 위협 항목 유형이 v5에서 삭제되었습니다.

목록에서 이름을 선택한 후에는 그 이름이 변경되지 않습니다. 또한 일단 표시된 목록은 삭제되지 않습니다 (목록이 더 이상 유용하지 않은 경우 비게 되지만 계속 존재함). 따라서 Google 세이프 브라우징 클라이언트 코드에 이러한 이름을 하드 코딩하는 것이 적절합니다.

hashList.get 메서드와 hashLists.batchGet 메서드는 모두 증분 업데이트를 지원합니다. 증분 업데이트를 사용하면 대역폭이 절약되고 성능이 향상됩니다. 증분 업데이트는 클라이언트의 목록 버전과 최신 버전 목록 간의 델타를 전송하는 방식으로 작동합니다. (클라이언트가 새로 배포되었고 사용 가능한 버전이 없는 경우 전체 업데이트를 사용할 수 있습니다.) 증분 업데이트에는 삭제 색인과 추가 항목이 포함되어 있습니다. 먼저 클라이언트는 지정된 색인의 항목을 로컬 데이터베이스에서 삭제한 다음 추가를 적용해야 합니다.

마지막으로 손상을 방지하기 위해 클라이언트는 서버에서 제공한 체크섬과 비교하여 저장된 데이터를 확인해야 합니다. 체크섬이 일치하지 않을 때마다 클라이언트는 전체 업데이트를 수행해야 합니다.

목록 콘텐츠 디코딩

모든 목록은 크기를 줄이기 위해 특수 인코딩을 사용하여 게재됩니다. 이 인코딩은 Google 세이프 브라우징 목록에 개념적으로 임의의 정수와 통계적으로 구별할 수 없는 해시 또는 해시 접두사가 포함되어 있음을 인식함으로써 작동합니다. 이 정수를 정렬하고 인접한 차이를 취하면 이 인접한 차이는 어떤 의미에서 '작게' 될 것으로 예상됩니다. Golomb-Rice 인코딩은 이 작은 크기를 악용합니다.

Google 세이프 브라우징 v5에는 4바이트 데이터, 8바이트 데이터, 16바이트 데이터, 32바이트 데이터를 처리하는 4가지 유형이 있습니다. 3개의 연속된 4바이트 정수가 인코딩되는 예를 살펴보겠습니다. k로 표시된 Rice 매개변수를 3으로 가정합니다. 인코딩의 몫은 단순히 k비트 오른쪽으로 이동한 인접한 차이 값입니다. 주어진 정수가 연속적이므로 인접한 차이는 1이고, 3비트 단위로 이동한 후 몫 부분은 0이 됩니다. 최하위 k비트는 001입니다. 0몫은 단일 0비트로 인코딩됩니다. 나머지는 1이며 100으로 인코딩됩니다. 이는 다시 반복되어 비트스트림 01000100을 형성합니다. 결과 비트스트림은 Little Endian을 00100010으로 사용하여 인코딩됩니다. 따라서 다음 데이터에 해당합니다.

rice_parameter: 3
entries_count: 2
encoded_data: "\x22"

32비트 정수에 대한 위의 디코딩 단계 후에는 그 결과를 삭제 인덱스 또는 덧셈으로 직접 사용할 수 있습니다. v4와 달리 나중에 바이트 스왑을 수행할 필요가 없습니다.

사용 가능한 목록

다음 목록은 v5alpha1에서 사용하도록 권장됩니다.

추후에 추가 목록이 제공될 예정이며, 이때 위의 표가 확장됩니다.

업데이트 빈도

클라이언트는 minimum_wait_duration 필드에서 서버의 반환된 값을 검사하고 이를 사용하여 데이터베이스의 다음 업데이트를 예약해야 합니다. 이 값은 0일 수 있으며, 이 경우 클라이언트는 즉시 다른 업데이트를 수행해야 합니다.

변환 목록 업데이트

v4에서는 threatListUpdates.fetch 메서드를 사용하여 목록을 다운로드합니다. v5에서는 hashLists.batchGet 메서드로 전환됩니다.

요청을 다음과 같이 변경해야 합니다.

1. v4 ClientInfo 객체를 완전히 삭제합니다. 전용 필드를 사용하여 클라이언트의 ID를 제공하는 대신 잘 알려진 사용자 에이전트 헤더를 사용하면 됩니다. 이 헤더에 클라이언트 ID를 제공하기 위한 규정된 형식은 없지만 공백 문자나 슬래시 문자로 구분된 원래 클라이언트 ID와 클라이언트 버전을 포함하는 것이 좋습니다.
2. 각 v4 ListUpdateRequest 객체에 대해 다음을 실행합니다.
   • 위 표에서 해당하는 v5 목록 이름을 찾아 v5 요청에 해당 이름을 제공합니다.
   • threat_entry_type 또는 platform_type와 같은 불필요한 필드를 삭제합니다.
   • v4의 state 필드는 v5 versions 필드와 직접 호환됩니다. v4에서 state 필드를 사용하여 서버로 전송되는 동일한 바이트 문자열은 versions 필드를 사용하여 v5에서 간단하게 전송할 수 있습니다.
   • v4 제약 조건의 경우 v5는 SizeConstraints라는 간소화된 버전을 사용합니다. region와 같은 추가 필드는 삭제해야 합니다.

다음과 같이 응답을 변경해야 합니다.

1. v4 enum ResponseType는 단순히 partial_update라는 부울 필드로 대체됩니다.
2. 이제 minimum_wait_duration 필드는 0이거나 생략할 수 있습니다. 이 경우 클라이언트는 즉시 다른 요청을 해야 합니다. 이는 클라이언트가 SizeConstraints에서 최대 업데이트 크기에 대해 최대 데이터베이스 크기보다 작은 제약조건을 지정하는 경우에만 발생합니다.
3. 32비트 정수에 대한 Rice 디코딩 알고리즘을 조정해야 합니다. 차이점은 인코딩된 데이터가 다른 엔디언으로 인코딩된다는 것입니다. v4와 v5 모두에서 32비트 해시 접두사는 사전순으로 정렬됩니다. 하지만 v4에서는 이 접두사가 정렬될 때 리틀 엔디언으로 간주되지만 v5에서는 이 접두사가 정렬될 때 빅 엔디언으로 처리됩니다. 즉, 사전식 정렬은 Big Endian을 사용한 숫자 정렬과 동일하므로 클라이언트가 정렬을 수행할 필요가 없습니다. Chromium v4 구현에서 이러한 종류의 예는 여기에서 확인할 수 있습니다. 이러한 정렬은 제거할 수 있습니다.
4. 다른 해시 길이에는 Rice 디코딩 알고리즘을 구현해야 합니다.

해시 검색 변환

v4에서는 fullHashes.find 메서드를 사용하여 전체 해시를 가져올 수 있습니다. v5에서 이에 상응하는 메서드는 hashes.search 메서드입니다.

요청을 다음과 같이 변경해야 합니다.

1. 정확히 길이가 4바이트인 해시 접두사만 전송하도록 코드를 구조화합니다.
2. v4 ClientInfo 객체를 완전히 삭제합니다. 전용 필드를 사용하여 클라이언트의 ID를 제공하는 대신 잘 알려진 사용자 에이전트 헤더를 사용하면 됩니다. 이 헤더에 클라이언트 ID를 제공하기 위한 규정된 형식은 없지만 공백 문자나 슬래시 문자로 구분된 원래 클라이언트 ID와 클라이언트 버전을 포함하는 것이 좋습니다.
3. client_states 필드를 삭제합니다. 더 이상 필요하지 않습니다.
4. 더 이상 threat_types 및 유사한 필드를 포함하지 않아도 됩니다.

다음과 같이 응답을 변경해야 합니다.

1. minimum_wait_duration 필드가 삭제되었습니다. 고객은 필요에 따라 언제든지 새로운 요청을 제출할 수 있습니다.
2. v4 ThreatMatch 객체가 FullHash 객체로 간소화되었습니다.
3. 캐싱이 단일 캐시 기간으로 단순화되었습니다. 캐시와 상호작용하는 방법은 위 절차를 참조하세요.