Google justifikon kufizimin e webRequest API të përdorur nga bllokuesit e reklamave

Zhvilluesit e shfletuesit Chrome u përpoq justifikoj ndërprerja e mbështetjes për mënyrën e bllokimit të funksionimit të webRequest API, e cila ju lejon të ndryshoni përmbajtjen e marrë në fluturim dhe përdoret në mënyrë aktive në shtesat për bllokimin e reklamave,
mbrojtjen kundër malware, phishing, spiunimin e aktivitetit të përdoruesit, kontrollet prindërore dhe privatësinë.

Motivet e Google:

  • Modaliteti i bllokimit të API webKërkesë çon në konsum të lartë të burimeve.
    Kur përdorni këtë API, shfletuesi së pari i dërgon shtesës të gjitha të dhënat e përfshira në kërkesën e rrjetit, shtesa e analizon atë dhe kthen një version të modifikuar për përpunim të mëtejshëm në shfletues ose lëshon udhëzime bllokimi. Në këtë rast, vonesat kryesore lindin jo në fazën e përpunimit të trafikut nga shtesa, por për shkak të kostove të përgjithshme të koordinimit të ekzekutimit të shtesës. Në veçanti, manipulime të tilla kërkojnë nisjen e një procesi të veçantë për të plotësuar, si dhe përdorimin e IPC për të ndërvepruar me këtë proces dhe mekanizmat e serializimit të të dhënave;

  • Shtesa kontrollon plotësisht të gjithë trafikun në një nivel të ulët, gjë që hap mundësi të mëdha për abuzime dhe shkelje të privatësisë. Sipas statistikave të Google, 42% e të gjitha shtesave me qëllim të keq të zbuluar përdorën webRequest API. Vihet re se çdo muaj, përpjekjet për të vendosur mesatarisht 1800 shtesa me qëllim të keq bllokohen në katalogun e Dyqanit të Uebit të Chrome. Fatkeqësisht, rishikimi nuk na lejon të kapim të gjitha shtesat me qëllim të keq pa përjashtim, kështu që për të rritur mbrojtjen, u vendos që të kufizohen shtesat në nivelin API. Ideja kryesore është të sigurohet shtesa me akses jo në të gjithë trafikun, por vetëm në të dhënat që janë të nevojshme për të zbatuar funksionalitetin e synuar. Në veçanti, për të bllokuar përmbajtjen, nuk është e nevojshme t'i jepet shtesës akses të plotë në të gjitha të dhënat konfidenciale të përdoruesit;
  • API deklarative zëvendësuese e propozuar deklarative RrjetiKërkesë kujdeset për të gjithë punën e filtrimit të përmbajtjes me performancë të lartë dhe kërkon vetëm shtesa për të ngarkuar rregullat e filtrimit. Shtesa nuk mund të ndërhyjë në trafik dhe të dhënat private të përdoruesit mbeten të paprekshme;
  • Google mori parasysh shumë nga komentet në lidhje me mungesën e funksionalitetit të API-së deklarativeNetRequest dhe zgjeroi kufirin e numrit të rregullave të filtrimit nga 30 mijë të propozuara fillimisht për zgjerim në një maksimum global prej 150 mijë, dhe gjithashtu shtoi aftësinë për të ndryshoni dhe shtoni rregullat, hiqni dhe zëvendësoni titujt HTTP (Referer, Cookie, Set-Cookie) dhe parametrat e kërkesës;
  • Për ndërmarrjet, është e mundur të përdoret mënyra e bllokimit të funksionimit të webRequest API, pasi politika për përdorimin e shtesave përcaktohet nga një administrator që kupton veçoritë e infrastrukturës dhe është i vetëdijshëm për rreziqet. Për shembull, API-ja e specifikuar mund të përdoret në ndërmarrje për të regjistruar flukset e trafikut të punonjësve dhe për t'u integruar me sistemet e brendshme;
  • Qëllimi i Google nuk është të minojë ose të shtypë shtesat e bllokimit të reklamave, por të mundësojë krijimin e bllokuesve më të sigurt dhe më të fuqishëm të reklamave;
  • Ngurrimi për të lënë mënyrën e bllokimit të funksionimit të webRequest API së bashku me deklaratën e re NetRequest shpjegohet me dëshirën për të kufizuar aksesin e shtesave në të dhëna konfidenciale. Nëse e lini API-në webRequest siç është, shumica e shtesave nuk do të përdorin deklarativin më të sigurt NetRequest, pasi kur zgjedhin midis sigurisë dhe funksionalitetit, shumica e zhvilluesve zakonisht zgjedhin funksionalitetin.

Kundërshtimet zhvilluesit shtesat:

  • Kryer nga zhvilluesit e shtesave testet tregojnë një ndikim të përgjithshëm të parëndësishëm në performancën e shtesave të bllokimit të reklamave (gjatë testimit, performanca e shtesave të ndryshme u krahasua, por pa marrë parasysh shpenzimet e përgjithshme të një procesi shtesë që koordinon ekzekutimin e mbajtësve në mënyrën e bllokimit të webRequest API);
  • Nuk është praktike të ndalosh plotësisht mbështetjen e një API që përdoret në mënyrë aktive në shtesa. Në vend që ta hiqni atë, mund të shtoni një leje të veçantë dhe të kontrolloni rreptësisht përshtatshmërinë e përdorimit të saj në shtesa, gjë që do t'i shpëtonte autorët e shumë shtesave të njohura nga ripërpunimi i plotë i produkteve të tyre dhe shmangien e funksionimit të prerjes;
  • Për të reduktuar kostot e përgjithshme, nuk mund ta fshini API-në, por ta ribëni atë bazuar në mekanizmin Promise, ngjashëm me zbatimin e webRequest në Firefox;
  • Alternativa e propozuar, deklarativeNetRequest, nuk mbulon të gjitha nevojat e zhvilluesve të shtesave për bllokimin e reklamave dhe sigurinë/privatësinë, pasi nuk ofron kontroll të plotë mbi kërkesat e rrjetit, nuk lejon përdorimin e algoritmeve të filtrimit me porosi dhe nuk lejon përdorimi i rregullave komplekse që mbivendosen me njëra-tjetrën në varësi të kushteve;
  • Me gjendjen aktuale të API-së deklarative NetRequest, është e pamundur të rikrijosh funksionalitetin ekzistues të shtesave uBlock Origin dhe uMatrix të pandryshuar, dhe gjithashtu e bën të pakuptimtë zhvillimin e mëtejshëm të një porti NoScript për Chrome;
  • Shqetësimet në lidhje me privatësinë janë të largëta, pasi mënyra vetëm për lexim, jo-bllokuese e webRequest API është lënë në vend dhe ende lejon shtesat me qëllim të keq të kontrollojnë të gjithë trafikun, por nuk ofron mundësinë për të ndërhyrë me të në fluturoj (ndryshoni përmbajtjen, vendosni reklamat tuaja, ekzekutoni minatorët dhe analizoni përmbajtjen e formularëve të hyrjes mund të përdoren pasi faqja të ketë përfunduar ngarkimin);
  • Zhvilluesit e shfletuesve Trim, Operë и Vivaldi, i ndërtuar në motorin Chromium, synojnë të lënë mbështetje për modalitetin e bllokimit të webRequest në produktet e tyre.

Burimi: opennet.ru

Shto një koment