← Cuadernos Lacre

تحلیل · ۱۶ مهٔ ۲۰۲۶

وقتی هیچ‌کس در میان نیست

رمزگذاری آنچه از یک سرور عبور می‌کند از محتوا محافظت می‌کند. نداشتن سرور در میان، صورت مسئله را پاک می‌کند. این دو یکی نیستند.

دو نفر، یک گفتگو

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

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

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

تفاوت بین رمزگذاری و عدم جمع‌آوری (قسمت دوم)

در مقاله قبلی از همین مجموعه استدلال کردیم که رمزگذاری محتوا و عدم جمع‌آوری متاداده یکی نیستند. گام دیگری وجود دارد که شایسته است با وضوح بیان شود: رمزگذاری آنچه از یک سرور عبور می‌کند و نداشتن سرور نیز یکی نیستند.

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

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

اعتماد، فقدان، و تفاوت بین این دو

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

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

فقدان یک اپراتور در معرض آن اتفاقات نیست. یک حکم قضایی نمی‌تواند از سروری که وجود ندارد داده‌ای بخواهد. یک مهاجم نمی‌تواند سروری را که وجود ندارد به خطر بیندازد. تغییری در سیاست یک شرکت نمی‌تواند بر داده‌هایی که آن شرکت هرگز نداشته است تأثیر بگذارد. جمله کلیدی ساده است: داده‌هایی که وجود ندارند نمی‌توانند گم شوند.

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

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

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

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

آنچه قانون می‌گوید و آنچه معماری انجام می‌دهد

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

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

شاهد غیرضروری

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

پاسخ در اکثر سرویس‌های پیام‌رسان حرفه‌ای که امروزه وجود دارند این است که نیازی نبود — و با این حال حضور داشت.


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

منابع و مطالعه بیشتر

  • سالتزر، جی. اچ.؛ رید، دی. پی.؛ کلارک، دی. دی. — End-to-end arguments in system design، ACM TOCS، ۱۹۸۴. متن بنیادی اصلی که طبق آن تضمین‌های یک سیستم باید در دو انتها اجرا شوند، نه در کانال واسطه.
  • مقررات (اتحادیه اروپا) ۲۰۱۶/۶۷۹، ماده ۲۵ — حفاظت از داده‌ها از طریق طراحی و به طور پیش‌فرض.
  • مقررات (اتحادیه اروپا) ۲۰۱۶/۶۷۹، ماده ۵.۱.ج — اصل به حداقل رساندن داده‌ها.
  • اشنایر، بی. — Data and Goliath: the hidden battles to collect your data and control your world (۲۰۱۵)، دبلیو. دبلیو. نورتون. فصل‌های مربوط به معماری‌هایی که جمع‌آوری را از طریق ساخت به حداقل می‌رسانند.

قراءات حديثة