Google motiverar begränsningen av webRequest API som används av annonsblockerare

Chrome webbläsare utvecklare försökte rättfärdiga upphörande av stödet för blockeringsläget för webRequest API, som låter dig ändra det mottagna innehållet i farten och används aktivt i tillägg för att blockera reklam,
skydd mot skadlig programvara, nätfiske, spioneri på användaraktivitet, föräldrakontroll och integritet.

Googles motiv:

• API-blockeringsläge webRequest leder till hög resursförbrukning.
  När du använder detta API skickar webbläsaren först tillägget all data som finns i nätverksbegäran, tillägget analyserar det och returnerar en modifierad version för vidare bearbetning i webbläsaren eller utfärdar blockeringsinstruktioner. I det här fallet uppstår de huvudsakliga förseningarna inte vid bearbetning av trafiken av tillägget, utan på grund av de allmänna kostnaderna för att samordna genomförandet av tillägget. I synnerhet kräver sådana manipulationer lanseringen av en separat process för att komplettera, liksom användningen av IPC för att interagera med denna process och dataserialiseringsmekanismer;

• Tillägget kontrollerar helt och hållet all trafik på en låg nivå, vilket öppnar stora möjligheter för missbruk och integritetsintrång. Enligt Googles statistik använde 42 % av alla upptäckta skadliga tillägg webRequest API. Det noteras att varje månad blockeras försök att placera i genomsnitt 1800 XNUMX skadliga tillägg i Chrome Web Store-katalogen. Tyvärr tillåter granskning oss inte att fånga alla skadliga tillägg utan undantag, så för att förbättra skyddet beslutades det att begränsa tillägg på API-nivå. Huvudidén är att ge tillägg med åtkomst inte till all trafik, utan bara till den data som är nödvändig för att implementera den avsedda funktionaliteten. I synnerhet för att blockera innehåll är det inte nödvändigt att ge tillägget full tillgång till all konfidentiell användardata;
• Föreslagen ersättningsdeklarativ API declarativeNetRequest tar hand om allt arbete med högpresterande innehållsfiltrering och kräver endast tillägg för att ladda filtreringsregler. Tillägget kan inte störa trafiken och användarens privata data förblir okränkbar;
• Google tog hänsyn till många av kommentarerna angående bristen på funktionalitet hos declarativeNetRequest API och utökade gränsen för antalet filtreringsregler från de initialt föreslagna 30 tusen per tillägg till ett globalt maximum på 150 tusen, och lade också till möjligheten att dynamiskt ändra och lägg till regler, ta bort och ersätta HTTP-rubriker (Referer, Cookie, Set-Cookie) och begärande parametrar;
• För företag är det möjligt att använda blockeringsläget för webRequest API, eftersom policyn för att använda tillägg bestäms av en administratör som förstår funktionerna i infrastrukturen och är medveten om riskerna. Till exempel kan det angivna API:et användas i företag för att registrera anställdas trafikflöden och integrera med interna system;
• Googles mål är inte att undergräva eller undertrycka annonsblockerande tillägg, utan att möjliggöra skapandet av säkrare och mer kraftfulla annonsblockerare;
• Oviljan att lämna blockeringsläget för webRequest API tillsammans med den nya declarativeNetRequest förklaras av önskan att begränsa åtkomsten av tillägg till konfidentiell data. Om du lämnar webRequest API som det är, kommer de flesta tillägg inte att använda den säkrare declarativeNetRequest, eftersom när man väljer mellan säkerhet och funktionalitet kommer de flesta utvecklare vanligtvis att välja funktionalitet.

invändningar utvecklare tillägg:

• Utförs av tilläggsutvecklare tester visa en obetydlig total inverkan på prestandan för annonsblockerande tillägg (under testning jämfördes prestanda för olika tillägg, men utan att ta hänsyn till omkostnaderna för en ytterligare process som koordinerar exekveringen av hanterare i blockeringsläget för webRequest API);
• Det är inte praktiskt att helt sluta stödja ett API som aktivt används i tillägg. Istället för att ta bort det kan du lägga till en separat behörighet och strikt kontrollera om dess användning i tillägg är lämplig, vilket skulle rädda författarna till många populära tillägg från att helt omarbeta sina produkter och undvika att klippa funktionalitet;
• För att minska omkostnader kan du inte ta bort API:t, utan göra om det baserat på Promise-mekanismen, liknande implementeringen av webRequest i Firefox;
• Det föreslagna alternativet, declarativeNetRequest, täcker inte alla behov hos tilläggsutvecklare för annonsblockering och säkerhet/integritet, eftersom det inte ger full kontroll över nätverksförfrågningar, inte tillåter användning av anpassade filtreringsalgoritmer och inte tillåter användningen av komplexa regler som överlappar varandra beroende på förhållandena;
• Med det nuvarande tillståndet för declarativeNetRequest API är det omöjligt att återskapa den befintliga funktionaliteten för tilläggen uBlock Origin och uMatrix oförändrade, och det gör även vidareutveckling av en NoScript-port för Chrome meningslös;
• Oron för integritet är långsökt, eftersom det skrivskyddade, icke-blockerande läget för webRequest API är kvar och fortfarande tillåter skadliga tillägg att kontrollera all trafik, men inte ger möjlighet att störa den på fly (ändra innehåll, placera dina annonser, kör gruvarbetare och analysera innehållet i inmatningsformulären kan användas efter att sidan har laddats klart);
• Webbläsarutvecklare Modig, Opera и Vivaldi, byggd på Chromium-motorn, har för avsikt att lämna stöd för blockeringsläget webRequest i sina produkter.

Källa: opennet.ru