Guglo pravigas la limigon de la webRequest API uzata de reklamblokiloj

Programistoj de Chrome retumilo provis pravigi ĉesigo de subteno por la bloka reĝimo de funkciado de la webRequest API, kiu ebligas al vi ŝanĝi la ricevitan enhavon sur la flugo kaj estas aktive uzata en aldonaĵoj por blokado de reklamado,
protekto kontraŭ malware, phishing, spionado de uzantagado, gepatra kontrolo kaj privateco.

Motivoj de Google:

• API-bloka reĝimo retejoPeto kondukas al alta konsumo de rimedoj.
  Kiam oni uzas ĉi tiun API, la retumilo unue sendas al la aldonaĵo ĉiujn datumojn enhavitajn en la reto-peto, la aldonaĵo analizas ĝin kaj resendas modifitan version por plua prilaborado en la retumilo aŭ eldonas blokajn instrukciojn. En ĉi tiu kazo, la ĉefaj prokrastoj aperas ne en la stadio de prilaborado de trafiko per la aldonaĵo, sed pro la superkostoj de kunordigado de la ekzekuto de la aldonaĵo. Aparte, tiaj manipuladoj postulas la lanĉon de aparta procezo por kompletigi, same kiel la uzon de IPC por interagi kun ĉi tiu procezo kaj datumaj seriigmekanismoj;

• La aldonaĵo tute kontrolas la tutan trafikon je malalta nivelo, kio malfermas vastajn ŝancojn por misuzo kaj privateco-malobservoj. Laŭ Guglo-statistiko, 42% de ĉiuj detektitaj malicaj aldonaĵoj uzis la webRequest API. Oni rimarkas, ke ĉiumonate, provoj meti mezumon de 1800 malicaj aldonaĵoj estas blokitaj en la katalogo de Chrome Web Store. Bedaŭrinde, reviziado ne permesas al ni kapti ĉiujn malicajn aldonaĵojn senescepte, do por plibonigi protekton, oni decidis limigi aldonaĵojn ĉe la API-nivelo. La ĉefa ideo estas provizi aldonaĵojn kun aliro ne al la tuta trafiko, sed nur al la datumoj necesaj por efektivigi la celitan funkcion. Aparte, por bloki enhavon, ne necesas doni al la aldonaĵo plenan aliron al ĉiuj konfidencaj uzantdatenoj;
• Proponita anstataŭiga deklara API declarativeNetRequest prizorgas la tutan laboron de alt-efikeca enhavfiltrado kaj nur postulas aldonaĵojn por ŝargi filtrajn regulojn. La aldonaĵo ne povas malhelpi trafikon kaj la privataj datumoj de la uzanto restas netuŝeblaj;
• Google konsideris multajn komentojn pri la manko de funkcieco de la deklaracia NetRequest API kaj vastigis la limon de la nombro da filtraj reguloj de la komence proponita 30 mil per etendo ĝis tutmonda maksimumo de 150 mil, kaj ankaŭ aldonis la kapablon dinamike. ŝanĝu kaj aldonu regulojn, forigu kaj anstataŭigu HTTP-kapojn (Referer, Kuketo, Aro-Kuketo) kaj petu parametrojn;
• Por entreprenoj, eblas uzi la blokan operacion de la webRequest API, ĉar la politiko por uzi aldonaĵojn estas determinita de administranto, kiu komprenas la funkciojn de la infrastrukturo kaj konscias pri la riskoj. Ekzemple, la specifita API povas esti uzata en entreprenoj por registri dungitajn trafikfluojn kaj integri kun internaj sistemoj;
• La celo de Guglo ne estas subfosi aŭ subpremi reklam-blokantajn aldonaĵojn, sed ebligi la kreadon de pli sekuraj kaj pli potencaj reklamblokiloj;
• La malemo forlasi la blokan operacion de la webRequest API kune kun la nova deklaraNetRequest estas klarigita per la deziro limigi la aliron de aldonaĵoj al konfidencaj datumoj. Se vi lasas la webRequest API tia, la plej multaj aldonaĵoj ne uzos la pli sekuran deklaranNetRequest, ĉar elektante inter sekureco kaj funkcieco, plej multaj programistoj kutime elektos funkciecon.

Obĵetoj programistoj aldonoj:

• Kondukita de aldonaj programistoj testoj montri sensignifan ĝeneralan efikon al la agado de aldonaĵoj pri blokado de reklamoj (dum testado, la agado de diversaj aldonaĵoj estis komparita, sed sen konsideri la superkompeton de plia procezo, kiu kunordigas la ekzekuton de pritraktantoj en la blokada reĝimo de la webRequest API);
• Ne estas praktike tute ĉesi subteni API, kiu estas aktive uzata en aldonaĵoj. Anstataŭ forigi ĝin, vi povas aldoni apartan permeson kaj strikte kontroli la taŭgecon de ĝia uzo en aldonaĵoj, kio savus la aŭtorojn de multaj popularaj aldonaĵoj de tute reverkado de siaj produktoj kaj evitus tranĉi funkciojn;
• Por redukti superkostojn, vi ne povas forigi la API, sed refari ĝin surbaze de la Promise-mekanismo, simile al la efektivigo de webRequest en Firefox;
• La proponita alternativo, declarativeNetRequest, ne kovras ĉiujn bezonojn de aldonaj programistoj por reklamblokado kaj sekureco/privateco, ĉar ĝi ne disponigas plenan kontrolon de retaj petoj, ne permesas la uzon de kutimaj filtraj algoritmoj kaj ne permesas. la uzo de kompleksaj reguloj, kiuj interkovras unu la alian depende de la kondiĉoj;
• Kun la nuna stato de la declarativeNetRequest API, estas neeble rekrei la ekzistantan funkciecon de la uBlock Origin kaj uMatrix-aldonaĵoj senŝanĝe, kaj ankaŭ faras pluevoluigon de NoScript-haveno por Chrome sencela;
• Zorgoj pri privateco estas malproksime, ĉar la nurlegebla, ne-bloka reĝimo de la webRequest API estas lasita en loko kaj daŭre permesas malicajn aldonaĵojn kontroli la tutan trafikon, sed ne disponigas la kapablon malhelpi ĝin sur la flugi (ŝanĝu enhavon, metu viajn reklamojn, kuru ministojn kaj analizu la enhavon de la enigformularoj povas esti uzata post kiam la paĝo finŝarĝis);
• Programistoj de retumilo kuraĝa, opero и Vivaldi, konstruitaj sur la Chromium-motoro, intencas lasi subtenon por la reĝimo de blokado de Request en siaj produktoj.

fonto: opennet.ru