പരസ്യ ബ്ലോക്കറുകൾ ഉപയോഗിക്കുന്ന webRequest API യുടെ നിയന്ത്രണത്തെ Google ന്യായീകരിക്കുന്നു

Chrome ബ്രൗസർ ഡെവലപ്പർമാർ ശ്രമിച്ചു ന്യായീകരിക്കുക webRequest API-യുടെ പ്രവർത്തനരീതി തടയുന്നതിനുള്ള പിന്തുണ നിർത്തലാക്കൽ, അത് നിങ്ങളെ ഈച്ചയിൽ സ്വീകരിച്ച ഉള്ളടക്കം മാറ്റാൻ അനുവദിക്കുകയും പരസ്യങ്ങൾ തടയുന്നതിന് ആഡ്-ഓണുകളിൽ സജീവമായി ഉപയോഗിക്കുകയും ചെയ്യുന്നു,
ക്ഷുദ്രവെയർ, ഫിഷിംഗ്, ഉപയോക്തൃ പ്രവർത്തനത്തിൽ ചാരവൃത്തി, രക്ഷാകർതൃ നിയന്ത്രണങ്ങൾ, സ്വകാര്യത എന്നിവയ്‌ക്കെതിരായ സംരക്ഷണം.

Google-ന്റെ ഉദ്ദേശ്യങ്ങൾ:

• API തടയൽ മോഡ് webRequest ഉയർന്ന വിഭവ ഉപഭോഗത്തിലേക്ക് നയിക്കുന്നു.
  ഈ API ഉപയോഗിക്കുമ്പോൾ, ബ്രൗസർ ആദ്യം നെറ്റ്‌വർക്ക് അഭ്യർത്ഥനയിൽ അടങ്ങിയിരിക്കുന്ന എല്ലാ ഡാറ്റയും ആഡ്-ഓൺ അയയ്‌ക്കുന്നു, ആഡ്-ഓൺ അത് വിശകലനം ചെയ്യുകയും ബ്രൗസറിൽ കൂടുതൽ പ്രോസസ്സിംഗിനായി പരിഷ്‌ക്കരിച്ച പതിപ്പ് നൽകുകയും അല്ലെങ്കിൽ തടയൽ നിർദ്ദേശങ്ങൾ നൽകുകയും ചെയ്യുന്നു. ഈ സാഹചര്യത്തിൽ, പ്രധാന കാലതാമസം ഉണ്ടാകുന്നത് ആഡ്-ഓൺ വഴി ട്രാഫിക് പ്രോസസ്സ് ചെയ്യുന്ന ഘട്ടത്തിലല്ല, മറിച്ച് ആഡ്-ഓണിന്റെ നിർവ്വഹണത്തെ ഏകോപിപ്പിക്കുന്നതിനുള്ള ഓവർഹെഡ് ചെലവുകൾ മൂലമാണ്. പ്രത്യേകിച്ചും, അത്തരം കൃത്രിമത്വങ്ങൾക്ക് പൂരകമാക്കുന്നതിന് ഒരു പ്രത്യേക പ്രക്രിയയുടെ സമാരംഭം ആവശ്യമാണ്, അതുപോലെ തന്നെ ഈ പ്രക്രിയയുമായും ഡാറ്റ സീരിയലൈസേഷൻ മെക്കാനിസങ്ങളുമായും സംവദിക്കാൻ ഐപിസിയുടെ ഉപയോഗം ആവശ്യമാണ്;

• ആഡ്-ഓൺ എല്ലാ ട്രാഫിക്കും താഴ്ന്ന തലത്തിൽ പൂർണ്ണമായും നിയന്ത്രിക്കുന്നു, ഇത് ദുരുപയോഗത്തിനും സ്വകാര്യത ലംഘനങ്ങൾക്കും വലിയ അവസരങ്ങൾ തുറക്കുന്നു. Google സ്ഥിതിവിവരക്കണക്കുകൾ പ്രകാരം, കണ്ടെത്തിയ ക്ഷുദ്ര ആഡ്-ഓണുകളിൽ 42% webRequest API ഉപയോഗിച്ചു. ഓരോ മാസവും, ശരാശരി 1800 ക്ഷുദ്ര ആഡ്-ഓണുകൾ സ്ഥാപിക്കാനുള്ള ശ്രമങ്ങൾ Chrome വെബ് സ്റ്റോർ കാറ്റലോഗിൽ തടയപ്പെടുന്നു. നിർഭാഗ്യവശാൽ, അപവാദം കൂടാതെ എല്ലാ ക്ഷുദ്ര ആഡ്-ഓണുകളും പിടിക്കാൻ അവലോകനം ഞങ്ങളെ അനുവദിക്കുന്നില്ല, അതിനാൽ പരിരക്ഷ വർദ്ധിപ്പിക്കുന്നതിന്, API തലത്തിൽ ആഡ്-ഓണുകൾ പരിമിതപ്പെടുത്താൻ തീരുമാനിച്ചു. എല്ലാ ട്രാഫിക്കിലേക്കും ആക്‌സസ് ഉള്ള ആഡ്-ഓണുകൾ നൽകുക എന്നതാണ് പ്രധാന ആശയം, പക്ഷേ ഉദ്ദേശിച്ച പ്രവർത്തനം നടപ്പിലാക്കാൻ ആവശ്യമായ ഡാറ്റയിലേക്ക് മാത്രം. പ്രത്യേകിച്ചും, ഉള്ളടക്കം തടയുന്നതിന്, എല്ലാ രഹസ്യാത്മക ഉപയോക്തൃ ഡാറ്റയിലേക്കും ആഡ്-ഓൺ പൂർണ്ണ ആക്സസ് നൽകേണ്ടതില്ല;
• നിർദ്ദിഷ്ട മാറ്റിസ്ഥാപിക്കൽ ഡിക്ലറേറ്റീവ് API declarativeNetRequest ഉയർന്ന പ്രകടനമുള്ള ഉള്ളടക്ക ഫിൽട്ടറിംഗിന്റെ എല്ലാ ജോലികളും ശ്രദ്ധിക്കുന്നു, കൂടാതെ ഫിൽട്ടറിംഗ് നിയമങ്ങൾ ലോഡുചെയ്യുന്നതിന് ആഡ്-ഓണുകൾ മാത്രം ആവശ്യമാണ്. ആഡ്-ഓണിന് ട്രാഫിക്കിൽ ഇടപെടാൻ കഴിയില്ല കൂടാതെ ഉപയോക്താവിന്റെ സ്വകാര്യ ഡാറ്റ അലംഘനീയമായി തുടരുന്നു;
• declarativeNetRequest API-യുടെ പ്രവർത്തനക്ഷമതയുടെ അഭാവത്തെക്കുറിച്ചുള്ള നിരവധി അഭിപ്രായങ്ങൾ Google കണക്കിലെടുക്കുകയും ഫിൽട്ടറിംഗ് നിയമങ്ങളുടെ എണ്ണത്തിന്റെ പരിധി ഒരു വിപുലീകരണത്തിന് 30 എന്നതിൽ നിന്ന് ആഗോളതലത്തിൽ പരമാവധി 150 ആയി വിപുലീകരിക്കുകയും ഡൈനാമിക് ചെയ്യാനുള്ള കഴിവ് ചേർക്കുകയും ചെയ്തു. നിയമങ്ങൾ മാറ്റുകയും ചേർക്കുകയും ചെയ്യുക, HTTP തലക്കെട്ടുകൾ നീക്കം ചെയ്യുകയും മാറ്റിസ്ഥാപിക്കുകയും ചെയ്യുക (റഫറർ, കുക്കി, സെറ്റ്-കുക്കി) പാരാമീറ്ററുകൾ അഭ്യർത്ഥിക്കുക;
• എന്റർപ്രൈസസിന്, webRequest API-യുടെ പ്രവർത്തനത്തെ തടയൽ മോഡ് ഉപയോഗിക്കാൻ കഴിയും, കാരണം ആഡ്-ഓണുകൾ ഉപയോഗിക്കുന്നതിനുള്ള നയം നിർണ്ണയിക്കുന്നത് ഇൻഫ്രാസ്ട്രക്ചറിന്റെ സവിശേഷതകൾ മനസ്സിലാക്കുകയും അപകടസാധ്യതകളെക്കുറിച്ച് ബോധവാനായിരിക്കുകയും ചെയ്യുന്ന ഒരു അഡ്മിനിസ്ട്രേറ്ററാണ്. ഉദാഹരണത്തിന്, ജീവനക്കാരുടെ ട്രാഫിക് ഫ്ലോകൾ രേഖപ്പെടുത്തുന്നതിനും ആന്തരിക സംവിധാനങ്ങളുമായി സംയോജിപ്പിക്കുന്നതിനും എന്റർപ്രൈസസിൽ നിർദ്ദിഷ്ട API ഉപയോഗിക്കാം;
• ഗൂഗിളിന്റെ ലക്ഷ്യം പരസ്യം തടയുന്ന ആഡ്-ഓണുകളെ ദുർബലപ്പെടുത്തുകയോ അടിച്ചമർത്തുകയോ ചെയ്യുകയല്ല, മറിച്ച് സുരക്ഷിതവും കൂടുതൽ ശക്തവുമായ പരസ്യ ബ്ലോക്കറുകൾ സൃഷ്ടിക്കാൻ പ്രാപ്തമാക്കുക എന്നതാണ്;
• പുതിയ declarativeNetRequest-നൊപ്പം webRequest API-യുടെ പ്രവർത്തനത്തെ തടയുന്ന രീതി ഉപേക്ഷിക്കാനുള്ള വിമുഖത, രഹസ്യാത്മക ഡാറ്റയിലേക്കുള്ള ആഡ്-ഓണുകളുടെ ആക്‌സസ് പരിമിതപ്പെടുത്താനുള്ള ആഗ്രഹത്താൽ വിശദീകരിക്കപ്പെടുന്നു. നിങ്ങൾ webRequest API അതേപടി ഉപേക്ഷിക്കുകയാണെങ്കിൽ, മിക്ക ആഡോണുകളും കൂടുതൽ സുരക്ഷിതമായ declarativeNetRequest ഉപയോഗിക്കില്ല, കാരണം സുരക്ഷയും പ്രവർത്തനവും തമ്മിൽ തിരഞ്ഞെടുക്കുമ്പോൾ, മിക്ക ഡെവലപ്പർമാരും സാധാരണയായി പ്രവർത്തനക്ഷമത തിരഞ്ഞെടുക്കും.

എതിർപ്പുകൾ ഡെവലപ്പർമാർ കൂട്ടിച്ചേർക്കലുകൾ:

• ആഡ്-ഓൺ ഡെവലപ്പർമാർ നടത്തിയത് പരിശോധനകൾ പരസ്യം തടയുന്ന ആഡ്-ഓണുകളുടെ പ്രകടനത്തിൽ മൊത്തത്തിലുള്ള അപ്രധാനമായ സ്വാധീനം കാണിക്കുക (ടെസ്റ്റിംഗ് സമയത്ത്, വിവിധ ആഡ്-ഓണുകളുടെ പ്രകടനം താരതമ്യം ചെയ്തു, എന്നാൽ തടയൽ മോഡിൽ ഹാൻഡ്‌ലറുകളുടെ നിർവ്വഹണം ഏകോപിപ്പിക്കുന്ന ഒരു അധിക പ്രക്രിയയുടെ ഓവർഹെഡ് കണക്കിലെടുക്കാതെ webRequest API);
• ആഡ്-ഓണുകളിൽ സജീവമായി ഉപയോഗിക്കുന്ന ഒരു API പിന്തുണയ്ക്കുന്നത് പൂർണ്ണമായും നിർത്തുന്നത് പ്രായോഗികമല്ല. ഇത് നീക്കം ചെയ്യുന്നതിനുപകരം, നിങ്ങൾക്ക് ഒരു പ്രത്യേക അനുമതി ചേർക്കാനും ആഡ്-ഓണുകളിൽ അതിന്റെ ഉപയോഗത്തിന്റെ പര്യാപ്തത കർശനമായി നിയന്ത്രിക്കാനും കഴിയും, ഇത് നിരവധി ജനപ്രിയ ആഡ്-ഓണുകളുടെ രചയിതാക്കളെ അവരുടെ ഉൽപ്പന്നങ്ങൾ പൂർണ്ണമായും പുനർനിർമ്മിക്കുന്നതിൽ നിന്ന് സംരക്ഷിക്കുകയും പ്രവർത്തനക്ഷമത കുറയ്ക്കുന്നത് ഒഴിവാക്കുകയും ചെയ്യും;
• ഓവർഹെഡ് ചെലവുകൾ കുറയ്ക്കുന്നതിന്, നിങ്ങൾക്ക് API ഇല്ലാതാക്കാൻ കഴിയില്ല, പക്ഷേ Firefox-ൽ webRequest നടപ്പിലാക്കുന്നതിന് സമാനമായി Promise മെക്കാനിസത്തെ അടിസ്ഥാനമാക്കി റീമേക്ക് ചെയ്യുക;
• നിർദ്ദിഷ്ട ബദൽ, declarativeNetRequest, ആഡ്-ഓൺ ഡെവലപ്പർമാരുടെ പരസ്യ തടയലിനും സുരക്ഷ/സ്വകാര്യതയ്ക്കും വേണ്ടിയുള്ള എല്ലാ ആവശ്യങ്ങളും ഉൾക്കൊള്ളുന്നില്ല, കാരണം ഇത് നെറ്റ്‌വർക്ക് അഭ്യർത്ഥനകളിൽ പൂർണ്ണ നിയന്ത്രണം നൽകുന്നില്ല, ഇഷ്‌ടാനുസൃത ഫിൽട്ടറിംഗ് അൽഗോരിതങ്ങളുടെ ഉപയോഗം അനുവദിക്കുന്നില്ല, അനുവദിക്കുന്നില്ല വ്യവസ്ഥകൾ അനുസരിച്ച് പരസ്പരം ഓവർലാപ്പ് ചെയ്യുന്ന സങ്കീർണ്ണമായ നിയമങ്ങളുടെ ഉപയോഗം;
• declarativeNetRequest API-യുടെ നിലവിലെ അവസ്ഥയിൽ, uBlock Origin, uMatrix ആഡ്-ഓണുകളുടെ നിലവിലുള്ള പ്രവർത്തനക്ഷമത മാറ്റമില്ലാതെ പുനഃസൃഷ്ടിക്കുക അസാധ്യമാണ്, കൂടാതെ Chrome-നുള്ള NoScript പോർട്ടിന്റെ കൂടുതൽ വികസനവും അർത്ഥശൂന്യമാക്കുന്നു;
• വെബ്‌റിക്വസ്റ്റ് API-യുടെ റീഡ്-ഒൺലി, നോൺ-ബ്ലോക്കിംഗ് മോഡ് നിലവിലുണ്ട് എന്നതിനാൽ, എല്ലാ ട്രാഫിക്കും നിയന്ത്രിക്കാൻ ക്ഷുദ്ര ആഡ്-ഓണുകളെ ഇപ്പോഴും അനുവദിക്കുന്നു, എന്നാൽ അതിൽ ഇടപെടാനുള്ള കഴിവ് നൽകുന്നില്ല എന്നതിനാൽ സ്വകാര്യതയെക്കുറിച്ചുള്ള ആശങ്കകൾ വളരെ അകലെയാണ്. ഫ്ലൈ (ഉള്ളടക്കം മാറ്റുക, നിങ്ങളുടെ പരസ്യങ്ങൾ സ്ഥാപിക്കുക, ഖനിത്തൊഴിലാളികളെ പ്രവർത്തിപ്പിക്കുക, ഇൻപുട്ട് ഫോമുകളിലെ ഉള്ളടക്കങ്ങൾ വിശകലനം ചെയ്യുക പേജ് ലോഡിംഗ് പൂർത്തിയാക്കിയ ശേഷം ഉപയോഗിക്കാം);
• ബ്രൗസർ ഡെവലപ്പർമാർ ധീരതയുള്ള, Opera и വിവാൽഡി, Chromium എഞ്ചിനിൽ നിർമ്മിച്ചിരിക്കുന്നത്, അവരുടെ ഉൽപ്പന്നങ്ങളിൽ webRequest തടയൽ മോഡിനുള്ള പിന്തുണ ഉപേക്ഷിക്കാൻ ഉദ്ദേശിക്കുന്നു.

അവലംബം: opennet.ru