Manifest V3 הקרובה עבור תוספי Google Chrome ישנה את אופן הפעולה של חוסמי פרסומות ב-Chrome. האם זו הדרך הנכונה קדימה עבור חוסמי פרסומות וגוגל?
גוגל כרום הוא דפדפן האינטרנט חוצה הפלטפורמות הפופולרי ביותר הזמין בשוק כרגע, בטענה ל-62.7% מנתח השימוש בדפדפן העולמי עד מאי 2019, עם ספארי של אפל במקום השני עם 15.89% ו-Firefox של מוזילה תובע 5.07%. בגלל חלק הארי שלה, השינויים הקטנים ביותר שגוגל כרום מבצעת עבור הפלטפורמה שלה משפיעים בסופו של דבר על מיליוני משתמשים ברחבי העולם. אז כשגוגל הכריזה על גרסת מניפסט ההרחבות הבאה בצורה של Manifest V3 עבור הרחבות של Google Chrome, ידענו שאנחנו היו צפויים לכמה שינויים גדולים, במיוחד כשהתברר שגוגל בנתה ממשק API של חוסם תוכן בתוך Chrome עצמו.
מה זה Manifest V3?
אם אתה משתמש Chrome פעיל, אתה ללא ספק משתמש בכמה הרחבות. הרחבות הן תוכנות קטנות המותאמות אישית את חווית הגלישה באמצעות ממשקי API שהדפדפן מספק, המאפשר למשתמשים להתאים את הפונקציונליות וההתנהגות כדי להתאים לצרכים ולהעדפות האישיות שלהם. הרחבות אלו מופצות בעיקר דרך ה חנות האינטרנט של Chrome, שהוא ביתם של יותר מ-180,000 שלוחות.
מאז בסוף השנה שעברה, גוגל עבדה על "Manifest V3", קבוצה של שינויים מוצעים לפלטפורמת תוספי Chrome שניתן לסווג כ"שינויים שוברים". בתור ה מסמך דיון ציבורי עבור Manifest V3 קובע, גרסת מניפסט ההרחבה היא מנגנון להגבלת יכולות מסוימות למחלקה מסוימת של הרחבות. הגבלות אלו יכולות להיות בצורת גרסה מינימלית או גרסה מקסימלית. הגבלה לגרסה מינימלית מאפשרת לממשקי API או ליכולות חדשות יותר להיות זמינות רק להרחבות חדשות יותר בעוד שהגבלה לגרסת מניפסט מקסימלית מאפשרת לממשקי API או ליכולות ישנות יותר להיות בהדרגה הוצא משימוש.
במילים פשוטות יותר, גרסת מניפסט חדשה מאפשרת ל-Chrome להגביל ממשקי API ותכונות לגרסת מניפסט חדשה זו, ב כדי לאלץ מפתחי תוספים לעבור הרחק ממשקי API ישנים מסוימים בגלל ההשפעה השלילית שלהם על המשתמש ניסיון. יישום הרחבה ב- Manifest V3 אמור לספק ערבויות חזקות יותר מנקודות מבט של אבטחה, פרטיות וביצועים.
אמנם יש מגוון רחב של שינויים המתוארים במניפסט V3, אבל השינוי השנוי ביותר במחלוקת נוגע להחלטת גוגל להגביל את יכולות החסימה הקיימות בגרסה הקיימת chrome.webRequest API (ולמקד את ה-API סביב תצפית במקום חסימה) ולאחר מכן הצג את יכולות החסימה הללו באמצעות חדש chrome.declarativeNetRequest ממשק API. לשינוי הספציפי הזה יש הלהיב את הקהילה כשהיא בסופו של דבר מתמקדת במנגנון חסימת הפרסומות של התוסף המפורסם לחסימת פרסומות, מקור uBlock, ומשפיע ישירות על 10 מיליון המשתמשים שלו.
לפני שנתייחס לבעיה זו, בואו נסתכל כיצד webRequest API בהשוואה ל declarativeNetRequest ממשק API.
Web Request API ו-Declarative Net Request API
ההווה
התיאור הרשמי של Web Request מתאר את ה-API באופן הבא:
Use the chrome.webRequest API to observe and analyze traffic and to intercept, block, or modify requests in-flight.
עם Web Request, Chrome שולח את כל הנתונים בבקשת רשת לשלוחה מאזינה עבורה. לאחר מכן, לתוסף יש הזדמנות להעריך את הבקשה ולהורות ל-Chrome מה לעשות עם הבקשה: לאפשר אותה, לחסום אותה או לשלוח אותה עם שינויים מסוימים.
עקוב אחר רצף האירועים כדי להבין מה קורה כאשר תוספים משתמשים ב-Web Request API. כאשר משתמש עם תוסף Web Request מותקן לוחץ על קישור, Chrome מודיע לתוסף שנעשתה בקשת נתונים לפני שהבקשה מגיעה לשרת. ההרחבה יכולה לבחור לשנות את הבקשה בשלב זה. לאחר מכן השרת מגיב, אבל התגובה שוב עוברת דרך התוסף, וההרחבה יכולה להכתיב אם יש לשנות את התגובה. לאחר מכן Chrome מעבד לבסוף את הדף והמשתמש יכול לראות את התוצאה של פעולת הקליק שלו.
כפי שכרום מוסר כל הנתונים בבקשת רשת, הרחבות המשתמשות ב-Web Request API יש גישה לקרוא ולשנות כל מה שמשתמש עושה באינטרנט. אז בעוד שחוסמי תוכן כמו uBlock Origin מנצלים בחוכמה את הפוטנציאל של API זה, גוגל טוענת כי תוספים אחרים עם כוונות זדוניות ניצלו אותו לרעה כדי לקבל גישה למשתמשים האישיים מֵידָע. לפי גוגל, 42% מההרחבות הזדוניות השתמשו ב-Web Request API מאז ינואר 2018. גוגל גם טוענת שיש "עלויות ביצועים משמעותיות" הכרוכות ב-API כגרסה החוסמת זה דורש תהליך מתמשך ולעתים קרובות ארוך טווח שאינו תואם ביסודו עם 'עצלן' תהליכים.
עם Manifest V3, גוגל מציעה להגביל את ה-API הזה בצורת החסימה שלו. כחלופה, Google מספקת את ממשק ה-API של Net Request Declarative.
העתיד
התיאור הרשמי של Declarative Net Request מתאר את ה-API באופן הבא:
The chrome.declarativeNetRequest API is used to block or modify network requests by specifying declarative rules.
עם Declarative Net Request, Chrome אינו צריך לשלוח את כל המידע על בקשה לתוסף ההאזנה. במקום זאת, התוסף רושם כללים ב-Chrome שאומרים לדפדפן מראש מה לעשות אם רואים סוגים מסוימים של בקשות.
ההרחבה מפרטת את חוקיה מראש. לאחר מכן, בקשת המשתמשים מתאימה לכלל זה על ידי הדפדפן (ולא התוסף), והפעולה מתבצעת גם על ידי הדפדפן, והדף מעובד לאחר מכן. גוגל מזכירה שזה מאפשר להם להבטיח יעילות מכיוון שהם יכולים להפעיל שליטה על האלגוריתם הקובע את התוצאה ויכול למנוע או להשבית כללים לא יעילים. זה גם מציג הבטחות פרטיות טובות יותר למשתמש הקצה מכיוון שפרטי בקשת הרשת אינם חשופים להרחבה. מאחר שכבר אין צורך בתהליכים מתמשכים וארוכי טווח (מאחר שהכללים נרשמו מראש), גוגל טוענת כי גישה זו מביאה גם שיפורי ביצועים שיהפכו את ההרחבות לבעלות קיימא משמעותית על משאבים מוגבלים פלטפורמות.
בקשת רשת הצהרתית תהיה זמינה גם ל-Manfest V2 (נוכחי) וגם ל-Manfest V3, אבל זו תהיה הדרך העיקרית שבה Google תאפשר לשנות בקשות רשת ב-Manfest V3.
המחלוקת
נראה שהשינויים של גוגל הגיוניים עד שתשמע את הצד השני של הסיפור, בעיקר זה של חוסמי פרסומות. העברת ה-API הספציפית הזו נתפסת כדרך של גוגל להרוג חוסמי פרסומות מכיוון שהיא משנה מהותית את הדרך שבה פועל אחד מחוסמי הפרסומות הפופולריים ביותר. זה מתקשר ל"תיאוריה" לפיה גוגל מונעת לקראת השינוי הזה יותר מנקודת המבט העסקית מאשר מנקודת המבט של אבטחת המשתמש. אחרי הכל, גוגל מסתמכת במידה רבה על פרסום לצורך הכנסותיה, וחוסמי פרסומות נתפסים כאיום ישיר על לקוחות גוגל בחזית זו, כפי שנחשף באמצעות הגשת טופס 10-K של Alphabet לשנת 2018 (באמצעות הקופה):
טכנולוגיות חדשות וקיימות עלולות להשפיע על היכולת שלנו להתאים אישית מודעות ו/או עלולות לחסום מודעות מקוונות, מה שיפגע בעסק שלנו.
טכנולוגיות פותחו כדי להקשות על מודעות הניתנות להתאמה אישית או לחסום את הצגת המודעות לחלוטין וחלק מהספקים של השירותים המקוונים יש טכנולוגיות משולבות שעלולות לפגוע בפונקציונליות הליבה של צד שלישי דיגיטלי פִּרסוּם. רוב ההכנסות שלנו בגוגל נגזרות מעמלות ששולמו לנו בקשר להצגת מודעות באינטרנט. כתוצאה מכך, טכנולוגיות וכלים כאלה עלולים להשפיע לרעה על תוצאות התפעול שלנו.
גוגל היה חייב לשחרר הצהרה כדי לטפל בכך, וחוזרת על עמדתה לפיה השינוי הוא אינטרס של פרטיות המשתמש ולא מתקפה ישירה נגד חוסמי פרסומות:
אנחנו לא מונעים פיתוח של חוסמי פרסומות או מונעים ממשתמשים לחסום פרסומות. במקום זאת, אנחנו רוצים לעזור למפתחים, כולל חוסמי תוכן, לכתוב הרחבות באופן שמגן על פרטיות המשתמשים.
יש להתייחס לשניים מחוסמי הפרסומות הפופולריים ביותר הזמינים ב-Google Chrome: מקור uBlock ו Adblock Plus, שניהם נוקטים בגישות שונות כדי להשיג את אותה תוצאה של חסימת תוכן. uBlock Origin מסתמכת במידה רבה על Web Request API, והקהילה קיבלה עדיפות להרחבה זו לאורך השנים. Adblock Plus ותוספי חסימת תוכן אחרים מסתמכים גם הם על החלק החוסם של Web Request, כך ששינויים ב-API זה ישפיעו בסופו של דבר על רוב חוסמי התוכן לפחות בקיבולת מסוימת.
הדחיפה של גוגל לבטל את Web Request תהרוג בעצם את uBlock Origin בפורמט הנוכחי שלה, משהו שאכן ישפיע על הרבה משתמשים. בעוד שמשתמשים ללא נאמנות (ובלי כוונה להטריד את עצמם כיצד משיגים את חסימת המודעות) ימצאו פתרונות חלופיים שמגיעים עם חסרונות משלהם, זה יהפוך לבלתי אפשרי לנאמנים ולחובבים להמציא עיצובים חדשים של מנועי סינון כדי לעקוף את הטכניקות השונות שאתרי אינטרנט יעלו בסופו של דבר כדי להילחם בחוסמי פרסומות ב-API הספציפי הזה.
Declarative Net Request הוצע גם הוא להיות מנוע סינון מוגבל למדי, כפי שהיה תוכנן בתחילה יש מגבלה של 30,000 כללים על כללי סינון סטטיים לכל הרחבה (כללים המוצהרים במהלך ההתקנה); ומגבלה של 5,000 כללים על כללי סינון דינמיים לכל הרחבה (כללים שניתן להוסיף לאחר ההתקנה). כל עודף כללים יתעלמו, וזו קצת בעיה מכיוון של EasyList עבור Adblock Plus עצמו יש 70,000 כללים, בעוד ש-uBlock Origin יכול להיות מוגדר כך שיפעל עם יותר מ-100,000 כללים. לאחר התגובה הראשונית מהקהילה, גוגל הגיבה על ידי הבטחה לשנות את מגבלת החוק הסטטי מ-30,000 כללים לכל הרחבה למקסימום עולמי של 150,000 כללים. אז יש לכך תופעת לוואי של מניעת שימוש בסקריפטים כבדי כללים אחרים בשילוב עם חוסם פרסומות, כך שהמשתמשים יצטרכו להטוט עם ההעדפות שלהם.
מלבד מגבלת הסינון המוגבלת, בקשה נטו הצהרתית יכול להפנות רק לכתובות URL סטטיות, כך שאין תמיכה כלולה בהתאמת דפוסים. uBlock Origin מסתמכת מאוד על התאמת דפוסים ועל מפתח ההרחבה ציינו כי לא ניתן לבצע שיפוץ בדיעבד אלגוריתם ההתאמה של התוסף שלו כדי לעמוד בדרישת ה-API. ה-API ידרוש גם עדכון מלא של הרחבה כדי פשוט לעדכן את רשימת המסננים, שזו תהיה פעילות תכופה מדי בהתחשב ב תדירות שבה מתעדכנות רשימות המסננים הללו. כמובן, עדכונים אלו יהיו תלויים גם בקריטריונים ובתהליכים של Google לבדיקת התוספות.
מצד שני, גוגל תמיד שמרה על עמדתה לפיה כוונתה להתרחק מ-Web Request היא מ- פרספקטיבה אבטחה, שכן ה-Web Request API חזק מדי בצורתו הנוכחית ומשאיר עבורו מקום רחב מאוד התעללות. ניצול לרעה זה אינו רק תיאורטי, מכיוון שגוגל ציינה ש-42% מהרחבות זדוניות ניצלו לרעה את ה-API הזה. של אפל ספארי API של חוסם תוכן תוכנן כמו Declarative Net Request מסיבות דומות, מכיוון שיש פחות מקום למפתח נוכל לנצל. ב-Web Request, בקשות רשת עדיין יהיו ניתנות לצפייה, אך הן יצטרכו הרשאות במארחים הרלוונטיים. עם Manifest V3, גם הרשאות המארח משתנות באופן משמעותי ולא ניתן עוד להעניק אותן באופן גורף בזמן ההתקנה.
גוגל השתמשה גם בתקורות ביצועים כמניע למעבר. הערכה של בקשות רשת מתרחשת בשרשור JavaScript של התוסף, דבר שעלול לעלות ביוקר בביצועים. כהפרכה, המפתח של uBlock Origin מזכיר שהסיומת שלו אינו גורר עונש ביצוע משמעותי אפילו כשיש לאכוף עד 140,000 מסננים סטטיים. לטענת העלויות שנגרמו, ניתן לשחזר בקלות על ידי המשאבים המונעים הורדה משרתים מרוחקים ולכן אינם מעובדים על ידי הדפדפן.
למרות שגוגל לא משתמשת בנימוק הזה, ניתן להעלות טיעון אחד נגד Web Request ליעילות חסימת מודעות. עם Web Request, אם הרחבה לא מגיבה בזמן (בגלל פיגור או קריסה), בקשת הטיפול ברשת מותרת באופן ברור, מה שמאפשר למודעות לחמוק דרך חוסם המודעות. מצד שני, בקשה נטו הצהרתית לא תסבול מהחיסרון הזה. במקום זאת, מודעות יעברו אם הן לא ייתפסו במסגרת הכללים הסטטיים, וזה יקרה לעתים קרובות יותר מאשר לא.
סיכום
מההסברים לעיל, ברור ש-Declarative Net Request אינו שיבוט פונקציונלי של 1:1 לחסימה היכולות של ה-Web Request API, ומפתחי הרחבות ירגישו מוטרדים כאשר העבודה הקשה שלהם תיפגע על ידי שינויים כאלה. אבל להגיון של גוגל יש גם משקל -- Web Request היא חזקה מדי, והכוחות שלה צריכים להיות מצומצם לטובת העניין הגדול יותר של קהילת המשתמשים (המורכבת ממשתמשים ממוצעים יחד עם חובבי).
המהלך לעבר Declarative Net Request יכול היה להיות גם מהלך יחסי יחסי ציבור חיובי - אחרי הכל, גוגל מוסיפה ממשק API מובנה של חוסם תוכן לכרום! אבל מכיוון שה-API החדש מגיע עם הגבלות כבדות משלו, הקהילה רואה בכך בצדק כגזירת כנפיים. בעולם אידיאלי, גוגל הייתה צריכה לחקור את פעולתם של חוסמי פרסומות כמו uBlock Origin לפני שדחפה את ה-API החדש. כפי שהוא נראה כעת, ה-API החדש יכול להשתמש בהקלות נוספות במגבלות הכללים שלו כדי להתאים לתרחישים שבהם משתמשים ירצו להשתמש בשני הרחבות כבדות מסננים.
לפי הקופה, הרכיבים הראשונים עם שינויים ב- Manifest V3 יהיו זמינים מיולי 2019 ואילך. אנו מקווים ש-Google תענה על המשוב שהתקבל מקהילת מפתחי ההרחבות עם הבנייה הללו.
תודה מיוחדת לעורך הראשי של XDA, מישאל רחמן, על תשומותיו ועזרתו!
עריכה: המאמר השווה באופן שגוי את העבודה של Adblock Plus לזו של Declarative Net Request API. המאמר תוקן בהתאם. Adblock Plus יושפע גם מהסרת יכולות החסימה של Web Request API.