자주 묻는 질문 - 내부 작동 원리

어려운 작업은 실질적으로 게코(Gecko)라는 파이어폭스, 선더버드 그리고 다른 애플러케이션에 내장된 상위 엔진에 의해 이루어집니다. 게코는 "콘텐츠 정책(content policies)"으로 불리는 것을 허용합니다. 콘텐츠 정책은 단순한 자바스크립트(또는 C++) 객체로서 브라우저가 어떤 것을 불러올 필요가 있을 때마다 호출됩니다. 그것은 불러올 주소와 몇몇 다른 데이터를 검토한 다음, 그것의 허용 여부를 결정합니다. 등록된 많은 콘텐츠 정책이 존재하고(파이어폭스 또는 시몽키에서 사이트가 이미지를 불러오는 것을 허용하지 않게 정의하면 실질적으로 내장된 콘텐츠 정책 중 하나를 설정하게 되는 것입니다), 확장 프로그램이라면 콘텐츠 정책을 등록할 수 있습니다. 그래서 차단 기능을 위해 애드블록 플러스는 콘텐츠 정책을 등록하고, 그외에 차단할 주소와 필터 설정을 위한 사용자 인터페이스 코드를 결정하기 위해 애플리케이션 로직이 존재합니다.

개발자 참고사항 : 콘텐츠 정책을 등록하기 위해 XPCOM 컴포넌트를 작성해야 하며, 이 컴포넌트는 nsIContentPolicy 인터페이스를 내장합니다. "콘텐츠 정책" 카테고리(이를 위해 카테고리 관리자를 사용함)에 당신의 컴포넌트를 등록하기 위해 모듈의 registerSelf method를 조절해야 합니다. 이제 컴포넌트의 shouldLoad method는 호출될 것이고, 특정 요청이 수락될 것인지를 결정할 수 있습니다.

모든 필터는 내부적으로 정규 표현식으로 변환됩니다. 엄밀한 의미에서 그러한 일반 필터는 명확하지 않기 때문입니다. 예를 들어 필터 ad*banner.gif|는 정규 표현식 /ad.*banner\.gif$/로 변환됩니다. 그런데 필터를 주소에 적용할 때 브라우징의 속도를 저하시키지 않기 위해 모든 필터를 차례대로 테스트하지 않습니다.

필터를 정규 표현식을 변환할 뿐만 아니라 필터에서 텍스트 정보를 추출합니다. 그것이 필요한 이유는 주소마다 존재하는 8자의 고유한 문자열(일명 단축)과 필터가 일치하기 때문입니다(길이는 정해져 있지 않지만 8자가 합리적임). 예를 들어 필터 |http://ad.*가 있고, "http://a", "ttp://ad", "tp://ad." 사이에서 선택을 하면 이 문자열 중에서 어느 것이든지 이 필터와 항상 일치합니다.

불행하게도 와일드 카드 문자(*)로 8자 미만의 단순 필터이거나 명확하게 변환될 수 없는 정규 표현식이면 필터의 단축을 찾는 것은 불가능합니다. 모든 단축은 검색 표에 있고, 애드블록 플러스는 단축에 의해 필터를 매우 효율적으로 찾을 수 있습니다. 그런 후 특정 주소가 테스트될 때 거기에서 알려진 단축을 먼저 찾을 것입니다. (이것은 매우 빠르게 이뤄질 수 있고 그 필요한 시간은 단축의 개수와 거의 무관합니다.) 단축이 발견되었을 때만 문자열은 필터와 일치하는 정규 표현식을 테스트하게 됩니다. 그러나 단축 없는 필터는 차례차례 느린 속도로 테스트됩니다.

요약하자면 : 빠른 필터 목록을 필터 처리의 속도 향상을 위해 필터 작성 방법은 무엇입니까? 정규 표현식은 항상 느리기 때문에 가능한 한 적게 사용해야 합니다. 단순한 필터라도 최소 8자의 온전한 텍스트인지 역시 확인해야 합니다. 반면에 그것들은 정규 표현식만큼 느리지는 않을 것입니다 (이것들은 와일드 카드 문자(*)와 같이 특별한 의미의 어떠한 문자도 포함하지 않음을 의미합니다). 그러나 완전한 형식의 필터라면 필터의 수와는 무관하며, 처리 시간은 항상 같습니다. 만약 20개의 단순한 필터를 1개의 정규 표현식으로 교체할 수 있다면 가치가 있을지도 모릅니다. 정규 표현식을 단순 필터로 변환할 것을 매우 권장합니다.

알고리듬과 일치하는 필터에 대한 상세한 설명

요소 숨김 필터는 CSS로 변환되며, 사용자가 방문하는 모든 웹 페이지에 적용됩니다. example.com#div(evil_ad)와 같은 필터는 다음과 같이 변환됩니다.

@-moz-document domain(example.com)
{
  div#evil_ad, div.evil_ad
  {
    display: none !important;
  }
}

@-moz-document는 CSS 표준으로 제안된 확장이며, 모질라 개발자 센터에서 더 많은 정보를 참고하십시오.

어떤 도메인에 한정하지 않은 필터는 브라우저의 사용자 인터페이스의 요소 숨김을 막기 위해 프로토콜 http://와 https://로 제한할 것입니다 (chrome:// 프로토콜 스킴을 사용하고 있음). 예를 들어 필터 #div(evil_ad)는 다음과 같이 변환됩니다.

@-moz-document url-prefix(http://),url-prefix(https://)
{
  div#evil_ad, div.evil_ad
  {
    display: none !important;
  }
}

개발자 참고 : 애드블록 플러스는 여기에서 스타일시트 서비스를 이용하고 있습니다. 이 인터페이스는 게코 1.8부터 등장했고, 극적으로 확장 프로그램이 사용자 스타일시트를 추가할 수 있게 해주었습니다 (브라우저의 다시 시작이 필요한 userContent.css만을 수정할 수 있기 전에). 사용자 스타일시트는 모든 웹 사이트의 CSS 코드를 덮어쓸 것이고, importance로 인해 우선해서 적용됩니다.

필터 파일의 첫번째 줄은 보통 단순하게 [Adblock]만 있습니다. 하지만 종종 애드블록 플러스의 최신 버전은 [Adblock] 대신에 다른 텍스트를 입력한다는 것을 눈치챘을 것입니다. 이것은 초기 Adblock이 아닌 더 새로운 버전의 Adblock Plus에 의해서만 지원하는 고급 필터 구문을 사용하는 필터가 목록에 있을 때 이루어집니다.

(Adblock Plus 0.6.1.2 or higher required) [Adblock]

이것은 단순히 주석일 뿐입니다. Adblock(그러한 이유로 Adblock Plus도 마찬가지임)은 실제로 그 표시 앞에 있는 모든 것을 무시합니다. 애드블록 플러스 0.6.1.2는 그것을 지원하지 않았기 때문에 애드블록 플러스 버전에 영향을 받지 않습니다. 하지만 만약 훨씬 더 새로운 필터 구문을 사용한다면 다음과 같은 문자열을 확인할 것입니다.

[Adblock Plus 0.7.1]

애드블록 플러스 0.7.1부터 이러한 형태의 헤더를 지원합니다. 더 오래된 애드블록 플러스 버전과 애드블록은 이 헤더로 시작하는 파일을 열 수 없습니다. 현재 버전은 헤더에서 버전 번호를 확인 후 자체 버전 번호와 그것을 비교합니다. 만약 필터 파일이 더 새로운 애드블록 플러스가 필요하다면 불러오기 메시지에 업데이트를 요청이 있을 것입니다. 구독 필터의 경우 여전히 더 새로운 애드블록 플러스 버전에서 사용되는 필터 파일을 불러오겠지만 필터 관리 대화상자에 경고 메시지가 나타납니다.

마지막으로 애드블록 플러스는 필요하지만 버전 번호를 지정하고 싶지 않다면 파일을 [Adblock Plus]로 시작할 수 있습니다. 물론 이 파일은 애드블록 플러스 0.7.1 이상에서만 받아들여집니다.