Chrome browser ûntwikkelers beëinigjen fan stipe foar de blokkearjende modus fan wurking fan 'e webRequest API, wêrtroch jo de ûntfongen ynhâld op 'e flecht kinne feroarje en aktyf wurdt brûkt yn tafoegings foar blokkearjen fan reklame,
beskerming tsjin malware, phishing, spying op brûkersaktiviteit, âlderlike kontrôles en privacy.
De motiven fan Google:
- API-blokkearjende modus liedt ta hege boarne konsumpsje.
By it brûken fan dizze API stjoert de browser de tafoeging earst alle gegevens yn it netwurkfersyk, de add-on analysearret it en jout in wizige ferzje werom foar fierdere ferwurking yn 'e browser of jout blokkearjende ynstruksjes. Yn dit gefal ûntsteane de wichtichste fertragingen net op it poadium fan it ferwurkjen fan ferkear troch de add-on, mar troch de overheadkosten fan it koördinearjen fan de útfiering fan 'e add-on. Benammen sokke manipulaasjes fereaskje de lansearring fan in apart proses om oan te foljen, en ek it brûken fan IPC om te ynteraksje mei dit proses en data serialisaasjemeganismen; - De tafoeging kontroleart folslein alle ferkear op in leech nivo, wat grutte kânsen iepenet foar misbrûk en privacyskendings. Neffens Google-statistiken brûkte 42% fan alle ûntdutsen kweade add-ons de webRequest API. It wurdt opmurken dat elke moanne besykjen om gemiddeld 1800 kweade add-ons te pleatsen wurde blokkearre yn 'e Chrome Web Store-katalogus. Spitigernôch lit beoardieling ús net sûnder útsûndering alle kweade tafoegings fange, dus om beskerming te ferbetterjen waard besletten om tafoegings op API-nivo te beheinen. It haadidee is om tafoegings te jaan mei tagong net ta alle ferkear, mar allinich foar de gegevens dy't nedich binne om de bedoelde funksjonaliteit út te fieren. Benammen om ynhâld te blokkearjen, is it net nedich om de add-on folsleine tagong te jaan ta alle fertroulike brûkersgegevens;
- Foarstelde ferfangende declarative API soarget foar al it wurk fan heechweardige ynhâldfiltering en fereasket allinich tafoegings om filterregels te laden. De tafoeging kin net ynterferearje mei ferkear en de priveegegevens fan de brûker bliuwe ûnoantaaste;
- Google hat rekken holden mei in protte fan 'e opmerkings oangeande it gebrek oan funksjonaliteit fan' e declarativeNetRequest API en wreide de limyt op it oantal filterregels út fan 'e ynearsten foarstelde 30 tûzen per útwreiding nei in wrâldwide maksimum fan 150 tûzen, en tafoege ek de mooglikheid om dynamysk wizigje en tafoegje regels, ferwiderje en ferfange HTTP-koppen (Referer, Cookie, Set-Cookie) en fersyk parameters;
- Foar bedriuwen is it mooglik om de blokkearjende modus fan wurking fan 'e webRequest API te brûken, om't it belied foar it brûken fan tafoegings wurdt bepaald troch in behearder dy't de funksjes fan' e ynfrastruktuer begrypt en bewust is fan 'e risiko's. Bygelyks, de oantsjutte API kin brûkt wurde yn bedriuwen foar it opnimmen fan wurknimmersferkearstreamen en yntegrearje mei ynterne systemen;
- It doel fan Google is net om tafoegings foar blokkearjen fan advertinsjes te ûndergraven of te ûnderdrukken, mar om it meitsjen fan feiliger en machtiger advertinsjeblokkers mooglik te meitsjen;
- De ûnwilligens om de blokkearjende wurkwize fan 'e webRequest API te ferlitten tegearre mei de nije declarativeNetRequest wurdt ferklearre troch de winsk om de tagong fan tafoegings te beheinen ta fertroulike gegevens. As jo de webRequest API litte sa't it is, sille de measte tafoegings de feiliger declarativeNetRequest net brûke, om't by it kiezen tusken feiligens en funksjonaliteit, de measte ûntwikkelders gewoanlik funksjonaliteit kieze.
:
- Utfierd troch tafoegingsûntwikkelders in ûnbedoelde totale ynfloed sjen litte op de prestaasjes fan add-ons foar blokkearjen fan advertinsjes (by testen waarden de prestaasjes fan ferskate tafoegings fergelike, mar sûnder rekken te hâlden mei de overhead fan in ekstra proses dat de útfiering fan hannelers koördineart yn 'e blokkearjende modus fan de webRequest API);
- It is net praktysk om folslein te stopjen mei it stypjen fan in API dy't aktyf wurdt brûkt yn tafoegings. Yn stee fan it fuortheljen, kinne jo in aparte tastimming tafoegje en de adekwaatheid fan har gebrûk yn tafoegings strikt kontrolearje, wat de auteurs fan in protte populêre tafoegings besparje soe fan it folslein opnij bewurkjen fan har produkten en foarkommen fan besunigingsfunksjonaliteit;
- Om overheadkosten te ferminderjen, kinne jo de API net wiskje, mar opnij meitsje op basis fan it Promise-meganisme, fergelykber mei de ymplemintaasje fan webRequest yn Firefox;
- It foarstelde alternatyf, declarativeNetRequest, dekt net alle behoeften fan tafoegingsûntwikkelders foar advertinsjeblokkering en feiligens/privacy, om't it gjin folsleine kontrôle leveret oer netwurkoanfragen, it brûken fan oanpaste filteralgoritmen net tastean en net tastean it brûken fan komplekse regels dy't inoar oerlappe ôfhinklik fan 'e betingsten;
- Mei de hjoeddeistige tastân fan 'e declarativeNetRequest API is it ûnmooglik om de besteande funksjonaliteit fan' e uBlock Origin en uMatrix tafoegings net te feroarjen, en makket ek fierdere ûntwikkeling fan in NoScript-poarte foar Chrome sinleas;
- Soargen oer privacy binne fierstente, om't de allinich-lêzen, net-blokkearjende modus fan 'e webRequest API op syn plak wurdt litten en noch altyd kweade tafoegings mooglik makket om al it ferkear te kontrolearjen, mar jout net de mooglikheid om har te bemuoien mei de fleane (feroarje ynhâld, pleats jo advertinsjes, rinne miners en analysearje de ynhâld fan 'e ynfierformulieren kinne brûkt wurde nei't de side foltôge is mei laden);
- Browser-ûntwikkelders , и , boud op 'e Chromium-motor, binne fan doel om stipe foar de webRequest-blokkearjende modus yn har produkten te ferlitten.
Boarne: opennet.ru