Google જાહેરાત અવરોધકો દ્વારા ઉપયોગમાં લેવાતા webRequest API ના પ્રતિબંધને યોગ્ય ઠેરવે છે

ક્રોમ બ્રાઉઝર ડેવલપર્સ પ્રયાસ કર્યો વાજબી ઠેરવવું webRequest API ના ઑપરેશનના બ્લૉકિંગ મોડ માટે સમર્થન બંધ કરવું, જે તમને ફ્લાય પર પ્રાપ્ત સામગ્રીને બદલવાની મંજૂરી આપે છે અને જાહેરાતને અવરોધિત કરવા માટે ઍડ-ઑન્સમાં સક્રિયપણે ઉપયોગમાં લેવાય છે,
માલવેર, ફિશિંગ, વપરાશકર્તા પ્રવૃત્તિ પર જાસૂસી, પેરેંટલ નિયંત્રણો અને ગોપનીયતા સામે રક્ષણ.

Google ના હેતુઓ:

• API અવરોધિત મોડ વેબ વિનંતી ઉચ્ચ સંસાધન વપરાશ તરફ દોરી જાય છે.
  આ API નો ઉપયોગ કરતી વખતે, બ્રાઉઝર સૌપ્રથમ નેટવર્ક વિનંતીમાં સમાવિષ્ટ તમામ ડેટા એડ-ઓનને મોકલે છે, એડ-ઓન તેનું વિશ્લેષણ કરે છે અને બ્રાઉઝરમાં આગળની પ્રક્રિયા માટે સંશોધિત સંસ્કરણ પરત કરે છે અથવા અવરોધિત સૂચનાઓ આપે છે. આ કિસ્સામાં, મુખ્ય વિલંબ એડ-ઓન દ્વારા ટ્રાફિકની પ્રક્રિયાના તબક્કે નથી, પરંતુ એડ-ઓનના અમલને સંકલન કરવાના ઓવરહેડ ખર્ચને કારણે થાય છે. ખાસ કરીને, આવા મેનિપ્યુલેશન્સને પૂરક બનાવવા માટે એક અલગ પ્રક્રિયા શરૂ કરવાની જરૂર છે, તેમજ આ પ્રક્રિયા અને ડેટા સીરીયલાઇઝેશન મિકેનિઝમ્સ સાથે ક્રિયાપ્રતિક્રિયા કરવા માટે IPCનો ઉપયોગ;

• એડ-ઓન નિમ્ન સ્તરે તમામ ટ્રાફિકને સંપૂર્ણપણે નિયંત્રિત કરે છે, જે દુરુપયોગ અને ગોપનીયતાના ઉલ્લંઘન માટે વિશાળ તકો ખોલે છે. ગૂગલના આંકડા અનુસાર, તમામ શોધાયેલ દૂષિત એડ-ઓન્સમાંથી 42% એ webRequest API નો ઉપયોગ કર્યો હતો. નોંધનીય છે કે દર મહિને, ક્રોમ વેબ સ્ટોર કેટેલોગમાં સરેરાશ 1800 દૂષિત એડ-ઓન મૂકવાના પ્રયાસોને અવરોધિત કરવામાં આવે છે. કમનસીબે, સમીક્ષા કરવાથી અમને અપવાદ વિના તમામ દૂષિત ઍડ-ઑન્સ પકડવાની મંજૂરી મળતી નથી, તેથી સુરક્ષા વધારવા માટે, API સ્તરે ઍડ-ઑન્સને મર્યાદિત કરવાનો નિર્ણય લેવામાં આવ્યો હતો. મુખ્ય વિચાર એ છે કે તમામ ટ્રાફિકની ઍક્સેસ સાથે એડ-ઓન પ્રદાન કરવું નહીં, પરંતુ ફક્ત તે ડેટાને પ્રદાન કરવું જે હેતુપૂર્વક કાર્યક્ષમતાને અમલમાં મૂકવા માટે જરૂરી છે. ખાસ કરીને, સામગ્રીને અવરોધિત કરવા માટે, એડ-ઓનને તમામ ગોપનીય વપરાશકર્તા ડેટાની સંપૂર્ણ ઍક્સેસ આપવી જરૂરી નથી;
• સૂચિત રિપ્લેસમેન્ટ ઘોષણાત્મક API declarativeNetRequest ઉચ્ચ-પ્રદર્શન સામગ્રી ફિલ્ટરિંગના તમામ કાર્યની કાળજી લે છે અને ફિલ્ટરિંગ નિયમો લોડ કરવા માટે ફક્ત એડ-ઓનની જરૂર છે. એડ-ઓન ટ્રાફિકમાં દખલ કરી શકતું નથી અને વપરાશકર્તાનો ખાનગી ડેટા અવિશ્વસનીય રહે છે;
• Google એ declarativeNetRequest API ની કાર્યક્ષમતાના અભાવને લગતી ઘણી ટિપ્પણીઓને ધ્યાનમાં લીધી અને ફિલ્ટરિંગ નિયમોની મર્યાદાને શરૂઆતમાં સૂચિત 30 હજાર પ્રતિ એક્સ્ટેંશનથી વધારીને વૈશ્વિક મહત્તમ 150 હજાર કરી, અને ગતિશીલ રીતે કરવાની ક્ષમતા પણ ઉમેરી. નિયમો બદલો અને ઉમેરો, HTTP હેડરો દૂર કરો અને બદલો (રેફરર, કૂકી, સેટ-કુકી) અને પરિમાણોની વિનંતી કરો;
• એન્ટરપ્રાઇઝ માટે, વેબરિક્વેસ્ટ API ના ઑપરેશનના અવરોધિત મોડનો ઉપયોગ કરવો શક્ય છે, કારણ કે એડ-ઓન્સનો ઉપયોગ કરવાની નીતિ એક એડમિનિસ્ટ્રેટર દ્વારા નક્કી કરવામાં આવે છે જે ઇન્ફ્રાસ્ટ્રક્ચરની સુવિધાઓને સમજે છે અને જોખમોથી વાકેફ છે. ઉદાહરણ તરીકે, ઉલ્લેખિત API નો ઉપયોગ એન્ટરપ્રાઇઝમાં કર્મચારી ટ્રાફિક પ્રવાહને રેકોર્ડ કરવા અને આંતરિક સિસ્ટમો સાથે સંકલિત કરવા માટે કરી શકાય છે;
• Google નું ધ્યેય એડ-ઓન્સને અવરોધિત કરવાનું અથવા તેને દબાવવાનું નથી, પરંતુ વધુ સુરક્ષિત અને વધુ શક્તિશાળી જાહેરાત બ્લોકર્સની રચનાને સક્ષમ કરવાનું છે;
• નવી declarativeNetRequest સાથે webRequest API ના ઓપરેશનના બ્લોકીંગ મોડને છોડવાની અનિચ્છા ગોપનીય ડેટા સુધી એડ-ઓનની ઍક્સેસને મર્યાદિત કરવાની ઇચ્છા દ્વારા સમજાવવામાં આવી છે. જો તમે webRequest API જેમ છે તેમ છોડો છો, તો મોટાભાગના એડઓન્સ વધુ સુરક્ષિત declarativeNetRequest નો ઉપયોગ કરશે નહીં, કારણ કે સુરક્ષા અને કાર્યક્ષમતા વચ્ચે પસંદગી કરતી વખતે, મોટાભાગના વિકાસકર્તાઓ સામાન્ય રીતે કાર્યક્ષમતા પસંદ કરશે.

વાંધો વિકાસકર્તાઓ ઉમેરાઓ:

• એડ-ઓન ડેવલપર્સ દ્વારા હાથ ધરવામાં આવે છે પરીક્ષણો જાહેરાત અવરોધિત એડ-ઓન્સના પ્રદર્શન પર એક નજીવી એકંદર અસર દર્શાવે છે (પરીક્ષણ દરમિયાન, વિવિધ એડ-ઓન્સના પ્રદર્શનની તુલના કરવામાં આવી હતી, પરંતુ વધારાની પ્રક્રિયાના ઓવરહેડને ધ્યાનમાં લીધા વિના જે બ્લોકિંગ મોડમાં હેન્ડલર્સના અમલને સંકલન કરે છે. webRequest API);
• ઍડ-ઑન્સમાં સક્રિય રીતે ઉપયોગમાં લેવાતા API ને સમર્થન આપવાનું સંપૂર્ણપણે બંધ કરવું વ્યવહારુ નથી. તેને દૂર કરવાને બદલે, તમે એક અલગ પરવાનગી ઉમેરી શકો છો અને ઍડ-ઑન્સમાં તેના ઉપયોગની પર્યાપ્તતાને સખત રીતે નિયંત્રિત કરી શકો છો, જે ઘણા લોકપ્રિય ઍડ-ઑન્સના લેખકોને તેમના ઉત્પાદનોને સંપૂર્ણપણે પુનઃકાર્ય કરવાથી બચાવશે અને કાર્યક્ષમતામાં ઘટાડો કરવાનું ટાળશે;
• ઓવરહેડ ખર્ચ ઘટાડવા માટે, તમે API ને કાઢી શકતા નથી, પરંતુ ફાયરફોક્સમાં webRequest ના અમલીકરણની જેમ પ્રોમિસ મિકેનિઝમના આધારે તેને ફરીથી બનાવી શકો છો;
• સૂચિત વૈકલ્પિક, declarativeNetRequest, જાહેરાત અવરોધિત કરવા અને સુરક્ષા/ગોપનીયતા માટે એડ-ઓન ડેવલપર્સની તમામ જરૂરિયાતોને આવરી લેતું નથી, કારણ કે તે નેટવર્ક વિનંતીઓ પર સંપૂર્ણ નિયંત્રણ પ્રદાન કરતું નથી, કસ્ટમ ફિલ્ટરિંગ અલ્ગોરિધમ્સના ઉપયોગને મંજૂરી આપતું નથી અને મંજૂરી આપતું નથી. જટિલ નિયમોનો ઉપયોગ જે શરતોના આધારે એકબીજાને ઓવરલેપ કરે છે;
• declarativeNetRequest API ની વર્તમાન સ્થિતિ સાથે, uBlock Origin અને uMatrix ઍડ-ઑન્સની હાલની કાર્યક્ષમતાને યથાવત રીતે ફરીથી બનાવવી અશક્ય છે, અને Chrome માટે NoScript પોર્ટના વધુ વિકાસને અર્થહીન બનાવે છે;
• ગોપનીયતા વિશેની ચિંતાઓ દૂરની વાત છે, કારણ કે ફક્ત-વાંચવા માટે, webRequest API નો બિન-અવરોધિત મોડ સ્થાને બાકી છે અને તે હજુ પણ દૂષિત એડ-ઓનને તમામ ટ્રાફિકને નિયંત્રિત કરવાની મંજૂરી આપે છે, પરંતુ તેની સાથે દખલ કરવાની ક્ષમતા પ્રદાન કરતું નથી. ફ્લાય (સામગ્રી બદલો, તમારી જાહેરાતો મૂકો, માઇનર્સ ચલાવો અને ઇનપુટ ફોર્મની સામગ્રીનું વિશ્લેષણ કરો, પૃષ્ઠ લોડ કરવાનું સમાપ્ત થયા પછી ઉપયોગ કરી શકાય છે);
• બ્રાઉઝર વિકાસકર્તાઓ બહાદુર, ઓપેરા и વિવાલ્ડી, ક્રોમિયમ એન્જિન પર બનેલ, તેમના ઉત્પાદનોમાં webRequest બ્લોકિંગ મોડ માટે સમર્થન છોડવાનો ઇરાદો ધરાવે છે.

સોર્સ: opennet.ru