کروم براؤزر ڈویلپرز WebRequest API کے آپریشن کے بلاکنگ موڈ کے لیے سپورٹ کا بند کرنا، جو آپ کو موصول ہونے والے مواد کو فلائی پر تبدیل کرنے کی اجازت دیتا ہے اور اشتہارات کو مسدود کرنے کے لیے ایڈ آنز میں فعال طور پر استعمال ہوتا ہے،
میلویئر، فشنگ، صارف کی سرگرمیوں کی جاسوسی، والدین کے کنٹرول اور رازداری کے خلاف تحفظ۔
گوگل کے مقاصد:
- API بلاک کرنے کا موڈ اعلی وسائل کی کھپت کی طرف جاتا ہے.
اس API کا استعمال کرتے وقت، براؤزر پہلے ایڈ آن کو نیٹ ورک کی درخواست میں موجود تمام ڈیٹا بھیجتا ہے، ایڈ آن اس کا تجزیہ کرتا ہے اور براؤزر میں مزید کارروائی کے لیے ترمیم شدہ ورژن واپس کرتا ہے یا بلاک کرنے کی ہدایات جاری کرتا ہے۔ اس صورت میں، اہم تاخیر ایڈ آن کے ذریعے ٹریفک کو پروسیس کرنے کے مرحلے پر نہیں، بلکہ ایڈ آن کے عمل کو مربوط کرنے کے اوور ہیڈ اخراجات کی وجہ سے ہوتی ہے۔ خاص طور پر، اس طرح کی ہیرا پھیری کو تکمیل کے لیے ایک علیحدہ عمل کے آغاز کی ضرورت ہوتی ہے، ساتھ ہی اس عمل اور ڈیٹا سیریلائزیشن کے طریقہ کار کے ساتھ تعامل کے لیے IPC کے استعمال کی ضرورت ہوتی ہے۔ - ایڈ آن تمام ٹریفک کو نچلی سطح پر مکمل طور پر کنٹرول کرتا ہے، جس سے بدسلوکی اور رازداری کی خلاف ورزیوں کے وسیع مواقع کھلتے ہیں۔ گوگل کے اعدادوشمار کے مطابق، تمام پائے جانے والے نقصان دہ ایڈ آنز میں سے 42% نے webRequest API کا استعمال کیا۔ واضح رہے کہ کروم ویب سٹور کیٹلاگ میں ہر ماہ اوسطاً 1800 نقصان دہ ایڈ آنز کو بلاک کر دیا جاتا ہے۔ بدقسمتی سے، جائزہ لینے سے ہمیں بغیر کسی استثنا کے تمام نقصان دہ ایڈ آنز پکڑنے کی اجازت نہیں ملتی، اس لیے تحفظ کو بڑھانے کے لیے، API کی سطح پر ایڈ آنز کو محدود کرنے کا فیصلہ کیا گیا۔ مرکزی خیال تمام ٹریفک تک رسائی کے ساتھ ایڈ آنز فراہم کرنا ہے، بلکہ صرف اس ڈیٹا تک جو مطلوبہ فعالیت کو نافذ کرنے کے لیے ضروری ہے۔ خاص طور پر، مواد کو بلاک کرنے کے لیے، یہ ضروری نہیں ہے کہ ایڈ آن کو صارف کے تمام خفیہ ڈیٹا تک مکمل رسائی دی جائے۔
- مجوزہ متبادل اعلاناتی API اعلی کارکردگی والے مواد کی فلٹرنگ کے تمام کام کا خیال رکھتا ہے اور فلٹرنگ کے قواعد کو لوڈ کرنے کے لیے صرف ایڈ آنز کی ضرورت ہوتی ہے۔ ایڈ آن ٹریفک میں مداخلت نہیں کر سکتا اور صارف کا نجی ڈیٹا ناقابل تسخیر رہتا ہے۔
- Google نے declarativeNetRequest API کی فعالیت کی کمی کے حوالے سے بہت سے تبصروں کو مدنظر رکھا اور فلٹرنگ قوانین کی تعداد کی حد کو ابتدائی طور پر تجویز کردہ 30 ہزار فی ایکسٹینشن سے بڑھا کر عالمی زیادہ سے زیادہ 150 ہزار تک بڑھا دیا، اور متحرک طور پر اس کی صلاحیت کو بھی شامل کیا۔ تبدیل کریں اور قواعد شامل کریں، HTTP ہیڈرز کو ہٹائیں اور تبدیل کریں (ریفرر، کوکی، سیٹ-کوکی) اور پیرامیٹرز کی درخواست کریں؛
- انٹرپرائزز کے لیے، webRequest API کے آپریشن کے بلاکنگ موڈ کا استعمال کرنا ممکن ہے، کیونکہ ایڈ آنز استعمال کرنے کی پالیسی ایک ایسے منتظم کے ذریعے طے کی جاتی ہے جو انفراسٹرکچر کی خصوصیات کو سمجھتا ہو اور خطرات سے آگاہ ہو۔ مثال کے طور پر، مخصوص API کو ملازمین کے ٹریفک کے بہاؤ کو ریکارڈ کرنے اور اندرونی نظاموں کے ساتھ مربوط کرنے کے لیے انٹرپرائزز میں استعمال کیا جا سکتا ہے۔
- گوگل کا مقصد اشتہارات کو مسدود کرنے والے ایڈز کو کمزور کرنا یا دبانا نہیں ہے، بلکہ زیادہ محفوظ اور زیادہ طاقتور اشتہار بلاکرز کی تخلیق کو فعال کرنا ہے۔
- نئے declarativeNetRequest کے ساتھ webRequest API کے آپریشن کے بلاکنگ موڈ کو چھوڑنے میں ہچکچاہٹ کی وضاحت خفیہ ڈیٹا تک ایڈ آنز کی رسائی کو محدود کرنے کی خواہش سے ہوتی ہے۔ اگر آپ webRequest API کو اسی طرح چھوڑ دیتے ہیں، تو زیادہ تر ایڈونز زیادہ محفوظ declarativeNetRequest استعمال نہیں کریں گے، کیونکہ سیکیورٹی اور فعالیت کے درمیان انتخاب کرتے وقت، زیادہ تر ڈویلپر عام طور پر فعالیت کا انتخاب کریں گے۔
:
- ایڈ آن ڈویلپرز کی طرف سے منعقد اشتہارات کو مسدود کرنے والے ایڈ آنز کی کارکردگی پر ایک غیر معمولی مجموعی اثر دکھائیں (ٹیسٹنگ کے دوران، مختلف ایڈ آنز کی کارکردگی کا موازنہ کیا گیا، لیکن ایک اضافی عمل کے اوور ہیڈ کو مدنظر رکھے بغیر جو کہ بلاکنگ موڈ میں ہینڈلرز کے عمل کو مربوط کرتا ہے۔ webRequest API)؛
- کسی ایسے API کو مکمل طور پر سپورٹ کرنا بند کرنا عملی نہیں ہے جو ایڈ آنز میں فعال طور پر استعمال ہوتا ہے۔ اسے ہٹانے کے بجائے، آپ ایک علیحدہ اجازت شامل کر سکتے ہیں اور ایڈ آنز میں اس کے استعمال کی مناسبیت کو سختی سے کنٹرول کر سکتے ہیں، جو بہت سے مشہور ایڈ آنز کے مصنفین کو اپنی مصنوعات کو مکمل طور پر دوبارہ کام کرنے سے بچائے گا اور فعالیت میں کمی سے بچ جائے گا۔
- اوور ہیڈ اخراجات کو کم کرنے کے لیے، آپ API کو حذف نہیں کر سکتے ہیں، لیکن اسے وعدے کے طریقہ کار کی بنیاد پر دوبارہ بنا سکتے ہیں، جیسا کہ Firefox میں webRequest کے نفاذ کی طرح ہے۔
- مجوزہ متبادل، declarativeNetRequest، ایڈ بلاکنگ اور سیکیورٹی/پرائیویسی کے لیے ایڈ آن ڈویلپرز کی تمام ضروریات کو پورا نہیں کرتا، کیونکہ یہ نیٹ ورک کی درخواستوں پر مکمل کنٹرول فراہم نہیں کرتا، اپنی مرضی کے مطابق فلٹرنگ الگورتھم کے استعمال کی اجازت نہیں دیتا، اور اس کی اجازت نہیں دیتا۔ پیچیدہ قوانین کا استعمال جو حالات کے لحاظ سے ایک دوسرے کو اوورلیپ کرتے ہیں؛
- declarativeNetRequest API کی موجودہ حالت کے ساتھ، uBlock Origin اور uMatrix add-ons کی موجودہ فعالیت کو بغیر کسی تبدیلی کے دوبارہ بنانا ناممکن ہے، اور Chrome کے لیے NoScript پورٹ کی مزید ترقی کو بھی بے معنی بناتا ہے۔
- رازداری کے بارے میں خدشات دور کی بات ہے، کیونکہ ویب ریکوسٹ API کا صرف پڑھنے کے لیے، نان بلاکنگ موڈ کو اپنی جگہ پر چھوڑ دیا گیا ہے اور اب بھی نقصان دہ ایڈ آن کو تمام ٹریفک کو کنٹرول کرنے کی اجازت دیتا ہے، لیکن اس میں مداخلت کرنے کی صلاحیت فراہم نہیں کرتا ہے۔ فلائی (مواد تبدیل کریں، اپنے اشتہارات لگائیں، کان کنوں کو چلائیں اور ان پٹ فارم کے مواد کا تجزیہ کریں صفحہ لوڈنگ ختم ہونے کے بعد استعمال کیا جا سکتا ہے)؛
- براؤزر ڈویلپرز , и , Chromium انجن پر بنایا گیا، اپنی مصنوعات میں webRequest بلاک کرنے کے موڈ کے لیے سپورٹ چھوڑنے کا ارادہ رکھتا ہے۔
ماخذ: opennet.ru