Mae Google yn cyfiawnhau cyfyngu ar yr API WebRequest a ddefnyddir gan atalwyr hysbysebion

Datblygwyr porwr Chrome ceisio cyfiawnhau rhoi'r gorau i gefnogaeth ar gyfer dull gweithredu blocio'r WebRequest API, sy'n eich galluogi i newid y cynnwys a dderbynnir ar y hedfan ac a ddefnyddir yn weithredol mewn ychwanegion ar gyfer rhwystro hysbysebion,
amddiffyniad rhag drwgwedd, gwe-rwydo, ysbïo ar weithgaredd defnyddwyr, rheolaethau rhieni a phreifatrwydd.

Cymhellion Google:

• Modd blocio API gweGais yn arwain at ddefnydd uchel o adnoddau.
  Wrth ddefnyddio'r API hwn, mae'r porwr yn gyntaf yn anfon yr ychwanegyn yr holl ddata sydd wedi'i gynnwys yn y cais rhwydwaith, mae'r ychwanegyn yn ei ddadansoddi ac yn dychwelyd fersiwn wedi'i addasu i'w brosesu ymhellach yn y porwr neu'n cyhoeddi cyfarwyddiadau blocio. Yn yr achos hwn, mae'r prif oedi yn codi nid yn ystod y cam o brosesu traffig gan yr ychwanegiad, ond oherwydd gorbenion cydgysylltu gweithrediad yr ychwanegiad. Yn benodol, mae triniaethau o'r fath yn gofyn am lansio proses ar wahân i ategu, yn ogystal â defnyddio IPC i ryngweithio â'r broses hon a mecanweithiau cyfresoli data;

• Mae'r ychwanegiad yn rheoli'r holl draffig yn llwyr ar lefel isel, sy'n agor cyfleoedd enfawr ar gyfer cam-drin a thorri preifatrwydd. Yn ôl ystadegau Google, defnyddiodd 42% o'r holl ychwanegion maleisus a ganfuwyd yr API WebRequest. Nodir bod ymdrechion i osod 1800 o ychwanegion maleisus ar gyfartaledd yn cael eu rhwystro bob mis yng nghatalog Chrome Web Store. Yn anffodus, nid yw adolygu yn caniatáu inni ddal yr holl ychwanegion maleisus yn ddieithriad, felly er mwyn gwella diogelwch, penderfynwyd cyfyngu ar ychwanegion ar lefel API. Y prif syniad yw darparu ychwanegion â mynediad nid i bob traffig, ond dim ond i'r data sy'n angenrheidiol i weithredu'r swyddogaeth a fwriedir. Yn benodol, i rwystro cynnwys, nid oes angen rhoi mynediad llawn i'r ychwanegyn i'r holl ddata defnyddwyr cyfrinachol;
• API datganiadol newydd arfaethedig declarativeNetRequest yn gofalu am yr holl waith o hidlo cynnwys perfformiad uchel a dim ond ychwanegion sydd ei angen i lwytho rheolau hidlo. Ni all yr ychwanegiad ymyrryd â thraffig ac mae data preifat y defnyddiwr yn parhau i fod yn anorchfygol;
• Cymerodd Google i ystyriaeth lawer o'r sylwadau ynghylch diffyg ymarferoldeb yr API declarativeNetRequest ac ehangodd y terfyn ar nifer y rheolau hidlo o'r 30 mil a gynigiwyd yn wreiddiol fesul estyniad i uchafswm byd-eang o 150 mil, a hefyd ychwanegodd y gallu i ddeinamig newid ac ychwanegu rheolau, dileu a disodli penawdau HTTP (Cyfeiriwr, Cwci, Set-Cwci) a gofyn am baramedrau;
• Ar gyfer mentrau, mae'n bosibl defnyddio dull gweithredu blocio WebRequest API, gan fod y polisi ar gyfer defnyddio ychwanegion yn cael ei bennu gan weinyddwr sy'n deall nodweddion y seilwaith ac sy'n ymwybodol o'r risgiau. Er enghraifft, gellir defnyddio'r API penodedig mewn mentrau i gofnodi llif traffig gweithwyr ac integreiddio â systemau mewnol;
• Nid nod Google yw tanseilio neu atal ychwanegion blocio hysbysebion, ond i alluogi creu atalwyr hysbysebion mwy diogel a phwerus;
• Mae'r amharodrwydd i adael y dull blocio o weithredu'r API WebRequest ynghyd â'r declarativeNetRequest newydd yn cael ei esbonio gan yr awydd i gyfyngu ar fynediad ychwanegion i ddata cyfrinachol. Os byddwch yn gadael yr API WebRequest fel y mae, ni fydd y rhan fwyaf o ategion yn defnyddio'r declarativeNetRequest mwy diogel, oherwydd wrth ddewis rhwng diogelwch ac ymarferoldeb, bydd y rhan fwyaf o ddatblygwyr fel arfer yn dewis ymarferoldeb.

Gwrthwynebiadau datblygwyr ychwanegiadau:

• Wedi'i gynnal gan ddatblygwyr ychwanegion profion dangos effaith gyffredinol ansylweddol ar berfformiad ychwanegion blocio hysbysebion (yn ystod y profion, gwnaethom gymharu perfformiad amrywiol ychwanegion, ond heb ystyried gorbenion proses ychwanegol sy'n cydlynu gweithrediad trinwyr yn y modd blocio o yr API webRequest);
• Nid yw'n ymarferol rhoi'r gorau i gefnogi API sy'n cael ei ddefnyddio'n weithredol mewn ychwanegion yn llwyr. Yn hytrach na chael gwared arno, gallwch ychwanegu caniatâd ar wahân a rheoli'n llym ddigonolrwydd ei ddefnydd mewn ychwanegion, a fyddai'n arbed awduron llawer o ychwanegion poblogaidd rhag ail-weithio eu cynhyrchion yn llwyr ac osgoi torri ymarferoldeb;
• Er mwyn lleihau costau gorbenion, ni allwch ddileu'r API, ond ei ail-wneud yn seiliedig ar y mecanwaith Addewid, yn debyg i weithredu webRequest yn Firefox;
• Nid yw'r dewis amgen arfaethedig, declarativeNetRequest, yn cwmpasu holl anghenion datblygwyr ychwanegion ar gyfer blocio hysbysebion a diogelwch/preifatrwydd, gan nad yw'n darparu rheolaeth lawn dros geisiadau rhwydwaith, nid yw'n caniatáu defnyddio algorithmau hidlo arferol, ac nid yw'n caniatáu y defnydd o reolau cymhleth sy'n gorgyffwrdd â'i gilydd yn dibynnu ar yr amodau;
• Gyda chyflwr presennol yr API declarativeNetRequest, mae'n amhosibl ail-greu ymarferoldeb presennol yr ychwanegion uBlock Origin ac uMatrix heb eu newid, ac mae hefyd yn gwneud datblygiad pellach o borthladd NoScript ar gyfer Chrome yn ddibwrpas;
• Mae pryderon ynghylch preifatrwydd yn bell iawn, gan fod modd darllen yn unig, di-rwystro API WebRequest yn cael ei adael yn ei le ac yn dal i ganiatáu ychwanegion maleisus i reoli'r holl draffig, ond nid yw'n darparu'r gallu i ymyrryd ag ef ar y hedfan (newid cynnwys, gosod eich hysbysebion, rhedeg glowyr a dadansoddi cynnwys y ffurflenni mewnbwn gellir ei ddefnyddio ar ôl i'r dudalen orffen llwytho);
• Datblygwyr porwr Dewr, Opera и Vivaldi, wedi'i adeiladu ar yr injan Chromium, yn bwriadu gadael cefnogaeth ar gyfer y modd blocio webRequest yn eu cynhyrchion.

Ffynhonnell: opennet.ru