گنجاندن پیش‌فرض Idle Detection API در کروم 94 به موجی از انتقادات منجر شده است که به مخالفت‌های توسعه‌دهندگان Firefox و WebKit/Safari اشاره می‌کنند.
Idle Detection API به سایت‌ها اجازه می‌دهد تا زمانی را که کاربر غیرفعال است، تشخیص دهند. با صفحه‌کلید/موس تعامل نمی‌کند یا روی مانیتور دیگری کار نمی‌کند. API همچنین به شما امکان می دهد بفهمید که آیا محافظ صفحه روی سیستم اجرا می شود یا خیر. اطلاعات مربوط به عدم فعالیت با ارسال یک اعلان پس از رسیدن به آستانه عدم فعالیت مشخص انجام می شود که حداقل مقدار آن 1 دقیقه تنظیم شده است.
توجه به این نکته مهم است که استفاده از Idle Detection API مستلزم اعطای صریح مجوزهای کاربر است. اگر برنامه برای اولین بار سعی کند عدم فعالیت را تشخیص دهد، پنجره ای به کاربر نمایش داده می شود که از شما می پرسد آیا مجوزها را صادر کند یا عملیات را مسدود کند. برای غیرفعال کردن کامل Idle Detection API، یک گزینه ویژه ("chrome://settings/content/idleDetection") در بخش تنظیمات "Privacy and Security" ارائه شده است.
بخش های برنامه شامل برنامه های چت، شبکه های اجتماعی و ارتباطات است که می توانند وضعیت کاربر را بسته به حضور وی در رایانه تغییر دهند یا اطلاع رسانی پیام های جدید را تا رسیدن کاربر به تاخیر بیاندازند. API همچنین می‌تواند در برنامه‌های کیوسک برای بازگشت به صفحه اصلی پس از مدتی عدم فعالیت یا غیرفعال کردن عملیات تعاملی با منابع فشرده، مانند ترسیم مجدد نمودارهای پیچیده، به‌روزرسانی مداوم نمودارها، زمانی که کاربر پشت رایانه نیست، استفاده شود.
موضع مخالفان فعال کردن Idle Detection API این است که اطلاعات مربوط به حضور یا عدم حضور کاربر در رایانه را می توان محرمانه تلقی کرد. علاوه بر برنامه‌های کاربردی مفید، این API می‌تواند برای اهداف بد نیز استفاده شود، به عنوان مثال، برای سوء استفاده از آسیب‌پذیری‌ها در زمانی که کاربر دور است یا برای پنهان کردن فعالیت‌های مخرب آشکار، مانند استخراج. با استفاده از API مورد نظر می توان اطلاعاتی در مورد الگوهای رفتاری کاربر و ریتم روزانه کار او نیز جمع آوری کرد. به عنوان مثال، می توانید متوجه شوید که کاربر معمولاً چه زمانی به ناهار می رود یا محل کار را ترک می کند. در زمینه درخواست اجباری برای اثبات مجوز، این نگرانی‌ها توسط Google ناچیز تلقی می‌شوند.
علاوه بر این، می توانید یادداشت توسعه دهندگان Chrome را در مورد ترویج تکنیک های جدید برای اطمینان از عملکرد ایمن با حافظه یادداشت کنید. به گفته گوگل، 70 درصد از مشکلات امنیتی کروم ناشی از خطاهای حافظه مانند استفاده از بافر پس از آزاد کردن حافظه مرتبط با آن (استفاده پس از آزاد) است. سه استراتژی اصلی برای مقابله با چنین خطاهایی شناسایی شده است: تقویت بررسی ها در مرحله کامپایل، مسدود کردن خطاها در زمان اجرا و استفاده از یک زبان ایمن برای حافظه.
گزارش شده است که آزمایش‌هایی برای افزودن قابلیت توسعه مؤلفه‌ها به زبان Rust به پایگاه کد Chromium آغاز شده است. کد Rust هنوز در بیلدهای ارائه شده به کاربران گنجانده نشده است و عمدتاً با هدف آزمایش امکان توسعه بخش‌های جداگانه مرورگر در Rust و ادغام آنها با سایر بخش‌های نوشته شده در C++ است. به موازات آن، برای کد ++C، پروژه ای به توسعه ادامه می دهد تا از نوع MiraclePtr به جای نشانگرهای خام استفاده کند تا امکان سوء استفاده از آسیب پذیری های ناشی از دسترسی به بلوک های حافظه از قبل آزاد شده را مسدود کند و روش های جدیدی برای تشخیص خطاها در مرحله کامپایل نیز پیشنهاد شده است.
علاوه بر این، گوگل آزمایشی را برای آزمایش اختلال احتمالی سایت ها پس از رسیدن مرورگر به نسخه ای متشکل از سه رقم به جای دو رقم آغاز می کند. به طور خاص، در نسخه‌های آزمایشی Chrome 96، تنظیم «chrome://flags#force-major-version-to-100» زمانی که در سربرگ User-Agent، نسخه 100 (Chrome/100.0.4650.4) مشخص شده بود ظاهر شد. شروع به نمایش می کند. در ماه آگوست آزمایش مشابهی در فایرفاکس انجام شد که مشکلاتی را در پردازش نسخه های سه رقمی در برخی سایت ها آشکار کرد.
منبع: opennet.ru