Chrome의 새로운 확장 기능 API인 Manifest V3는 더 이상 가능한 미래가 아니라 현실입니다. 그리고 이제 AdGuard 확장 프로그램을 포함하여 수십 개의 광고 차단 확장은 Manifest V3에 따라 작동해야 합니다.

2018년 구글이 새로운 API를 설명하는 문서를 처음 게시했을 때 개발자 커뮤니티는 즉시 구글을 비판했습니다. Adguard는 매니페스트 V3(Manifest V3) 구현의 부정적인 결과에 대한 몇 가지 기사를 발표했으며 "상황이 그렇게 나쁘게 나오지 않을 것"이라는 희망을 표명했습니다.

많은 비판에도 불구하고 Manifest V3는 2020년 말에 Chrome 88 베타와 함께 릴리스 되었습니다. 2022년 1월부터 Manifest V2 기반의 새로운 확장 프로그램을 Chrome 웹 스토어에 추가하는 것이 불가능해졌습니다. 그리고 2023년 1월부터 Manifest V2의 모든 확장 프로그램(이전에 Chrome 웹 스토어에 추가된 확장 프로그램 포함)의 작동이 중지됩니다.

Windows, Mac 또는 Android용 AdGuard를 사용하는 경우 MV3에 대해 걱정할 필요가 없습니다. 왜냐하면 이런 앱들이 브라우저에서 제어되지 않기 때문입니다.

실험적인 AdGuard MV3 브라우저 확장 프로그램

2021년 중반에 Manifest V3의 엄격한 제한에도 불구하고 광고를 차단할 수 있는 새로운 확장 프로그램의 프로토타입을 개발하기 시작했습니다. 그러나 새 API는 아직 원시 상태였고 일부 측면은 마무리 중이었고 제대로 작동하지 않았습니다. 그러나 모든 어려움을 극복하고 구글이 매니페스트 V3를 적용해도 광고 차단기는 살아남을 수 있음을 증명했습니다다.

프로토타입을 개발하는 동안 새로운 API의 기능으로 인해 많은 심각한 문제에 직면했습니다. 각 문제에 대해 자세히 살펴보겠습니다.

새로운 확장 프로그램을 사용하려면 Chrome WebStore에서 설치할 수 있습니다.

위 비디오는 확장 프로그램이 어떻게 작동하는지 보여줍니다.

규칙 제한

확장 프로그램 필터의 모든 규칙은 매니페스트 V3에 의해 정적(기본) 및 동적 규칙으로 나뉘었고 그 수는 크게 제한되었습니다.

하나의 확장 프로그램을 사용하는 경우 정적 규칙은 30,000개의 규칙으로 제한되고 여러 확장 프로그램을 사용하는 경우 총 330,000개의 규칙이 허용됩니다 (또한 확장 프로그램당 1000개의 정규식 제한도 고려합니다). 문제는 허용된 모든 규칙이 하나의 확장 프로그램에 적용되고 규칙 제한에 도달하여 다른 확장 프로그램에 규칙을 적용할 수 없다는 것입니다.

AdGuard 확장 프로그램에서 이러한 문제가 발생하면 브라우저가 활성 필터 목록을 수정했으며 AdGuard 기본 광고 필터만 사용하도록 설정했다는 메시지가 표시됩니다. 이 문제는 업데이트, 서비스 워커 재시작, 당사 또는 타사 차단기에서 설정된 필터 변경 등 후에 발생할 수 있습니다. 최악의 경우, 기본 필터에 30,000개 이상의 규칙이 포함되어 있으므로 기본 필터가 활성화되지 않을 수 있습니다.

이러한 경우 브라우저가 비활성화한 것과 활성화한 것에 대한 설명이 별도의 화면에 표시됩니다.

사용자가 자신의 규칙이나 필터를 추가할 수 있는 동적 규칙의 경우 5000개로 제한됩니다 (정규 표현식 규칙 1000개 제한 포함). 이 제한을 초과하면 AdGuard MV3는 처음 5,000개의 규칙만 적용할 수 있고 나머지는 비활성 상태로 유지됩니다.

규칙 수 제한 초과에 대한 알림은 다음과 같이 표시됩니다.

Manifest V3의 제한 사항은 필터링 품질과 사용자 경험뿐만 아니라 필터 개발 커뮤니티에도 해를 끼칩니다. 이전에는 누구나 스스로 필터를 만들 수 있었고 이 필터는 널리 사용되어 권장 차단 목록에 포함될 수 있었습니다. 이제 그렇게 하는 것이 훨씬 더 어려워졌습니다.

차단기는 사전 설정된 필터(50개 이하)를 사용해야 하며 사용자가 사용할 필터를 매우 신중하게 선택해야 합니다.

물론 자신의 필터를 수동으로 설정할 수도 있습니다. 그러나 모든 사용자 정의 필터와 사용자 규칙은 5000개로 제한된다는 점을 잊지 마십시오.

아래의 문제 설명은 개발자만 이해할 수 있을 것 같습니다. 당신이 개발자가 아니라면, 이 부분은 건너뛸 수 있습니다. 이 링크를 클릭하면 결론으로 이동합니다.

선언적 규칙

Manifest V3가 도입되기 전에 필터링 엔진은 확장 프로그램을 통해 서버에서 다운로드한 필터에서 동적으로 구축되었습니다. 또한 필터를 구성하는 규칙은 페이지 로딩의 여러 단계에서 적용되었습니다.

예를 들어 브라우저가 요청을 보내기 전에 규칙이 활성화되었을 수 있습니다. onBeforeRequest 이벤트 내에서 브라우저는 확장 프로그램에 특정 요청을 처리할 것인지 물었고 확장 프로그램은 이를 차단하거나 리디렉션하여 동적으로 반응했습니다. 페이지가 이미 로드되고 DOM이 나타날 때 보정 규칙이 적용되었습니다.

이제 Manifest V3가 적용되어 onBeforeRequest 메소드를 더 이상 사용할 수 없습니다. 대신 Chrome은 요청을 수정할 수 있는 권한이 브라우저에 부여되는 declarativeNetRequest API 사용을 제안합니다. 확장 프로그램은 브라우저가 네트워크 요청을 수정하거나 차단할 선언적 규칙 집합만 알립니다.

선언적 규칙 신텍스

선언적 규칙의 신텍스는 최신 광고 차단기에서 일반적으로 사용하는 신텍스와 상당히 다릅니다. 많은 커뮤니티 회원이 Manifest V3 내에서 작업하기를 거부하고 Chrome 전용으로 맞춤화된 규칙을 만드는 데 시간을 소비하기를 원하지 않을 수 있습니다.

각 규칙은 다음 필드로 구성되어야 합니다.

• id – 규칙의 식별자입니다. 선언적 규칙을 텍스트 규칙과 연결하는 데 사용할 수 있습니다.
• priority – 규칙의 우선 순위입니다. 규칙이 쿼리에 적용되는 방식을 결정합니다.
• action – 규칙의 동작입니다.
  세 가지 종류가 있습니다:
  • block – 요청을 차단하는 동작입니다.
  • redirect 또는 upgradeScheme – 요청을 리디렉션하는 동작입니다.
  • allow 또는 allowAllRequests – 요청을 허용하는 동작입니다.
  • condition – 규칙이 적용되는 조건입니다.

규칙의 예는 다음과 같습니다.

{
  "id": 1,
  "priority": 1,
  "action": { "type" : "block" },
  "condition": {
    "urlFilter": "abc",
    "domains": ["example.org"],
    "resourceTypes": ["script"]
  }
}

이 규칙은 주소에 abc 하위 문자열이 있고 도메인 example.org가 있는 사이트에서 시작된 스크립트에 대한 모든 요청을 차단합니다.

현재 상황은 데자뷰를 유발합니다. Safari용 광고 차단 확장 프로그램을 개발할 때 규칙 신텍스를 브라우저 개발자가 부과한 신텍스로 변환하는 방법을 찾아야 했습니다. 이번에는 유사한 방식으로 신텍스를 Chrome의 선언적 규칙으로 변환합니다.

정적 및 동적 규칙을 변환하기 위해 @adguard/tsurlfilter 라이브러리에 모듈이 추가되었습니다. 라이브러리는 필터 규칙을 실행하고 선언적 규칙으로 변환한 후 규칙 집합으로 결합하여 .json 파일에 저장합니다. 라이브러리는 텍스트 규칙과 JSON 규칙 간의 연결이 끊어지지 않도록 매핑 테이블을 작성합니다.

변환기 작동 방식의 예는 다음과 같습니다.

||example.com^$script 규칙은 다음으로 변환됩니다.

{
    "id": 1,
    "action": {
        "type": "block"
    },
    "condition": {
        "urlFilter": "||example.com^",
        "resourceTypes": [
            "script"
        ],
        "isUrlFilterCaseSensitive": false
    }
}

@@||example.com^$script$domain=example.org 규칙은 다음으로 변환됩니다.

{
    "priority": 1,
    "id": 23,
    "action": {
        "type": "allow"
    },
    "condition": {
        "urlFilter": "||example.com^$script",
        "initiatorDomains": [
            "example.org"
        ],
        "isUrlFilterCaseSensitive": false
    }
}

대부분의 규칙은 올바르게 변환되지만 다음과 같은 다양한 제한으로 인해 일부 기능이 손실됩니다.

• $removeparam은 제외(~) 및 정규식(regexp)을 지원하지 않습니다.

• 정규 표현식의 경우 크롬은 이러한 표현식의 자체 구현을 사용하므로 표준 기능의 일부가 지원되지 않습니다. 예를 들어, 역참조, 부정 예견 및 소유 수량자를 포함하는 정규식입니다.

• negative lookahead는 필터에서 자주 사용됩니다. 빠른 검색에 따르면 현재 AdGuard 필터에 이 표현식이 포함된 규칙이 43개 있습니다. 언뜻 보기에는 많지 않지만 이러한 규칙의 대부분은 다양한 도메인에서 작동해야 한다는 점을 염두에 두십시오. 따라서 이 제한만으로도 1000개 이상의 웹사이트에서 광고 차단이 중단됩니다.

• 정규식은 소비된 메모리 양에 대해 Chrome 내에서 추가로 검증됩니다. 이 경우 어떤 종류의 구현이 사용되는지 확실하지 않기 때문에 일부 정규식에 몇 가지 문제가 있을 수 있습니다.

• 쿠키 규칙은 지원되지 않습니다.

• 기사가 더 복잡해지지 않도록 여기에서 다루지 않을 더 많은 문제가 있습니다.

선언적 규칙의 문제는 다소 명백합니다. 이 신텍스는 확장 프로그램의 기능을 심각하게 제한합니다. 실망스럽게도 Chrome 개발자가 이 신텍스를 개선하기를 바라는 것 외에는 우리가 할 수 있는 일이 없습니다.

규칙 세트

새 API에 따르면 선언적 규칙은 규칙 집합으로 결합되어야 합니다.

Manifest V3에서 규칙 집합을 통합하는 예는 다음과 같습니다.

{
  "name": "AdGuard AdBlocker MV3",
  "version": "1",
  "declarative_net_request": {
     "rule_resources": [{
       "id": "ruleset_1",
       "enabled": true,
       "path": "rules.json"
     }]
   },
   …
}

규칙 세트는 manifest.json 파일에 지정되며 확장 프로그램이 설치되거나 업데이트될 때만 로드됩니다. 이것은 큰 문제입니다. 때때로 필터링 규칙은 웹사이트의 레이아웃이나 성능을 손상시킵니다. 많은 규칙에서 모든 오류를 포착하는 것은 불가능하고 사이트가 지속적으로 변경되어 문제가 발생할 수 있기 때문에 이는 보통 일입니다.

필터에 어떤 규칙이 있고 빠르게 비활성화해야 한다고 상상해 보세요. Manifest V2 확장 프로그램에서는 $badfilter 수정자는 규칙을 빠르게 비활성화하기 위해 사용되었습니다. 필터 개발자는 지정된 수정자를 사용하여 규칙을 추가하고 확장 프로그램은 동적으로 업데이트되며 새 규칙은 참조된 규칙을 비활성화하고 상황이 더 나아질 것입니다. 하지만 이 방법은 매니페스트 V3에 사용할 수 없습니다.

이제 필터가 며칠 동안 업데이트되지 않을 것입니다. Chrome 스토어에 새 버전을 추가한 후 검토가 통과될 때까지 기다려야 합니다. 안타깝게도 사용자에게 업데이트된 필터를 제공할 수 있는 다른 방법은 없습니다.

통계 및 필터링 로그

Manifest V2를 기반으로 하는 AdGuard 확장 프로그램에는 브라우저에서 보낸 모든 요청과 이에 대한 자세한 정보를 보여주는 필터링 로그가 있습니다. 특히 이 규칙 또는 해당 규칙을 차단하는 데 사용된 필터링 규칙을 확인할 수 있습니다.

Chrome 자체가 이제 개발자 모드에서 압축을 풀고 설치된 확장 프로그램과만 요청을 차단하고 통계를 공유하기 때문에 이전과 같은 필터링 로그를 구현할 수 없습니다.

프로토타입의 현재 버전은 필터링 로그를 구현하지 않습니다. 대신 필터 개발자는 Chrome 개발자가 권장하는 메커니즘을 사용해야 합니다. 사실 declarativeNetRequest를 사용하면 어떤 규칙이 작동했는지에 대한 정보를 얻을 수 있습니다. 그러나 이 정보를 확인하려면 리포지토리를 복제하고 확장 프로그램을 ‘빌드’하고 브라우저를 개발자 모드로 전환해야 합니다.

서비스 워커

매니페스트 V3 때문에 배경 페이지가 사라졌습니다. 백그라운드 페이지는 확장 프로그램이 상태를 유지하고 브라우저 API(예: 앞서 언급한 onBeforeRequest)와 함께 작동할 수 있는 별도의 백그라운드 프로세스입니다. Manifest V3에서 이 페이지는 종종 브라우저에 의해 중단되는 서비스 워커로 대체되었습니다.

브라우저가 서비스 워커를 중지하면 확장 프로그램은 일종의 절전 모드로 전환됩니다. 선언적 규칙은 작동하지만 동적으로 로드되는 보정 규칙은 작동하지 않습니다. 확장 프로그램이 작동하려면 무언가가 서비스 워커를 절전 모드에서 깨워야 합니다. 페이지를 로드하거나 서비스 워커에게 보낸 메시지일 수 있습니다.

서비스 워커가 깨어나면 확장 프로그램은 리포지토리에서 필터링 규칙을 읽고 빠르게 찾을 수 있도록 처리하기 시작합니다. 이 시간(1.5~2초) 동안 확장 프로그램은 보정 필터링을 적용하지 않지만 광고 요청은 브라우저 자체에서 차단됩니다. 그런 다음 엔진이 실행되고 광고가 사라집니다.

결론

Manifest V3의 제한에도 불구하고 AdGuard MV3는 여전히 광고 및 추적으로부터 보호합니다.

• 추적자에 대한 요청을 사전에 차단합니다.
• 배너, 소셜 위젯 및 기타 성가신 요소를 숨깁니다.
• YouTube를 포함한 동영상 공유 플랫폼의 광고를 차단합니다.

실험적 확장 프로그램은 이전 버전만큼 효과적이지는 않지만 대부분의 사용자는 차이를 느끼지 못할 것입니다.

이 프로토타입의 목표는 새로운 접근 방식을 테스트하고 피드백을 받는 것입니다. 이 프로그램을 사용해 보고 개선할 수 있는 것을 알려 주시면 감사하겠습니다. 이 프로토타입은 오픈 소스이며 Github에 게시됩니다.

광고 차단기 개발자들 중 맨 처음으로 Manifest V3로 구축된 확장 프로그램을 출시함으로써 Google이 우리에게 제기한 과제를 해결했다고 주장할 수 있습니다. 이제 Manifest V2가 중단된 후에도 Chrome 사용자는 AdGuard 브라우저 확장 프로그램을 사용하여 광고 및 추적기로부터 자신을 보호할 수 있습니다.