{"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\/es\/blog\/news\/v-chrome-nachalos-testirovanie-tretej-redaktsii-manifesta-nesovmestimoj-s-ublock-origin","title":{"rendered":"En Chrome se ha comenzado a probar la tercera edici\u00f3n del manifiesto, incompatible con uBlock Origin.","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

La empresa Google Empez\u00f3 la prueba<\/a><\/noindex> de la tercera edici\u00f3n del manifiesto de Chrome, que infringe<\/a><\/noindex> el funcionamiento<\/a><\/noindex> de muchas extensiones para bloquear contenido no deseado y garantizar la seguridad. El soporte para el nuevo manifiesto, que define las capacidades y recursos proporcionados a las extensiones, se ha a\u00f1adido en versiones experimentales. Chrome Canary<\/a><\/noindex>.
\nEl nuevo manifiesto ha sido desarrollado en el marco de la iniciativa<\/a><\/noindex> de la mejora de la seguridad, la privacidad y el rendimiento de las extensiones (el objetivo principal es simplificar la creaci\u00f3n de extensiones seguras y de alto rendimiento, y dificultar la creaci\u00f3n de extensiones inseguras y lentas).<\/p>\n

El manifiesto todav\u00eda est\u00e1 en fase de pruebas alpha tempranas, no es definitivo y se ha a\u00f1adido para permitir a los desarrolladores comenzar a experimentar y adaptar sus extensiones.
\nSe espera que la activaci\u00f3n del nuevo manifiesto ocurra el pr\u00f3ximo a\u00f1o. El momento de finalizaci\u00f3n del soporte de la segunda edici\u00f3n del manifiesto a\u00fan no est\u00e1 determinado.
\n Para facilitar la migraci\u00f3n de las extensiones al nuevo manifiesto, se ha preparado una lista de verificaci\u00f3n<\/a><\/noindex>, que incluye cambios a los que los desarrolladores de extensiones deben prestar atenci\u00f3n.<\/p>\n

Recordemos que principal<\/a><\/noindex> descontento<\/a><\/noindex> con el nuevo<\/a><\/noindex> manifiesto<\/a><\/noindex> relacionado con la finalizaci\u00f3n del soporte del modo de bloqueo de la API webRequest, que se limitar\u00e1 a un modo solo de lectura. La \u00fanica excepci\u00f3n ser\u00e1 para la edici\u00f3n de Chrome para empresas (Chrome for Enterprise), donde se conservar\u00e1 el soporte de la API webRequest. Mozilla ha decidido no seguir el nuevo manifiesto y mantener en Firefox la posibilidad de uso completo de la API webRequest.<\/p>\n

En lugar de la API webRequest para filtrar contenido, el nuevo manifiesto propone una API declarativa. declarativeNetRequest<\/a><\/noindex>. Si la API webRequest permit\u00eda conectar controladores propios, que tienen acceso completo a las solicitudes de red y pueden modificar el tr\u00e1fico sobre la marcha, la nueva API declarativeNetRequest proporciona acceso a un motor integrado universal para filtrar, que maneja autom\u00e1ticamente las reglas de bloqueo, no permitiendo el uso de sus propios algoritmos de filtrado ni la definici\u00f3n de reglas complejas que se superpongan entre s\u00ed dependiendo de las condiciones. <\/p>\n

El nuevo manifiesto tambi\u00e9n presenta otros cambios que afectan la compatibilidad con las extensiones. Entre ellos:<\/p>\n