Kill switch و تصاحب نهادی

وعده‌ای که بر پایه امکان پس گرفتن آن بنا شده است

در سال ۲۰۱۷، در طول طوفان ایرما، چندین مالک Tesla در فلوریدا متوجه شدند که خودرویشان با دریافت یک به‌روزرسانی از راه دور از سازنده، ناگهان کیلومترهای اضافی به برد خود اضافه کرده است. آن‌ها هزینه‌ای برای آن پرداخت نکرده بودند. باتری همیشه قادر به ارائه آن بود؛ سازنده تصمیم گرفته بود به منظور بخش‌بندی بازار، اجازه دسترسی به آن را به مشتری ندهد. در طول وضعیت اضطراری، Tesla ظرفیت کامل را به طور موقت فعال کرد. پس از پایان وضعیت اضطراری، آن را غیرفعال کرد.

آنچه اخبار به عنوان یک حرکت سخاوتمندانه توصیف می‌کرد، با خواندن دقیق، چیز دیگری بود. مالک هرگز صاحب کل محصولی که هزینه آن را پرداخته بود، نبود. سازنده یک توانایی فنی را حفظ کرده بود — گسترش یا کاهش ویژگی‌ها از راه دور — و انتخاب کرده بود که در آن مورد خاص به نفع مشتری از آن استفاده کند. او می‌توانست برعکس آن را انتخاب کند. این داستان از یک عمل خیرخواهانه حکایت نمی‌کند؛ بلکه از یک معماری قدرت می‌گوید.

این مقاله به این معماری می‌پردازد. ما آن را طبق عرف صنعت، kill switch می‌نامیم: کلید قطع از راه دور که به اپراتور اجازه می‌دهد ویژگی‌های یک محصول، سرویس یا دستگاهی را که کاربر فکر می‌کرد متعلق به اوست، غیرفعال کند، تغییر دهد یا پس بگیرد. سوال این نیست که آیا اپراتور صادق است یا خیر. سوال این است که وقتی او دیگر صادق نباشد، یا وقتی کسی او را مجبور کند از کلید در جهت دیگری استفاده کند، چه اتفاقی می‌افتد.

دقیقاً kill switch چیست

این اصطلاح از انگلیسی آمده و ترجمه آن دشوار است: عبارت interruptor de muerte دراماتیک به نظر می‌رسد؛ interruptor remoto بیش از حد خنثی است. آنچه kill switch را تعریف می‌کند نه درام، بلکه یک ویژگی ساده است: توانایی فنی برای غیرفعال کردن چیزی از راه دور، در دستان کسی که کاربر استفاده‌کننده از آن نیست. این می‌تواند یک توقف کامل باشد —خودرویی که روشن نمی‌شود، فایلی که حذف می‌شود، حسابی که معلق می‌شود— یا یک توقف جزئی —قابلیتی که ناپدید می‌شود، باتری که برد خود را از دست می‌دهد، اشتراکی که قطع می‌شود.

هر کنترل از راه دوری یک kill switch نیست. یک به‌روزرسانی امنیتی روتین که توسط کاربر هنگام نصب محصول مجاز شده است، چنین نیست. سیستم ضد سرقتی که توسط خود مالک هنگام سرقت گوشی فعال می‌شود نیز چنین نیست. kill switch به معنای واقعی کلمه سه ویژگی دارد: استفاده از آن تصمیم اپراتور است نه کاربر؛ برای فعال شدن نیاز به رضایت موردی فرد متاثر ندارد؛ و بر روی محصول یا خدماتی اعمال می‌شود که کاربر از قبل آن را کاملاً متعلق به خود می‌دانست.

گالری اروپایی کلیدهای فعال

Tesla این الگو را به کرات تکرار می‌کند، که در مورد آن به صورت مستند است: کاهش قراردادی برد اعمال شده بر خودروهای دست دوم که صاحب آنها تغییر کرده است، حذف عملکردهای رانندگی کمکی پس از ابطال مجوز، تغییرات یک‌جانبه در رفتار محصول بین نسخه‌های سفت‌افزار. John Deere سال‌هاست که در مرکز بحث‌های اروپایی و آمریکایی درباره حق تعمیر قرار دارد: خرید تراکتور شامل یک لایه نرم‌افزاری است که خدمات آن به شبکه رسمی سازنده بستگی دارد؛ وقتی آن شبکه از ثبت‌نام خودداری می‌کند، تراکتور عملکردهای اساسی را کاهش می‌دهد. BMW در سال ۲۰۲۲ اشتراک ماهانه‌ای را برای فعال کردن گرمکن صندلی در خودروهایی که قبلاً به صورت فیزیکی نصب شده بود پیشنهاد داد؛ فشار عمومی باعث عقب‌نشینی از این مدل شد، اما توانایی فنی همچنان باقی است.

در سطح نرم‌افزار، این الگو ساختاری است. Adobe Creative Cloud زمانی که اشتراک تمدید نمی‌شود، مجوزهای ماهانه را باطل می‌کند و فایل‌هایی را که کاربر با آن ابزارها ایجاد کرده، غیرقابل استفاده می‌کند. Microsoft می‌تواند نسخه‌هایی از Windows را که غیرقانونی می‌داند، بدون راهکار عملی غیرفعال کند. Google در اجرای احکام قضایی یا تصمیمات داخلی، برنامه‌ها را از Play Store حذف می‌کند؛ برنامه لغو نصب شده از گوشی‌هایی که در آنجا بود نیز لغو نصب می‌شود. Apple Pay در مارس ۲۰۲۲ در روسیه با اجرای تحریم‌های بین‌المللی توسط Apple غیرفعال شد: در آن بستر مشروع بود، اما این رویه همیشه در دسترس بود.

استدلال مشروع از جانب سازنده

کسی که یکی از این سیستم‌ها را طراحی می‌کند معمولاً استدلال‌های کاملاً معتبری ارائه می‌دهد:

1. پیشگیری از سرقت. اگر ماشین یا گوشی من دزدیده شود، قدردان این هستم که سازنده می‌تواند آن را از راه دور غیرقابل استفاده کند.
2. پیشگیری از کلاهبرداری. اشتراک‌های پرداخت نشده نیاز به مکانیسم قطع دارند؛ بدون این مکانیسم، مدل کسب و کار فرو می‌پاشد.
3. پیشگیری از سوءاستفاده. یک ابزار خطرناک در دستان ناصحیح می‌تواند از قابلیت ابطال بهره‌مند شود.
4. انطباق با قوانین. برخی دستورات قانونی اپراتور را ملزم به حذف محتوا، غیرفعال کردن قابلیت‌ها یا تعلیق حساب‌ها می‌کنند و سیستمی بدون سوئیچ، سیستمی است که نمی‌تواند از آن‌ها تبعیت کند.

هر چهار استدلال درست هستند. هیچ‌کدام ماهیت موضوع را تغییر نمی‌دهند. درست است که یک kill switch پیشگیری از سرقت را تسهیل می‌کند؛ همچنین درست است که همین قابلیت برای اجبار مشتری زنده، و نه فقط آسیب رساندن به سارق، به کار می‌رود. درست است که مدل اشتراکی نیاز به قطع دارد؛ همچنین درست است که این قطع می‌تواند فردا برای مشتری فعلی به دلیلی غیر از آنچه در قرارداد پیش‌بینی شده، اجرا شود. مسئله این نیست که آیا kill switch کاربردهای قانونی دارد یا خیر. مسئله این است که وقتی وجود داشته باشد، کاربردهای آن محدود به آنچه در مستندات اولیه پیش‌بینی شده، نمی‌ماند.

تسخیر نهادی

در اینجا مفهومی وارد می‌شود که عنوان مقاله را به خود اختصاص داده است. تسخیر نهادی وضعیتی است که در آن یک بازیگر — یک شرکت خصوصی، یک نهاد دولتی، یک سازمان رگولاتوری — در نهایت توانایی‌هایی را که برای اهداف محدود به دست آورده یا به او اعطا شده بود، برای اهدافی گسترده‌تر، متفاوت یا صراحتاً مخالف اهداف اصلی به کار می‌گیرد. اقتصاد سیاسی دهه‌هاست که این پدیده را در مقررات مالی می‌شناسد. صنعت فناوری در حال کشف آن با دست خود است.

مکانیسم به این صورت است. شرکت kill switch را برای اهداف قانونی طراحی می‌کند: ضد سرقت، مدیریت اشتراک، انطباق. شرکت این اهداف را در شرایط استفاده، در سیاست حفظ حریم خصوصی و در پیام‌های عمومی خود مستند می‌کند. سال‌ها می‌گذرد. یک دولت دستوری تحت قانونگذاری جدید صادر می‌کند؛ شرکت مجبور می‌شود از سوئیچ در جهتی استفاده کند که در مستندات اصلی‌اش شرح داده نشده بود. یک سهامدار فعال وارد هیئت مدیره می‌شود و سیاست تجاری را تغییر می‌دهد؛ سوئیچ‌ها وجود دارند و طبق سیاست جدید اعمال می‌شوند. شرکت توسط شرکت بزرگتری خریداری می‌شود؛ شرایط خدمات به طور یک‌جانبه با اطلاع‌رسانی سی‌روزه بازنویسی می‌شود. در هر مورد، مشتری که برای اهداف مستند شده به سوئیچ اعتماد کرده بود، متوجه می‌شود که سوئیچ هنوز آنجاست، اما به منافع دیگری پاسخ می‌دهد.

مورد نمونه برای خواننده اروپایی: پرونده Apple علیه FBI در San Bernardino، در سال ۲۰۱۶. پس از یک حمله در کالیفرنیا، FBI از Apple خواست تا آیفون عامل حمله را باز کند. Apple امتناع کرد و بخشی از استدلال‌های خود را بر پایه اصول و بخشی را بر پایه یک استدلال فنی بنا کرد: سیستم، آن‌طور که طراحی شده بود، به خود شرکت اجازه نمی‌داد بدون بازنویسی نرم‌افزار پایه، دستگاه را باز کند. محکم‌ترین دفاع، اخلاقی نبود؛ معماری بود. Apple بر قول فشار ندادن سوئیچ تکیه نکرد؛ بر نبود سوئیچ تکیه کرد. شرکت‌های دیگر، با سوئیچ‌های موجود در معماری‌شان، نتوانسته‌اند در برابر فشارهای مشابه، همان موضع را حفظ کنند.

مسیر قانونگذاری اروپایی

حقوق اروپا در آخرین دوره قانون‌گذاری، به جای کاهش، به سمت قابلیت‌های کنترل از راه دور بیشتر فشار آورده است. مقررات خدمات دیجیتال (DSA) که از فوریه ۲۰۲۴ کاملاً قابل اجرا است، پلتفرم‌ها را ملزم می‌کند تا مکانیسم‌های سریعی را برای حذف محتوا با دستور مرجع ذی‌صلاح فعال کنند؛ مکانیسم‌هایی که بدون قابلیت فنی زیربنایی وجود نخواهند داشت. مقررات هوش مصنوعی (AI Act) که از اوت ۲۰۲۴ به تدریج اجرایی شده است، ارائه‌دهندگان برخی از سیستم‌های هوش مصنوعی پرخطر را ملزم می‌کند تا اقداماتی را برای غیرفعال‌سازی یا نظارت انسانی معنادار فراهم کنند: شکلی هنجاری از kill switch اجباری. در مقابل، مقررات بازارهای دیجیتال (DMA) تعهدات قابلیت همکاری را معرفی می‌کند: جریانی مخالف که اثرات مسدودسازی را محدود می‌کند.

برای متخصصان اروپایی، خوانش صادقانه چنین است: سوال «آیا اپراتور می‌تواند این سرویس را برای من غیرفعال کند؟» هر سال به دلیل الزامات قانونی پاسخ‌های مثبت بیشتری دارد، نه کمتر. این مشروعیت مقررات را زیر سوال نمی‌برد —DSA به مشکلات واقعی پاسخ می‌دهد—، اما یک چیز را تقویت می‌کند: اعتماد به اینکه اپراتور از کلید استفاده نخواهد کرد، مستلزم اعتماد به این است که هیچ تعهد قانونی در آینده او را مجبور نخواهد کرد که از آن در جهتی که امروز پیش‌بینی نمی‌شود استفاده کند. این اعتمادی است که نه تنها به شرکت، بلکه به کل محیط قانونی بستگی دارد.

سوال طراحی که به ندرت پرسیده می‌شود

اکثر طراحی‌های فنی معاصر فرض می‌کنند که کلید وجود خواهد داشت و سپس وعده می‌دهند که از آن سوءاستفاده نکنند. جایگزینی وجود دارد که سخت‌گیرانه‌تر اما کاملاً امکان‌پذیر است: طراحی با این فرض که کلید نباید وجود داشته باشد. این یک شعار نیست. این مستلزم تصمیمات مشخصی است: معماری توزیع شده در مقابل متمرکز، حقوق در دستگاه کاربر در مقابل حقوق مشتق شده از حساب، محتوای رمزگذاری شده با کلیدهایی که اپراتور ندارد در مقابل محتوای رمزگذاری شده با کلیدهایی که اپراتور نگه می‌دارد، هویت رمزنگاری کاربر در مقابل هویت مدیریت شده توسط اپراتور. هر یک از این تصمیمات هزینه فنی واقعی و پیامدهای تجاری واقعی دارد. اما همه آن‌ها یک ویژگی مشترک دارند: به محض اتخاذ، برخی از دستورات قانونی را به عنوان یک موضوع ممکن حذف می‌کنند. چیزی که قابل اجرا نیست، نمی‌توان دستور اجرایش را صادر کرد.

برای خواننده حرفه‌ای

پنج سوالی که باید قبل از پذیرش هر سرویس حرفه‌ای حیاتی از ارائه‌دهنده آن پرسید، به ترتیبی که یک بازرس تداوم کسب‌وکار آن‌ها را مطرح می‌کند:

1. آیا قابلیت فنی ارائه‌دهنده برای تعلیق، مسدود کردن، حذف یا کاهش کیفیت سرویس، داده‌ها یا محصول من از راه دور وجود دارد؟
2. در چه موارد اعلام شده در قرارداد، ارائه‌دهنده می‌تواند از این قابلیت استفاده کند؟
3. در چه موارد اعلام نشده‌ای —دستور قضایی، تحریم بین‌المللی، تغییر سیاست یک‌جانبه، تصاحب شرکتی— او می‌تواند از آن استفاده کند؟
4. در صورت استفاده، چه مدت زمانی برای تداوم فعالیت حرفه‌ای دارم و چه برنامه خروجی در دسترس است؟
5. آیا جایگزین معماری وجود دارد که در آن پاسخ به سوال اول به دلیل ساختار، و نه به دلیل وعده، «نه» باشد؟

پاسخ به سوال پنجم همیشه در دسترس یا متناسب نیست. یک صفحه گسترده شخصی احتمالاً شایسته چنین الزامی نیست. یک پرونده حقوقی فعال، سابقه پزشکی یک بیمار، حسابداری مالیاتی، یک گفتگوی تحت حمایت اخلاق حرفه‌ای، بله. تناسب یک تصمیم حرفه‌ای است؛ خوانش صادقانه سوال اول اینگونه نیست: یا سوئیچ وجود دارد، یا وجود ندارد.

---

محافظتی که امکان عقب‌نشینی را حفظ می‌کند، محافظت ساختاری نیست؛ بلکه اعتمادی است که تغییر نام داده است. اعتماد، همانطور که در دفترچه دیگری گفتیم، یک راه حل اجتماعی معتبر است وقتی به کسی که شایسته آن است اعطا شود، اما در اولین تغییر دست‌ها شکننده است. پاک‌ترین دفاع ساختاری دفاعی است که نمی‌توان آن را پس گرفت زیرا در وهله اول وجود ندارد. مانند هر چیز دیگری در معماری: یک انتخاب طراحی، نه یک تصمیم بازاریابی.