גוגל ממשיכה להתעקש להגביל את ה-API שדורשים חוסמי פרסומות

סימאון וינסנט, עו"ד מפתחי תוספי Chrome, ראש צוות של Chrome, הגיב העמדה הנוכחית של גוגל לגבי הגרסה השלישית של מניפסט Chrome, מפרה עבודה תוספות רבות לחסימת תוכן בלתי הולם ולהבטחת אבטחה. החברה לא מתכוונת לזנוח את התוכנית המקורית להפסיק לתמוך במצב החסימה של ה-API של webRequest, המאפשר לך לשנות את התוכן המקובל תוך כדי תנועה. ייעשה חריג רק עבור המהדורה הארגונית של Chrome (Chrome for Enterprise), מה שישמור על תמיכת ה-API של webRequest ללא פגע.

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

מפתחי תוספים חוסמי פרסומות הכינו במשותף רשימת הערות, אשר פירטה את החסרונות של ממשק ה-API declarativeNetRequest. גוגל הסכימה עם הרבה מההערות והוסיפה את ה-API declarativeNetRequest. בפרט, נוספה תמיכה בשינוי והוספה דינמית של כללים, וניתן היה להסיר כותרות HTTP, אך רק את אלו שברשימה הלבנה (Referer, Cookie, Set-Cookie). ישנן תוכניות ליישם תמיכה בהוספה והחלפה של כותרות HTTP (לדוגמה, להחלפת הוראות Set-Cookie ו-CSP) ויכולת להסיר ולהחליף פרמטרים של בקשה.

גרסת טיוטה של ​​הגרסה השלישית של המניפסט, המגדירה את רשימת התכונות והמשאבים המסופקים על ידי תוספות Chrome, מתוכננת לשמש לבדיקות בגירסה ניסיונית של Chrome Canary בחודשים הקרובים.

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

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

ריימונד היל, מחבר מערכות חסימת התוכן הלא רצוי uBlock Origin ו-uMatrix, קשוח מספיק הגיב תגובתו של נציג גוגל ורמז על דמגוגיה ומשחקים מאחורי הקלעים שבהם גוגל, במסווה של הזדמנות טובה, מנסה לקדם את האינטרסים העסקיים שלה בתחום הפרסום המקוון, להשיג שליטה על מנגנוני הסינון שלה. להצדיק פעולות אלו בעיני הציבור הרחב.

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

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

מקור: OpenNet.ru