حریم خصوصی واقعی در برابر ظاهری: پرسش‌هایی که شایسته است بپرسیم

تفاوت میان حریم خصوصی معماری و حریم خصوصی اظهاری

در طول هفت مقالهٔ پیشینِ این دوره از لایه‌های گوناگونِ همان موضوع گذشتیم. حقوق انتقال‌های بین‌المللی با Schrems II. ایدهٔ ریاضیِ درهم‌سازی رمزنگارانه که هر Cuaderno را مُهر می‌کند. انتخاب معماریِ kill switch و تصاحب نهادی‌ای که تقریباً همیشه آن را همراهی می‌کند. سازوکار رمزنگاری سرتاسری و پرسش عملی دربارهٔ محل قرارگیری کلیدها. هم‌راستاسازی انگیزه‌ها بر پایهٔ مدل کسب‌وکار. هویت رمزنگارانهٔ خود-فرمان. میزبانی شخصی به‌منزلهٔ راهبردی متناسب. هر مقاله به زاویه‌ای پرداخت. این یکی، آخرینِ دوره، آنها را در یک پرسش‌نامه گرد می‌آورد.

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

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

لایهٔ ۱: معماری

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

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

تفاوت میان این سه از جنس درجه نیست: از جنس نوع است.

پرسش مکمل —که پیش‌تر در Cuaderno دربارهٔ رمزنگاری مطرح شد— این است: چه کسی کلیدهای رمزنگاری‌ای را که خواندن محتوا را ممکن می‌سازند در اختیار دارد؟ اگر کاربر و تنها کاربر آنها را داشته باشد، رمزنگاری واقعی است. اگر گرداننده نیز به هر شکل آنها را داشته باشد —حتی تحت نام «بازیابی حساب» یا «همگام‌سازی میان دستگاه‌ها»—، رمزنگاری اسمی است. این پرسش پاسخ میانیِ صادقانه نمی‌پذیرد.

لایهٔ ۲: مدل کسب‌وکار

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

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

لایهٔ ۳: صلاحیت قضایی

برای حرفه‌ای اروپایی، پرسش صلاحیت قضایی بلاغی نیست. گرداننده در کدام صلاحیت قضایی ثبت شده است؟ سرورهایی که داده‌ها را پردازش می‌کنند فیزیکی در کدام کشورند؟ آیا پاسخ به دو پرسش پیشین یکسان است یا متفاوت، و اگر متفاوت است، چه قانونی اعمال می‌شود؟ یک منطقهٔ اروپایی که توسط شرکتی آمریکایی گردانده می‌شود، برای مقاصد Schrems II، پاسخی اروپایی نیست: شرکت بدون توجه به محل سرورها تابع FISA 702 است.

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

لایهٔ ۴: گرداننده و kill switch

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

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

لایهٔ ۵: هویت و دسترسی

چه کسی اعتبارنامه‌های دسترسی به سرویس را کنترل می‌کند؟ اگر گرداننده بتواند دسترسی کاربر را بدون مشارکت کاربر بازنشانی کند —رویه‌ای که معمولاً «بازیابی حساب» نامیده می‌شود—، آنگاه گرداننده، از نظر فنی، نگهدارندهٔ حساب است و می‌تواند آن را نیز از طریق رویهٔ مناسب به هر که درخواست کند واگذارد. اگر گرداننده نتواند دسترسی را بازنشانی کند چون هویت به‌صورت رمزنگارانه در دستگاه کاربر قرار دارد، آنگاه گرداننده نمی‌تواند آن را واگذار کند، حتی تحت دستور. هر دو شیوه بنا بر زمینه مشروع‌اند؛ اما، بار دیگر، متفاوت‌اند، و شایسته است بدانیم کدام‌یک پذیرفته می‌شود.

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

لایهٔ ۶: آینده

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

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

تفاوت میان ساختار و وعده

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

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

پرسش‌نامه، مرتب‌شده

دوازده پرسش مشخص که دوره را جمع‌بندی می‌کنند، چنان مرتب‌شده که پاسخ هر یک پرسش بعدی را روشن می‌سازد:

1. آیا محتوا از سروری متعلق به گرداننده عبور می‌کند؟ اگر عبور می‌کند: به‌صورت آشکار، رمزنگاری‌شده با کلیدهای گرداننده، یا رمزنگاری‌شده با کلیدهای انحصاری کاربر؟
2. اگر به رمزنگاری سرتاسری استناد شود، کلیدهای رمزنگاری کجا قرار دارند؟ آیا گرداننده بخشی از آنها را به هر شکل، از جمله «بازیابی»، می‌شناسد یا نگه می‌دارد؟
3. سرویس چه فراداده‌ای تولید و نگهداری می‌کند؟ چه مدت؟ برای چه کسانی قابل مشاهده است؟
4. گرداننده چگونه تأمین مالی می‌شود؟ اگر تأمین مالی شامل تبلیغات یا کسب درآمد از داده‌ها باشد، آیا هدف اعلام‌شده داده‌های اشخاص ثالثی را که حرفه‌ای به او سپرده می‌پوشاند؟
5. وضعیت مالی گرداننده در افق سه تا پنج سال چگونه است؟ آیا عواملی وجود دارند که از تغییر قریب‌الوقوع مدل خبر دهند (عرضهٔ اولیهٔ سهام در پیش، دور تأمین مالی رو به اتمام، تملک محتمل)؟
6. گرداننده در کدام صلاحیت قضایی ثبت شده است؟ سرورها فیزیکی در کدام کشور قرار دارند؟ اگر متفاوت باشند، چه قانون ملی‌ای بر پردازش اعمال می‌شود؟
7. اگر یک دستور اطلاعاتی معتبر در صلاحیت قضایی گرداننده خواستار تحویل داده‌های من شود، چه روی می‌دهد؟ آیا شرکت می‌تواند از نظر فنی آن را اجرا کند؟
8. گرداننده چه توان فنی‌ای را برای تعلیق، مسدودسازی یا حذف سرویس حفظ می‌کند؟ تحت چه فرض‌های قراردادی؟ تحت چه فرض‌های غیرقراردادیِ به‌لحاظ تاریخی مستند؟
9. اگر گرداننده آن توان را علیه من به‌کار گیرد، به‌حق یا ناحق، چه برنامهٔ خروجی وجود دارد؟ آیا رویهٔ مستندی برای صدور داده‌ها به یک ارائه‌دهندهٔ جایگزین هست؟
10. چه کسی اعتبارنامه‌های دسترسی را کنترل می‌کند؟ آیا گرداننده می‌تواند بدون مشارکت من آنها را بازنشانی کند؟ آیا این مرا حفظ می‌کند یا در معرض خطر قرار می‌دهد؟
11. آیا برای این کارکرد مشخص جایگزینی اروپایی، خود-میزبان یا بدون سرور واسط وجود دارد؟ هزینهٔ واقعی آن، در مقایسه با خطرِ ارزیابی‌شده، چقدر است؟
12. اگر تصمیم امروز پنج سال بعد توسط بازرس، حسابرس یا مشتری‌ای که از یک نشت آسیب دیده بررسی شود، آیا انتخاب کنونی با استدلال‌های در دسترسِ امروز قابل دفاع خواهد بود، یا مستلزم عذرخواهی بابت نپرسیدنِ پرسش‌های معقول است؟

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

---

با این مقاله دومین دورهٔ Cuadernos Lacre را به پایان می‌بریم. با بدهی تحریریِ به‌ارث‌رسیده از Schrems II آغاز کردیم و با یک پرسش‌نامهٔ عملی پایان می‌دهیم. در این مسیر از مفاهیمی —درهم‌سازی، رمزنگاری، هویت— و تحلیل‌های کاربردی —kill switch، مدل کسب‌وکار، میزبانی شخصی— عبور کردیم. نیّت تحریریِ اعلام‌شدهٔ این نشریه آن نبود که خواننده را با فهرست جامع مشکلات گرانبار کند، بلکه آن بود که ابزارهایی به او بدهد تا در برابر هر سرویس تازه تشخیص دهد چه نوع پاسخی را می‌پذیرد. همان تمایز —میان معماری و وعده— خودِ ابزار است. باقی را هر حرفه‌ای در خدمت داده‌هایی خواهد گذاشت که در عمل خویش درخورِ پرسش می‌داند.