Web Environment Integrity یا WEI پیشنهادی برای دریافت گواهی دربارهٔ محیط اجرای مرورگر بود. این پیشنهاد به یک استاندارد عمومیِ مستقر برای وب تبدیل نشد و متن رسمی explainer صریحاً می‌گوید که دیگر دنبال نمی‌شود. بنابراین صحبت دربارهٔ آن باید به‌عنوان بررسی یک طرح کنارگذاشته‌شده انجام شود. عنوان قبلی مقاله که از «استاندارد» حرف می‌زد، این تمایز را پنهان می‌کرد و ممکن بود خواننده تصور کند سایت‌ها همین حالا موظف به استفاده از آن هستند.
بحث WEI هنوز برای طراح محصول و توسعه‌دهنده مفید است، چون پرسشی عملی مطرح می‌کند: وقتی یک سرویس می‌خواهد تقلب را کاهش دهد، چه کسی دربارهٔ قابل اعتماد بودن دستگاه کاربر تصمیم می‌گیرد و کاربری که تأیید نمی‌شود چه راهی دارد؟ این سؤال را می‌توان بدون فرض فعال بودن WEI بررسی کرد. هدف این متن، توضیح همان مرز تصمیم است؛ یک راهنمای نصب API یا خبر انتشار قابلیت در مرورگر نیست.
گواهی محیط اجرا چه معنایی دارد؟
در طرح پیشنهادی، یک سایت می‌توانست دربارهٔ محیط اجرای درخواست، token امضاشده دریافت کند. ایده این بود که یک طرف مورد اعتماد، بعضی ویژگی‌های آن محیط را گواهی کند و سایت بر اساس آن تصمیم بگیرد. این گواهی با تشخیص هویت صاحب حساب فرق دارد. ممکن است محیط از نظر سازوکار گواهی پذیرفته شود، اما شخص استفاده‌کننده مجوز انجام یک عملیات را نداشته باشد. برعکس، صاحب واقعی حساب ممکن است با دستگاه یا مرورگری کار کند که قابلیت گواهی مورد انتظار را ندارد.
Token نیز مدرک صحت همهٔ فعالیت‌های کاربر نیست. تصمیمی که دربارهٔ محیط اجرا گرفته می‌شود، دامنهٔ محدودی دارد. تبدیل آن به گزارهٔ «این انسان واقعی و همهٔ درخواست‌هایش سالم است» از معنای سیگنال فراتر می‌رود. طراحی ضدتقلب باید نوع سوءاستفاده را مشخص کند: ثبت سفارش جعلی، تلاش مکرر ورود یا دست‌کاری یک جریان پرداخت، مسئله‌های متفاوتی هستند. یک سیگنال کلی بدون مدل تهدید مشخص ممکن است هزینهٔ تازه‌ای برای کاربران ایجاد کند و مسئلهٔ اصلی را حل نکند.
برای فهم جریان، یک مثال فرضی در نظر بگیرید: سامانهٔ فروش بلیت می‌خواهد درخواست‌های خرید خودکار را محدود کند. دستگاه کاربر درخواست گواهی می‌دهد، صادرکننده نتیجه‌ای امضاشده برمی‌گرداند و سایت آن نتیجه را بررسی می‌کند. سپس خود سایت تصمیم می‌گیرد خرید را بپذیرد یا مرحلهٔ دیگری نشان دهد. در این روایت فرضی، صادرکننده و سایت دو نقش جدا دارند. مشکل یا سیاست محدودکننده در هرکدام می‌تواند به کاربر نهایی برسد.
مسئلهٔ ضدتقلب را دقیق تعریف کنید
پیش از انتخاب هر سازوکار تازه، بنویسید چه عملیاتی در خطر است، مهاجم چه چیزی به دست می‌آورد و چه دسترسی‌ای دارد. برای ورود حساب، ممکن است محدود کردن تعداد تلاش و مراقبت از Session اهمیت بیشتری از دسته‌بندی مرورگر داشته باشد. برای خرید بلیت، ظرفیت، نرخ درخواست و قواعد تخصیص نیز اثر دارند. هیچ‌کدام از این مثال‌ها نسخهٔ یکسانی برای همهٔ سرویس‌ها نیستند. ارزش مدل تهدید در این است که ابزار را به یک مسئلهٔ قابل مشاهده متصل می‌کند.
هزینهٔ خطای تصمیم هم باید روشن باشد. مسدود شدن یک بازدید عمومی با رد شدن پرداخت یا از دست رفتن دسترسی به حساب، پیامد یکسانی ندارد. سیاستی که همهٔ خطاها را با یک صفحهٔ «دسترسی ممنوع» پاسخ می‌دهد، اطلاعات مفید را از کاربر و تیم پشتیبانی می‌گیرد. بهتر است در طراحی جریان معلوم باشد کدام عملیات محدود شده، آیا تصمیم موقتی است و کاربر چه راه جایگزینی دارد. این توضیح باید بدون افشای جزئیات قابل سوءاستفاده نوشته شود.
وابستگی به صادرکنندهٔ گواهی
اگر دسترسی یک سرویس به تأیید چند صادرکننده وابسته شود، تصمیم آن صادرکننده‌ها بخشی از مسیر استفادهٔ مردم خواهد شد. در چنین مدلی، مرورگر تازه یا محیط آزمایشی ممکن است پیش از اینکه امکان اثبات سازگاری پیدا کند، از بعضی خدمات کنار گذاشته شود. این پیامد یک نگرانی معماری است، نه گزارش اثبات‌شده از حذف همهٔ مرورگرهای کوچک توسط WEI. چون طرح عمومی دنبال نشد، نباید نگرانی را به واقعه‌ای که رخ داده تبدیل کرد.
از دید مدیر محصول، مسئلهٔ انتخاب صادرکننده شبیه انتخاب یک dependency مهم است. باید معلوم باشد در صورت اختلال چه اتفاقی می‌افتد، چه اطلاعاتی برای تصمیم دریافت می‌شود و آیا امکان تغییر سیاست وجود دارد. اگر تیم فقط نتیجهٔ سبز یا قرمز را می‌بیند و هیچ راه بازبینی ندارد، توضیح خطا به کاربر سخت می‌شود. طراحی یک قرارداد روشن میان سرویس و صادرکننده، پیش‌نیاز فهم هزینهٔ عملیاتی آن وابستگی است.
سیاست پذیرش نیز می‌تواند از هدف اولیه فاصله بگیرد. یک سیگنال که برای کاهش تقلب پیشنهاد شده، ممکن است در طراحی یک سایت به شرط عمومی مشاهدهٔ محتوا تبدیل شود. همین جابه‌جایی محل استفاده باید در بررسی محصول دیده شود. نیاز به حفاظت از یک عملیات حساس، خودبه‌خود ضرورت محدود کردن همهٔ صفحه‌های عمومی را ثابت نمی‌کند. بهتر است تصمیم به دامنهٔ عملیات متصل بماند و گسترش آن نیاز به دلیل مستقل داشته باشد.
حریم خصوصی و امنیت را با هم بسنجید
کمتر شدن تقلب و کمتر شدن دادهٔ قابل جمع‌آوری دو هدف جدا هستند. یک سیستم ممکن است برای بررسی محیط دادهٔ جدیدی وارد جریان کند. تیم باید مشخص کند آن داده چه معنایی دارد، چه مدت نگه داشته می‌شود و چه کسانی به آن دسترسی دارند. عبارت کلی «سیستم امن است» دربارهٔ این تصمیم‌ها چیزی نمی‌گوید. یک نمودار ساده از فرستنده، گیرنده و محل ذخیره، اغلب به فهم مسئله بیشتر از مجموعه‌ای از صفات امنیتی کمک می‌کند.
تفاوت شناسایی فرد با ارزیابی محیط نیز نباید در متن سیاست حریم خصوصی گم شود. اگر داده‌ای به حساب متصل می‌شود، توضیح دهید اتصال برای چه کاری لازم است. اگر فقط برای تصمیم موقتی استفاده می‌شود، نگهداری دائمی آن نیاز به توجیه جدا دارد. این‌ها اصول طراحی یک جریان داده‌اند و ادعای حقوقی دربارهٔ مجاز بودن استفاده در یک کشور خاص نیستند. برای تصمیم حقوقی باید قوانین و شرایط واقعی همان محصول بررسی شوند.
مسیر جایگزین برای کاربر واقعی
فرض کنید کاربر بلیت‌فروشی با مرورگر سازمانی محدودشده وارد شده و مرحلهٔ تأیید جواب نمی‌دهد. اگر تنها توصیهٔ صفحه «مرورگر دیگری نصب کنید» باشد، امکان انجام آن در محیط کاربر معلوم نیست. مسیر جایگزین باید با ماهیت عملیات سازگار باشد؛ مثلاً پیگیری از کانال پشتیبانی رسمی یا انجام مرحلهٔ تأیید دیگری که محصول واقعاً ارائه می‌کند. پیشنهاد مسیر خیالی در متن خطا فقط یک بن‌بست را به بن‌بست دیگری منتقل می‌کند.
برای تیم پشتیبانی، دسته‌بندی خطا کمک می‌کند مشکل محصول از رفتار مشکوک جدا شود. گزارش نباید token حساس یا دادهٔ خصوصی را بی‌حساب ذخیره کند. کافی است دادهٔ لازم برای فهم مرحلهٔ شکست و پیگیری امن تعریف شود. یک نام روشن برای خطا، زمان رخداد و ارتباط با درخواست پشتیبانی در بسیاری از سناریوها از screenshot نامفهوم سودمندتر است. طراحی همین اطلاعات باید قبل از عمومی شدن محدودیت انجام شود.
چرا برچسب DRM تمام بحث را توضیح نمی‌دهد؟
در نقد WEI از مقایسه با DRM استفاده شده است، چون هر دو بحث با کنترل دسترسی و نقش طرف‌های مورد اعتماد پیوند دارند. اما یک تشبیه، جای توضیح سازوکار را نمی‌گیرد. اگر هدف نقد این است که کاربران بعضی محیط‌ها کنار گذاشته می‌شوند، همان مسیر کنارگذاری را نشان دهید. اگر نگرانی وابستگی به چند شرکت است، نقش صادرکننده را توضیح دهید. این شیوه امکان بررسی و پاسخ دقیق را بیشتر می‌کند و به خواننده کمک می‌کند اختلاف‌های واقعی را ببیند.
برای بررسی خبرهای مشابه، سه چیز را جدا ثبت کنید: پیشنهاد، پیاده‌سازی آزمایشی و قابلیت منتشرشده. وجود مخزن عمومی یا یک explainer به معنی تصویب استاندارد نیست. توضیح مجموعهٔ Explainers by Googlers نیز روشن می‌کند که پیشنهاد یک تیم، پذیرش آن از سوی همهٔ Google یا فرایند انتشار Blink را ثابت نمی‌کند. این تمایز کوچک، مانع نوشتن خبرهایی می‌شود که وضعیت یک طرح آزمایشی را به‌عنوان واقعیت جاری وب معرفی می‌کنند.
در یک محصول تازه، مستند تصمیم ضدتقلب را با تهدید مشخص و مسیر کاربر آغاز کنید. بعد محدودیت‌های سیگنال، خطای تصمیم و شیوهٔ بازبینی را بنویسید. برای ادامهٔ بحث دربارهٔ رفتار صفحهٔ محدودیت، راهنمای طراحی صفحات خطا به نوشتن پیام و مسیر خروج کمک می‌کند. دربارهٔ WEI، وضعیت مستند امروز همان کنارگذاشته شدن پیشنهاد عمومی است؛ هر خبر بعدی باید با نام دقیق محصول و دامنهٔ اجرای خودش بررسی شود.
هنوز دیدگاهی ثبت نشده
اولین نفری باشید که نظر می‌دهد!