کروم 94 میں Idle Detection API کی ڈیفالٹ شمولیت نے تنقید کی ایک لہر کو جنم دیا ہے، جس میں فائر فاکس اور ویب کٹ/سفاری ڈویلپرز کے اعتراضات کا حوالہ دیا گیا ہے۔
Idle Detection API سائٹس کو اس وقت کا پتہ لگانے کی اجازت دیتا ہے جب صارف غیر فعال ہوتا ہے، یعنی کی بورڈ/ماؤس کے ساتھ تعامل نہیں کرتا ہے یا کسی دوسرے مانیٹر پر کام نہیں کرتا ہے۔ API آپ کو یہ معلوم کرنے کی بھی اجازت دیتا ہے کہ آیا سسٹم پر اسکرین سیور چل رہا ہے یا نہیں۔ غیر فعالیت کے بارے میں معلومات ایک مخصوص غیر فعالیت کی حد تک پہنچنے کے بعد ایک اطلاع بھیج کر کی جاتی ہے، جس کی کم از کم قیمت 1 منٹ پر سیٹ کی گئی ہے۔
یہ نوٹ کرنا ضروری ہے کہ Idle Detection API کے استعمال کے لیے صارف کی واضح اجازت کی ضرورت ہوتی ہے، یعنی اگر ایپلیکیشن پہلی بار غیرفعالیت کا پتہ لگانے کی کوشش کرتی ہے، تو صارف کو ایک ونڈو پیش کی جائے گی جس میں پوچھا جائے گا کہ آیا اجازت دینا ہے یا آپریشن کو روکنا ہے۔ Idle Detection API کو مکمل طور پر غیر فعال کرنے کے لیے، ایک خاص آپشن ("chrome://settings/content/idleDetection") "پرائیویسی اور سیکیورٹی" سیٹنگز سیکشن میں فراہم کیا جاتا ہے۔
ایپلیکیشن کے شعبوں میں چیٹ، سوشل نیٹ ورکنگ اور کمیونیکیشن ایپلی کیشنز شامل ہیں جو کمپیوٹر پر اس کی موجودگی کے لحاظ سے صارف کی حیثیت کو تبدیل کر سکتی ہیں یا صارف کے آنے تک نئے پیغامات کی اطلاع میں تاخیر کر سکتی ہیں۔ API کا استعمال کیوسک ایپلی کیشنز میں غیرفعالیت کی مدت کے بعد اصل اسکرین پر واپس آنے کے لیے بھی کیا جا سکتا ہے، یا جب صارف کمپیوٹر پر نہ ہو تو وسائل سے متعلق انٹرایکٹو آپریشنز، جیسے کہ کمپلیکس کو دوبارہ ڈرائنگ کرنا، چارٹس کو مسلسل اپ ڈیٹ کرنا غیر فعال کرنا۔
Idle Detection API کو فعال کرنے کے مخالفین کا موقف یہ ہے کہ آیا صارف کمپیوٹر پر ہے یا نہیں اس بارے میں معلومات کو خفیہ تصور کیا جا سکتا ہے۔ مفید ایپلیکیشنز کے علاوہ، اس API کو برے مقاصد کے لیے بھی استعمال کیا جا سکتا ہے، مثال کے طور پر، صارف کے دور ہونے کے دوران کمزوریوں سے فائدہ اٹھانے کی کوشش کرنے یا کان کنی جیسی نمایاں بدنیتی پر مبنی سرگرمی کو چھپانے کے لیے۔ زیر بحث API کا استعمال کرتے ہوئے، صارف کے رویے کے پیٹرن اور اس کے کام کی روزانہ کی تال کے بارے میں معلومات بھی جمع کی جا سکتی ہیں۔ مثال کے طور پر، آپ یہ معلوم کر سکتے ہیں کہ صارف عام طور پر کب دوپہر کے کھانے پر جاتا ہے یا کام کی جگہ سے نکلتا ہے۔ اجازت کے ثبوت کے لیے ایک لازمی درخواست کے تناظر میں، گوگل ان خدشات کو غیر معمولی سمجھتا ہے۔
مزید برآں، آپ میموری کے ساتھ محفوظ آپریشن کو یقینی بنانے کے لیے نئی تکنیکوں کے فروغ کے بارے میں کروم ڈویلپرز کے نوٹ کو نوٹ کر سکتے ہیں۔ گوگل کے مطابق، کروم میں سیکیورٹی کے 70 فیصد مسائل میموری کی خرابیوں کی وجہ سے ہوتے ہیں، جیسے کہ اس سے منسلک میموری کو آزاد کرنے کے بعد بفر کا استعمال (استعمال کے بعد مفت)۔ اس طرح کی غلطیوں سے نمٹنے کے لیے تین اہم حکمت عملیوں کی نشاندہی کی گئی ہے: تالیف کے مرحلے پر چیک کو مضبوط بنانا، رن ٹائم پر غلطیوں کو روکنا، اور میموری سے محفوظ زبان کا استعمال۔
بتایا جاتا ہے کہ کرومیم کوڈبیس میں زنگ زبان میں اجزاء تیار کرنے کی صلاحیت کو شامل کرنے کے لیے تجربات شروع ہو گئے ہیں۔ زنگ کوڈ ابھی تک صارفین کو فراہم کردہ تعمیرات میں شامل نہیں کیا گیا ہے اور بنیادی طور پر اس کا مقصد براؤزر کے انفرادی حصوں کو زنگ میں تیار کرنے اور C++ میں لکھے گئے دیگر حصوں کے ساتھ ان کے انضمام کے امکان کو جانچنا ہے۔ متوازی طور پر، C++ کوڈ کے لیے، پہلے سے آزاد میموری بلاکس تک رسائی کی وجہ سے پیدا ہونے والی کمزوریوں سے فائدہ اٹھانے کے امکان کو روکنے کے لیے خام پوائنٹرز کے بجائے MiraclePtr قسم کا استعمال کرنے کے لیے ایک پروجیکٹ تیار ہوتا رہتا ہے، اور تالیف کے مرحلے پر غلطیوں کا پتہ لگانے کے لیے نئے طریقے بھی تجویز کیے جاتے ہیں۔
اس کے علاوہ، گوگل براؤزر کے دو کے بجائے تین ہندسوں پر مشتمل ورژن تک پہنچنے کے بعد سائٹس کے ممکنہ خلل کو جانچنے کے لیے ایک تجربہ شروع کر رہا ہے۔ خاص طور پر، کروم 96 کے ٹیسٹ ریلیز میں، "chrome://flags#force-major-version-to-100" ترتیب ظاہر ہوئی، جب User-Agent ہیڈر، ورژن 100 (Chrome/100.0.4650.4) میں بیان کیا گیا ہو۔ ظاہر ہونا شروع ہوتا ہے۔ اگست میں، فائر فاکس میں اسی طرح کا ایک تجربہ کیا گیا، جس میں کچھ سائٹس پر تین ہندسوں کے ورژن پر کارروائی کرنے میں دشواریوں کا انکشاف ہوا۔
ماخذ: opennet.ru