גוגל מצדיקה את ההגבלה של webRequest API המשמש חוסמי פרסומות

מפתחי דפדפן כרום ניסו לְהוֹכִיחַ הפסקת התמיכה במצב החסימה של ה-API של webRequest, המאפשר לך לשנות את התוכן המתקבל תוך כדי שימוש פעיל בתוספות לחסימת פרסום,
הגנה מפני תוכנות זדוניות, דיוג, ריגול אחר פעילות משתמשים, בקרת הורים ופרטיות.

המניעים של גוגל:

• מצב חסימת API webRequest מוביל לצריכת משאבים גבוהה.
  בעת שימוש ב-API זה, הדפדפן שולח לתוסף תחילה את כל הנתונים הכלולים בבקשת הרשת, התוסף מנתח אותם ומחזיר גרסה שונה לעיבוד נוסף בדפדפן או מנפיק הוראות חסימה. במקרה זה, העיכובים העיקריים נוצרים לא בשלב עיבוד התעבורה על ידי התוסף, אלא בשל עלויות התקורה של תיאום ביצוע התוסף. בפרט, מניפולציות כאלה דורשות השקה של תהליך נפרד כדי להשלים, כמו גם שימוש ב-IPC לאינטראקציה עם תהליך זה ומנגנוני הסדרת נתונים;

• התוסף שולט לחלוטין בכל התעבורה ברמה נמוכה, מה שפותח הזדמנויות עצומות לשימוש לרעה והפרות פרטיות. לפי הסטטיסטיקה של גוגל, 42% מכל התוספות הזדוניות שזוהו השתמשו ב-webRequest API. יצוין כי מדי חודש, ניסיונות להציב בממוצע 1800 תוספות זדוניות נחסמות בקטלוג חנות האינטרנט של Chrome. למרבה הצער, סקירה לא מאפשרת לנו לתפוס את כל התוספות הזדוניות ללא יוצא מן הכלל, ולכן כדי לשפר את ההגנה, הוחלט להגביל את התוספות ברמת ה-API. הרעיון המרכזי הוא לספק תוספים עם גישה לא לכל התעבורה, אלא רק לנתונים הדרושים ליישום הפונקציונליות המיועדת. בפרט, כדי לחסום תוכן, אין צורך לתת לתוספת גישה מלאה לכל נתוני המשתמש הסודיים;
• ממשק API הצהרתי מוצע להחלפה declarativeNetRequest דואג לכל העבודה של סינון תוכן בעל ביצועים גבוהים ודורש רק תוספות לטעינת כללי סינון. התוסף אינו יכול להפריע לתנועה והנתונים הפרטיים של המשתמש נותרים בלתי ניתנים להפרה;
• גוגל לקחה בחשבון רבות מההערות בנוגע לחוסר הפונקציונליות של ממשק ה-API declarativeNetRequest והרחיבה את המגבלה על מספר כללי הסינון מ-30 אלף שהוצעו בתחילה לכל הרחבה למקסימום עולמי של 150 אלף, וכן הוסיפה את היכולת באופן דינמי. לשנות ולהוסיף כללים, להסיר ולהחליף כותרות HTTP (Referer, Cookie, Set-Cookie) ופרמטרים של בקשה;
• עבור ארגונים, ניתן להשתמש במצב החסימה של ה-API של webRequest, שכן מדיניות השימוש בתוספים נקבעת על ידי מנהל המבין את תכונות התשתית ומודע לסיכונים. לדוגמה, ה-API שצוין יכול לשמש בארגונים כדי לתעד זרימות תעבורת עובדים ולשלב עם מערכות פנימיות;
• המטרה של גוגל היא לא לערער או לדכא תוספים לחסימת פרסומות, אלא לאפשר יצירת חוסמי פרסומות בטוחים וחזקים יותר;
• הרתיעה מלעזוב את מצב הפעולה החסימה של ה-API של webRequest יחד עם ה-DeclarativeNetRequest החדש מוסברת על ידי הרצון להגביל את הגישה של תוספות לנתונים חסויים. אם תשאיר את ה-API של webRequest כפי שהוא, רוב התוספות לא ישתמשו ב-declarativeNetRequest המאובטח יותר, שכן בעת ​​בחירה בין אבטחה לפונקציונליות, רוב המפתחים לרוב יבחרו בפונקציונליות.

התנגדויות מפתחים תוספות:

• מבוצע על ידי מפתחי תוספים בדיקות להראות השפעה כוללת לא משמעותית על הביצועים של תוספים לחסימת פרסומות (במהלך הבדיקה הושוו ביצועים של תוספות שונות, אך מבלי לקחת בחשבון את התקורה של תהליך נוסף שמתאם את ביצוע המטפלים במצב חסימה של webRequest API);
• זה לא מעשי להפסיק לחלוטין לתמוך ב-API שנמצא בשימוש פעיל בתוספות. במקום להסיר אותו, אתה יכול להוסיף הרשאה נפרדת ולשלוט בקפדנות על נאותות השימוש בו בתוספות, מה שיחסוך למחברים של תוספות פופולריות רבות מלעבד מחדש את המוצרים שלהם ולהימנע מחיתוך פונקציונליות;
• כדי להפחית את עלויות התקורה, לא ניתן למחוק את ה-API, אלא ליצור אותו מחדש על סמך מנגנון ה-Promise, בדומה ליישום webRequest בפיירפוקס;
• החלופה המוצעת, declarativeNetRequest, אינה מכסה את כל הצרכים של מפתחי תוספים לחסימת פרסומות ואבטחה/פרטיות, שכן היא אינה מספקת שליטה מלאה בבקשות הרשת, אינה מאפשרת שימוש באלגוריתמי סינון מותאמים אישית ואינה מאפשרת שימוש בכללים מורכבים החופפים זה לזה בהתאם לתנאים;
• עם המצב הנוכחי של ממשק ה-API declarativeNetRequest, אי אפשר ליצור מחדש את הפונקציונליות הקיימת של התוספות uBlock Origin ו-uMatrix ללא שינוי, וגם הופך פיתוח נוסף של יציאת NoScript עבור Chrome לחסר טעם;
• החששות לגבי פרטיות הם מרחיקי לכת, מכיוון שמצב הקריאה בלבד, שאינו חוסם, של webRequest API נותר במקומו ועדיין מאפשר לתוספות זדוניות לשלוט בכל התעבורה, אך אינו מספק את היכולת להפריע לה ב- fly (שנה תוכן, הצב את הפרסומות שלך, הפעל כורים ונתח את התוכן של טפסי הקלט שניתן להשתמש בהם לאחר סיום טעינת הדף);
• מפתחי דפדפנים אַמִיץ, Opera и ויואלדי, שנבנו על מנוע Chromium, מתכוונים להשאיר תמיכה במצב חסימת webRequest במוצרים שלהם.

מקור: OpenNet.ru