Simeon Vincent, Chrome-uitbreidingsontwikkelaarsadvokaat, Chrome-spanleier, Google se huidige posisie oor die derde hersiening van die Chrome-manifes, baie byvoegings om onvanpaste inhoud te blokkeer en sekuriteit te verseker. Die maatskappy is nie van plan om die oorspronklike plan te laat vaar om op te hou om die blokkeringsmodus van die webRequest API te ondersteun nie, wat jou toelaat om die aanvaarde inhoud dadelik te verander. 'n Uitsondering sal slegs gemaak word vir die ondernemingsuitgawe van Chrome (), wat die webRequest API-ondersteuning ongeskonde sal hou.
Vir gewone Chrome API-gebruikers sal beperk word tot leesalleen-modus. 'n Verklarende API is voorgestel om die webRequest API vir inhoudfiltrering te vervang , wat slegs 'n beperkte deel van die kenmerke dek wat in moderne advertensieblokkeerders gebruik word. Trouens, in plaas van sy eie hanteerders wat volle toegang tot netwerkversoeke het, word 'n klaargemaakte universele ingeboude filterenjin aangebied wat blokkeerreëls op sy eie verwerk. Byvoorbeeld, die declarativeNetRequest API laat jou nie toe om jou eie filteralgoritmes te gebruik nie en laat jou nie toe om komplekse reëls te skep wat mekaar oorvleuel na gelang van toestande nie.
Die ontwikkelaars van advertensieblokkerende byvoegings het gesamentlik voorberei , wat die tekortkominge van die declarativeNetRequest API gelys het. Google het met baie van die opmerkings saamgestem en die declarativeNetRequest API bygevoeg. Ondersteuning is veral bygevoeg om reëls dinamies te verander en by te voeg, en dit was moontlik om HTTP-opskrifte te verwyder, maar slegs dié in die witlys (Referer, Cookie, Set-Cookie). Daar is planne om ondersteuning te implementeer vir die byvoeging en vervanging van HTTP-opskrifte (byvoorbeeld vir die vervanging van Set-Cookie- en CSP-aanwysings) en die vermoë om versoekparameters te verwyder en te vervang.
'n Konsepweergawe van die derde weergawe van die manifes, wat die lys kenmerke en hulpbronne definieer wat deur Chrome-byvoegings verskaf word, word beplan om in die komende maande vir toetsing in eksperimentele weergawes van Chrome Canary gebruik te word.
Terselfdertyd bly die motivering om veranderinge aan die aanvaarde inhoud deur die webRequest API te verbied nie heeltemal duidelik nie. Bewerings dat die blokkeermodus van die webRequest API 'n negatiewe impak op werkverrigting het, aangesien die blaaier wag vir die voltooiing van die voltooiinghanteerder voordat die bladsy gelewer word, staan nie teen ondersoek nie. Voorheen gehou Die werkverrigting van advertensieblokkerende byvoegings het getoon dat die vertraging wat hulle bekendstel, weglaatbaar is. Gemiddeld vertraag die gebruik van 'n blokker die uitvoering van 'n versoek met slegs 'n fraksie van millisekondes, wat teen die algemene agtergrond weglaatbaar is.
Die tweede argument, wat verband hou met die begeerte om gebruikers te beskerm teen onbeheerde toegang tot inhoudbyvoegings, lyk ook nie oortuigend nie, want in plaas daarvan om die lang gevestigde en algemene funksionaliteit in wettige byvoegings te verwyder, kan jy 'n nuwe tipe toestemming en gee die gebruiker die finale keuse, installeer 'n byvoeging wat volle toegang tot netwerkversoeke het of nie. Boonop het Google ondersteuning gelaat vir die gebruik van die webRequest API in leesalleenmodus, wat volledige verkeersmonitering moontlik maak, maar nie laevlak-inmenging daarmee nie.
Byvoegings kan die inhoud van afgelaaide webblaaie deur ander API's verander (byvoorbeeld, kwaadwillige byvoegings kan steeds hul advertensies lewer, mynwerkers laat loop en die inhoud van invoervorms ontleed).
Raymond Hill, skrywer van die uBlock Origin en uMatrix ongewenste inhoudblokkeringstelsels, is taai genoeg die reaksie van 'n Google-verteenwoordiger en geskimp na demagogie en agter-die-skerms-speletjies waarin Google, onder die dekmantel van 'n goeie geleentheid, probeer om sy besigheidsbelange op die gebied van aanlyn-advertensies te bevorder, beheer te verkry oor sy filtermeganismes en regverdig hierdie optrede in die oë van die algemene publiek.
Hy het geen oortuigende argumente ontvang vir die behoefte om die API, wat wydverspreid en in aanvraag is onder ontwikkelaars van byvoegings, te stop nie. Na Raymond se mening is die prestasiedaling nie 'n argument nie, aangesien bladsye stadig laai as gevolg van hul opblaas, en nie as gevolg van die gebruik van webRequest-blokkeermodus in korrek geïmplementeerde byvoegings nie. As Google regtig omgegee het vir prestasie, sou hulle webRequest herontwerp het op grond van die , na analogie van webRequest in Firefox.
Volgens Raymond is Google se strategie om die regte balans te vind tussen die uitbreiding van die gebruikersbasis van Chrome en die skade aan besigheid wat veroorsaak word deur die gebruik van inhoudblokkeerders. In die eerste stadium van Chrome se uitbreiding moes Google advertensieblokkeerders verdra as een van die gewildste byvoegings onder gebruikers. Maar nadat Chrome oorheersing verkry het, het die maatskappy probeer om die weegskaal in sy guns te kantel en beheer oor blokkering te verkry deur die bevordering van om onvanpaste advertensieblokkering in Chrome in te sluit. Die webRequest API verslaan hierdie doel, aangesien inhoudblokkeringsbeheer nou in die hande van derdeparty-advertensieblokkeringsontwikkelaars is.
Bron: opennet.ru