{"id":52212,"date":"2019-11-03T00:00:00","date_gmt":"2019-11-02T21:00:00","guid":{"rendered":"https:\/\/prohoster.info\/blog\/blog_prohoster\/v-chrome-nachalos-testirovanie-tretej-redaktsii-manifesta-nesovmestimoj-s-ublock-origin"},"modified":"2020-02-18T13:59:53","modified_gmt":"2020-02-18T10:59:53","slug":"v-chrome-nachalos-testirovanie-tretej-redaktsii-manifesta-nesovmestimoj-s-ublock-origin","status":"publish","type":"post","link":"https:\/\/prohoster.info\/fr\/blog\/news\/v-chrome-nachalos-testirovanie-tretej-redaktsii-manifesta-nesovmestimoj-s-ublock-origin","title":{"rendered":"Chrome a commenc\u00e9 \u00e0 tester la troisi\u00e8me version du manifeste, incompatible avec uBlock Origin.","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

La soci\u00e9t\u00e9 Google a commenc\u00e9 les tests<\/a><\/noindex> de la troisi\u00e8me version du manifeste Chrome, qui enfreint<\/a><\/noindex> le fonctionnement<\/a><\/noindex> de nombreux modules d'extension pour bloquer le contenu ind\u00e9sirable et assurer la s\u00e9curit\u00e9. Le support du nouveau manifeste, qui d\u00e9finit les capacit\u00e9s et les ressources fournies aux modules d'extension, a \u00e9t\u00e9 ajout\u00e9 dans les versions exp\u00e9rimentales Chrome Canary<\/a><\/noindex>.
\nLe nouveau manifeste a \u00e9t\u00e9 \u00e9labor\u00e9 dans le cadre de l'initiative<\/a><\/noindex> du renforcement de la s\u00e9curit\u00e9, de la confidentialit\u00e9 et des performances des modules d'extension (l'objectif principal est de simplifier la cr\u00e9ation de modules s\u00e9curis\u00e9s et performants, et de compliquer la cr\u00e9ation de modules non s\u00e9curis\u00e9s et lents).<\/p>\n

Le manifeste est actuellement en phase de test alpha pr\u00e9coce, n'est pas d\u00e9finitif et a \u00e9t\u00e9 ajout\u00e9 pour permettre aux d\u00e9veloppeurs de commencer \u00e0 exp\u00e9rimenter et \u00e0 adapter leurs modules.
\nL'activation du nouveau manifeste est pr\u00e9vue pour l'ann\u00e9e prochaine. Le moment de l'arr\u00eat du support de la seconde version du manifeste n'est pas encore d\u00e9fini.
\n Pour faciliter la migration des modules vers le nouveau manifeste, une liste de contr\u00f4le<\/a><\/noindex>, comprenant les changements auxquels les d\u00e9veloppeurs doivent pr\u00eater attention, a \u00e9t\u00e9 pr\u00e9par\u00e9e.<\/p>\n

Rappelons que l'exigence essentielle ne se casse pas.<\/a><\/noindex> m\u00e9contentement<\/a><\/noindex> un nouvel<\/a><\/noindex> vis-\u00e0-vis du manifeste<\/a><\/noindex> est li\u00e9 \u00e0 l'arr\u00eat du support du mode de blocage de l'API webRequest, qui sera limit\u00e9 au mode en lecture seule. Une exception sera faite uniquement pour l'\u00e9dition Chrome pour entreprises (Chrome for Enterprise), o\u00f9 le support de l'API webRequest sera maintenu. L'entreprise Mozilla a d\u00e9cid\u00e9 de ne pas suivre le nouveau manifeste et de conserver dans Firefox la possibilit\u00e9 d'utiliser pleinement l'API webRequest.<\/p>\n

Au lieu de l'API webRequest pour filtrer le contenu, le nouveau manifeste propose une API d\u00e9clarative declarativeNetRequest<\/a><\/noindex>. Alors que l'API webRequest permettait d'attacher ses propres gestionnaires, ayant un acc\u00e8s complet aux requ\u00eates r\u00e9seau et capables de modifier le trafic \u00e0 la vol\u00e9e, la nouvelle API declarativeNetRequest fournit un acc\u00e8s \u00e0 un moteur int\u00e9gr\u00e9 universel pr\u00eat \u00e0 l'emploi pour le filtrage, traitant seul les r\u00e8gles de blocage, interdisant l'utilisation de ses propres algorithmes de filtrage et ne permettant pas de d\u00e9finir des r\u00e8gles complexes qui se chevauchent en fonction des conditions. <\/p>\n

Le nouveau manifeste pr\u00e9sente \u00e9galement d'autres changements affectant la compatibilit\u00e9 avec les modules. Parmi eux :<\/p>\n