구글 크롬 광고 차단앱의 종말이 다가오고 있다.

2018년 10월 구글 크롬 확장 프로그램 API 가 버전3으로 업데이트가 됩니다.

이와 함께 구글의 오픈소스 브라우저인 크로미움에도 이 업데이트가 반영됩니다.

크로미움에 반영된 기술들은 특별한 경우가 아니면 대부분 크롬 정식 버전에 반영됩니다.

일종의 오픈소스 베타테스트를 겸하는 크로미움에 확장 프로그램 API 의 최신 업데이트가 반영되면서 확장 프로그램 개발자들과, 보안 업계에서는 우려가 쏱아졌습니다.

크롬 확장 프로그램 API 중

webRequest API 에 대한 정책 변경으로 인해 크롬 확장 앱 형태로 제공되는

광고 차단 앱, 악성코드 탐지 및 차단 앱, 백신 프로그램, 프라이버시 보호 앱(자녀보호 앱 등) 과 같은 앱들이 사용 불가능해질 가능성이 생겼기 때문입니다.

webRequest API 는 크롬의 웹 트래픽을 실시간으로 모니터링, 분석해서 데이터를 가로채거나 차단, 수정을 할 수 있도록 해주는 API 입니다.

웹페이지를 위변조할 수 있는 가능성이 생기기 때문에 보안 이슈가 있기는 했지만, 활용성이 워낙 크기 때문에 그동안 유지가 되어왔던 측면이 있습니다.

크롬 확장 형태로 실행되는 백신, 악성코드 차단, 광고 차단 앱 등에 이 API를 이용하지만, 그 반대로 악성코드나 해킹 프로그램의 경로로 악용이 될 수도 있기 때문입니다.

크롬의 대표적인 확장 앱 중 하나인 광고 차단앱을 예를 들면 

크롬으로 사용자가 웹페이지에 접속할 경우, 광고 차단앱은 webRequest API를 이용해 웹 트래픽 응답을 모니터링하다, 

광고 패턴에 해당하는 리소스, 또는 차단 정책에 포함된 도메인이나 차단 리스트에 있는 URL 접근을 할 경우 해당 리소스를 차단합니다.

크롬 개발자 도구로 확인해보면

대표적인 크롬 광고 차단 앱인 AdBlock 은 아래처럼 광고와 관련된 패턴이나 URL을 중간에서 차단해서 웹페이지에 완전히 표시가 되지 않도록 합니다.

이런식의 크롬 확장 앱은 모두 webRequest API 를 이용해 개발되어 왔습니다.

새로운 크롬 확장 API 는 이 webRequest API 를 대신해 declarativeNetRequest 를 사용하도록 권장하고 있습니다.

아울러 webRequest API 에는 다음과 같은 문구가 명시됩니다.

"Starting from Chrome 72, an extension will be able to intercept a request only if it has host permissions to both the requested URL and the request initiator."

크롬 72버전부터 클롬 확장 앱은 요청URL(request URL)과 요청이니셰이터(request Initiator)에 대한 호스트 퍼미션이 있는 경우에 웹요청(Request)만을 가로챌 수 있다. 

조금 난해한가요? 사용자가 웹페이지에 접근하기 위해 보내는 요청에 대해서만 호스트 퍼미션이 있으면 변경이 가능하고, 웹 응답에 대해서는 아얘 수정을 할 수 없도록 막아 버렸습니다.

즉 웹서버(웹사이트)에서 오는 응답에 대해서는 확장 프로그램이 수정이나 차단 기능을 할 수 없게 막았습니다.

기술적으로는 

onSendHeaders

onBeforeRedirect

onResponseStarted

이벤트에 대해서 

"It does not allow you to modify or cancel the request."

즉, 수정하거나 취소할 수 없다고 명시를 했습니다.

사실상 크롬 확장 프로그램의 webRequest API 를 통한 웹페이지 응답에 대한 변조 자체를 막았다고 보면 됩니다.

원문 참조: https://developer.chrome.com/extensions/webRequest

그럼 구글이 대안으로 권장하면 declarativeNetRequest API에 대응하는 기능을 제공하면 되지만 declarativeNetRequest API 가 상당히 제한적인 기능만을 제공하기 때문에 사실상 무쓸모?입니다.

webRequest API 대용으로 사용하기 위해 만든 것으로 추측?되는 declarativeWebRequest API 도 정의만 되어있을 뿐 사실상 홀드 상태여서 더 이상 진행되지 않고 있습니다.

현재 가능한 선택지는 declarativeNetRequest API 를 쓰는 것 말고는 방법이 없습니다.

이 API 는 API 이름 그대로 선언적인 룰셋 정의를 통해 네트워크 요청을 차단하거나 리다이렉트 해주는 기능을 합니다.

간단하게 개념적인 예를 들면

{ "id" : 1, "action" : { "type" : "block" }, "condition" : { "urlFilter" : "adsense", "domains" : ["google.com"], "resource_types" : ["script"] } }

이런 JSON 형태의 룰셋을 정의해 크롬 확장 앱에서 declarativeNetRequest API 호출을 한다면

"google.com 도메인으로 요청하는 "adsense" 라는 문자열이 들어간 스크립트 요청은 차단(block) 한다."

는 규칙을 실행하게 됩니다.

이런 식의 명시적인 룰셋 정의로 과연 광고 차단앱이나 악성코드 차단 앱의 기능들을 정상적으로 구현할 수 있을까? 가는 의문이 들 수밖에 없습니다.

불난 남의집 싸움에서 조금 벗어나서 보자면

광고 차단앱과 같은 앱은 과연 사용자의 더 나은 선택권을 보장해주는 앱일까요?

아니면 구글의 이번 확장 프로그램 API변경이 사용자의 보안과 프라이버시를 보장해주는 더 나은 조치일까요?

보안과 프라이버시 문제는 분명히 구글에게는 다른 그 어떤 것보다 중요한 이슈입니다.

특히 EU의  유럽 개인정보 보호법(이하 GDPR)로 인해 발생할 가능성이 있는 천문학적인 벌금을 피해가기 위해서라도 개인 정보를 탈취할 가능성이 있는 써드파티 앱의 부적절한 접근을 차단할 필요가 분명히 있습니다.

페이스북이 현재 직면한 프라이버시 침해에 따르는 곤경을 보면서 구글은 앞으로 보안과 프라이버시를 더 많이 보장하는 쪽으로 구글의 모든서비스들을 정비를 할 것입니다.

구글에게는 생존이 걸린 문제이기 때문에 현재로서는 크롬 확장 프로그램 개발자들의 볼멘 불만은 충분히 감수할 의사가 있어 보입니다.

현재(2019년 1월) 크롬의 버전은 71입니다.

크롬의 평균 버전업 속도로 봤을때 늦어도 2019년 하반기에는 72버전으로 업데이트가 될 것이 확실합니다.

구글이 과연 광고차단앱과 백신류의 보안 프로그램을 위한 크롬 확장 개구멍?을 열어주는 은총을 베풀지는 아직 모릅니다.

다만, 구글의 이번 업데이트로 인해 보안과 프라이버시가 무엇보다 중요하고

더 나아가 구글이 크롬에 보안상 헛점이 될 소지가 다분한 개구멍을 뚫어줄 가능성은 없다는 점입니다.

그리고 소문으로만 떠돌던 구글이 브라우저에 광고 차단 기능을 내장할 것이라는 것도 현실화할 가능성이 높아졌습니다.

제한적인 기능을 제공하겠지만, 악성 광고나 악성 코드를 다운로드 실행하려는 광고류를 제한적으로 차단하는 기능정도면 크롬 사용자들은 큰 불만이 없을 수도 있습니다.

그리고 부수적으로는 크롬 전체 사용자의 5~10% 정도로 추산되는 광고차단앱 사용자들로 인해 차단되던 구글의 광고들도 더 많이 노출할 수 있게 될겁니다.

광고차단앱의 최대 피해자는 역시 구글의 애드센스였기 때문에...

크로미움 엔진으로 교체하는 마이크로소프트 엣지도 아마도 같은 정책을 따라갈 가능성이 큽니다.

파이어폭스도 유럽 GDPR의 영향을 피해갈 수 없기 때문에 어떤 형태로든 구글의 이번 업데이트와 유사한 업데이트가 있을 것입니다.

광고차단앱은 과연 살아남을 수 있을까요?