이전 기사에서 우리는 새로운 자바 스크립트 엔진에 대해 이야기했습니다. Mozilla 사람들이 다음 달 70 월에 출시 될 Firefox XNUMX의 다음 버전을 위해 작업 해 왔습니다. 다음 링크를). 이 기사에서는 Mozilla의 발표에 대해 이야기하겠습니다. WebExtensions API 기반 Firefox 추가 기능 사용에 대한 정보 Mozilla 개발자가 자신의 입장을 알리는 어느 그들은 곧 출시 될 Chrome 플러그인 매니페스트의 세 번째 버전을 완전히 따르려고하지 않습니다.
이것으로 그들은 특히, Firefox는 webRequest API 차단 모드를 계속 지원합니다., 허용 된 콘텐츠를 즉시 변경할 수 있으며 광고 차단기 및 콘텐츠 필터링 시스템에서 수요가 많습니다.
WebExtensions API 로의 전환의 주요 아이디어는 Firefox 및 Chrome 용 플러그인 개발 기술의 통합이었습니다. 따라서 현재의 형태에서 Firefox는 현재 두 번째 버전의 Chrome 매니페스트와 거의 100 % 호환됩니다.
매니페스트는 제공된 기능 및 리소스 목록을 정의합니다. 보완을 위해. l에 의해 부정적으로 인식되는 제한 조치의 도입으로 인해개발자 세 번째 버전의 매니페스트 플러그인, Mozilla는 매니페스트를 완전히 따르는 관행을 포기하고 변경 사항을 Firefox로 전송하지 않습니다. 플러그인 호환성을 위반합니다.
모든 반대에도 불구하고 Google은 WebRequest API 모드를 차단하는 모드에서 Chrome에 대한 지원을 중단하고 읽기 전용 모드로만 제한하고 declarativeNetRequest API의 새로운 선언적 콘텐츠 필터링 기능을 제공 할 계획입니다.
webRequest API를 사용하여 네트워크 요청에 대한 전체 액세스 권한과 즉시 트래픽을 수정할 수있는 컨트롤러를 연결할 수있는 경우, 새로운 declarativeNetRequest API는 독립적으로 처리하는 기본 제공 범용 필터링 엔진에 대한 액세스를 제공합니다. 차단 규칙은 자체 필터링 알고리즘의 사용을 허용하지 않으며 복잡한 규칙이 조건에 따라 서로 겹치는 것을 허용하지 않습니다.
Mozilla는 또한 다른 변경 사항을 지원하기 위해 Firefox로 포팅하는 편의성을 평가하고 있습니다. 플러그인 지원을 위반하는 Chrome 매니페스트의 세 번째 버전에서
- La 서비스 워커 실행으로 전환 백그라운드 프로세스의 형태로 필요한 것은 개발자가 일부 추가 코드를 변경하는 것입니다.
새로운 방법이 성능면에서 더 최적이지만 Mozilla는 백그라운드 페이지 실행에 대한 지원 유지를 고려하고 있습니다. - 새로운 세분화 된 권한 요청 모델 : 플러그인은 모든 페이지에 대해 즉시 활성화 될 수 없지만 ( "all_urls"권한이 제거됨) 활성 탭의 컨텍스트에서만 작동합니다. 즉, 사용자가 각 사이트에 대한 플러그인 작동을 확인해야합니다. 이 부문에서 Mozilla는 사용자의주의를 지속적으로 분산시키지 않으면 서 액세스 제어를 강화하는 방법을 모색하고 있습니다.
- 출처 간 신청 처리 변경 : 새 매니페스트에 따르면 이러한 스크립트가 삽입되는 메인 페이지와 동일한 권한 제한이 콘텐츠 처리 스크립트에 적용됩니다 (예를 들어 페이지에 위치 API에 대한 액세스 권한이없는 경우 스크립트 플러그인이 가져 오지 않습니다. 이 액세스 중 하나). 변경 사항은 Firefox에서 구현 될 예정입니다.
- 외부 서버에서 다운로드 한 코드 실행 금지 (우리는 플러그인이 외부 코드를로드하고 실행하는 상황에 대해 이야기하고 있습니다). Firefox는 이미 외부 코드 차단을 사용하고 있으며 Mozilla 개발자는 매니페스트의 세 번째 버전에서 제공되는 추가 코드 다운로드 추적 기술을 사용하여 이러한 보호를 강화할 수 있습니다.