미니 크로뮴 애드블럭 차단 사태(?) 에 관해
- Score_고동빈
- 조회 수 579
- 2019.05.30. 22:33
결론부터 말하자면... 옳은 방향이라고 생각합니다.
이 사태는 올 초에 구글이 크로뮴 프로젝트에 WebRequest API 제거를 제안하면서 시작됩니다. WebRequest API는 사용자의 브라우저에서 작용하는 웹 요청과 응답을 도착하기 전에 가로채서, 연결을 아예 드랍시켜버리거나 수정하여 원래의 목적지가 아닌 다른 곳으로 보내는 등의 액션을 취할 수 있는 API입니다. 지금의 광고 차단 플러그인들은 이 API를 응용해서 특정 조건(주로 URL 구조로 판단합니다)에 맞는 웹 요청(주로 광고 이미지나 동영상, 자바스크립트 등이겠죠?)을 드랍시키는 방식을 취하고 있습니다.
이쯤되면 대충 눈치를 까신 분도 있겠지만, 이 방식은 심각한 보안 결점이 있습니다. 그냥 대놓고 유저가 뭘 하는지를 들여다 볼 수 있는거니까요. TLS 암호화? 그딴거 소용 없습니다. 익스텐션이 보는 건 이미 브라우저 앞단에서 복호화 다 돼서 유저한테 대접되기 직전의 평문 데이터니까요.
그럼 세계 최고의 인터넷 광고업체인 구글이 애드블럭을 완전히 막으려는 음모론이냐? 아닙니다. 구글은 제거될 WebRequest API의 대안인 DeclarativeWebRequest API를 같이 제안한 상태입니다.
물론 DeclarativeWebRequest API는 원판에 비해 너프를 좀 먹긴 했습니다. 원판이 유저가 작용하는 웹 요청과 응답을 모두 까뒤집어 보는 방식이라면, DeclarativeWebRequest는 그런 힘까지는 없고, 대신 브라우저에 URL 필터를 등록할 수 있게 해줍니다. '이 필터를 너한테 줄테니 이런 요청이 들어오면 니가 대신 막아줘라' 하는거죠. 룰 갯수도 제한되어 있습니다. 얼만지 기억은 안나는데 대충 3만줄인가? 그럴겁니다.
그렇긴 해도, 이 방식이 도입되면 써드 파티 익스텐션은 이제 더 이상 유저의 정보를 마음대로 까 볼수 없습니다. 개인적으로는 이게 실제로 도입되면 WebKit이나 Firefox에서도 재빠르게 Declarative 방식으로 넘어갈 거 같네요.
이 방식에서 브라우저의 통제 하에 놓인다고 일이 터질게 있을까... 에는 개인적으로 의문부호가 붙네요. 브라우저의 통제가 들어간 상태에서 일이 터지면 그건 핫픽스 올려야 할 보안 결함인거고...
이러한 방침은 익스텐션이 딴맘 못먹게 아예 근본부터 차단하는 방식인겁니다.
물론 구글의 스토어 검수가 상당히 널널하다는 말씀은 저도 동의합니다. 근데 검수 그거도 다 사람이 하는거에요. 아무리 빡세게 돌려도 저런 백도어성 API를 열어두면 언젠가 문제가 생기게 되어 있습니다. 그걸 닫아버린다는거니까요.
그러니까 기존은 익스텐션에서 바로 까보고 막았는데
이제는 익스텐션 등에서 URL을 브라우저에 등록하면서 막아달라고 하면 그걸로 막는거라는거죠?
결국 저걸 크롬이 직접 통제한다는건데....
저게 어떨려나 모르겠네요
안드Q도 그렇고 얘도 그렇고 통제 해도 일터지면 뒷처리 안 지려고 할거면서 뭘 자꾸 막는지 모르겠네요
지금도 지들 귀찮아서 플레이스토어 관리 안 하는 마당에...
보안인건지 퇴보인건지 모르겠습니다