‏TDDDG § 25 در آلمان: محدودیت «فقط سمت سرور»

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

خلاصه

• ‏§ 25 از TDDDG محدودیت الزام‌آور هر استقرار سراسری در اروپاست. برای آلمان پیکربندی کنید؛ بقیه اتحادیه اروپا روی همین بنا، رو به بالا ساخته می‌شوند.
• ‏منافع مشروع جایگزین رضایت § 25 نمی‌شود. سند DSK با عنوان Orientierungshilfe (راهنمای جهت‌دهی) نسخه 1.2 مورخ 20 نوامبر 2024 در این مورد کاملاً صریح است و تا ماه می 2026 همچنان راهنمای معتبر و عملیاتی باقی مانده است.
• ‏تنها معماری بدون‌رضایت، پردازش کاملاً سمت سرور است؛ بدون کوکی، بدون localStorage، بدون پویش‌های اثرانگشت مرورگر و بدون هیچ خواندنِ شناسه سمت کلاینت. عبارت «Zugriff auf Informationen» (دسترسی به اطلاعات) در § 25 فراتر از کوکی‌ها می‌رود و هر خواندنِ داده سمت کلاینت را در بر می‌گیرد.
• ‏یک ارزیابی مستندِ منافع مشروع طبق Article 6(1)(f) همچنان باید وجود داشته باشد؛ این ارزیابی برای لایه پردازشِ GDPR است که پس از دریافتِ سمت سرور انجام می‌شود. این ارزیابی (LIA) قفلِ معافیتِ § 25 را باز نمی‌کند، اما پایه‌ای برای پردازش داده‌های شخصی فراهم می‌آورد.
• ‏اجرای قانون در BayLDA، NRW LDI، BlnBDI و HmbBfDI در سال‌های 2024 تا 2026 فعال است و استقرارهای GA4 / Meta Pixel / Hotjar را که رضایت منطبق با TDDDG ندارند، هدف می‌گیرد. حداکثر جریمه: 300,000 یورو طبق § 28(1) No. 13 به‌علاوه جریمه‌های GDPR طبق Article 83 به‌صورت موازی.

چرا آلمان فرق دارد

نقشه اروپایی آنالیتیکس بدون‌رضایت در سال 2026 یکدست نیست. CNIL فرانسه یک معافیتِ سنجش مخاطب با جزئیات کامل ساخته است؛ Garante ایتالیا، AEPD اسپانیا و AP هلند هم نسخه خود را ساخته‌اند. اما آلمان چنین کاری نکرده است. کنفرانس حفاظت از داده‌ها (Datenschutzkonferenz) — یعنی نهاد هماهنگ‌کننده هر 17 رگولاتورِ حفاظت از داده آلمان — در سندِ Orientierungshilfe für Anbieter:innen von digitalen Diensten (نسخه 1.2 مورخ 20 نوامبر 2024) تأیید کرد که § 25 از TDDDG قانونِ خاص (lex specialis) است و تنها رضایت یا ضرورتِ سخت‌گیرانه، اجازه ذخیره‌سازی یا دسترسی روی دستگاهِ کاربر را می‌دهد. منافع مشروع طبق Article 6(1)(f) از GDPR، پایه جایگزین معتبری برای خودِ عملیات ذخیره‌سازی یا دسترسی نیست.

به همین دلیل، آلمان محدودیت الزام‌آورِ هر استقرارِ آنالیتیکسِ سراسری در اروپا می‌شود. کسی که برای آلمان پیکربندی کند، برای همه‌جای دیگرِ اتحادیه اروپا هم پیکربندی شده است. اما کسی که فقط برای Sheet 16 فرانسه پیکربندی کند، هنوز باید پاسخی جداگانه و سخت‌گیرانه‌تر به اپراتور آلمانی بدهد.

نوشته‌ای که در ادامه می‌آید، همان پاسخ آلمانی است. خودِ قاعده، تغییرِ نام در ماه می 2024، معافیتِ محدود، اینکه چرا «فقط سمت سرور» وضعیتِ عملیاتیِ کار است، ارزیابیِ منافع مشروعِ Article 6(1)(f) از GDPR که با این‌حال باز هم باید وجود داشته باشد، اینکه Statnive Live کجا قرار می‌گیرد، بلوک سیاست حریم خصوصی به زبان آلمانی که اپراتور می‌تواند مستقیم بچسباند، و 8 رویداد ممیزیِ حریم خصوصی که ردِ پاسخ‌گویی را تولید می‌کنند.

‏TDDDG، به‌اختصار

قانونِ Telekommunikation-Telemedien-Datenschutz-Gesetz آلمان در 1 دسامبر 2021 با نام TTDSG اجرایی شد (انتقالِ Article 5(3) از دستورالعمل ePrivacy به قانون ملی، به دست دولت فدرال). در ماه می 2024، وقتی آلمان قانون خدمات دیجیتال اتحادیه اروپا (DSA) را به قانون ملی منتقل کرد، نامِ این قانون به TDDDG تغییر یافت — Telekommunikation-Digitale-Dienste-Datenschutz-Gesetz. محتوا تغییری نکرد؛ تنها نام، دامنه گسترده‌ترِ DSA را بازتاب داد.

ماده § 25 همان ماده عملیاتیِ مربوط به کوکی و ذخیره‌سازی است و انتقالِ مستقیمِ Article 5(3) از دستورالعمل ePrivacy یعنی Directive 2002/58/EC (با اصلاحاتِ 2009/136/EC) به شمار می‌رود.

‏§ 25(1) TDDDG (ترجمه انگلیسی): “Storing information in the end user’s terminal equipment or accessing information already stored in the terminal equipment is only permitted if the end user has consented on the basis of clear and comprehensive information. The information to the end user and the consent shall be provided in accordance with Regulation (EU) 2016/679 [GDPR].”

‏§ 25(2) تنها دو حالت را استثنا می‌کند:

• (i) هدفِ یگانه، انتقالِ یک پیام از طریق یک شبکه مخابراتیِ عمومی باشد، و
• (ii) ذخیره‌سازی یا دسترسی برای ارائه یک خدمت دیجیتالی که کاربر صراحتاً درخواست کرده، کاملاً ضروری باشد.

این کلِ معافیت است. در متنِ آلمانی هیچ معافیتی برای سنجش مخاطب وجود ندارد. هیچ معادلی برای Sheet 16 فرانسه، راهنمای کوکیِ 2021 ایتالیا یا راهنمای سنجش مخاطبِ اسپانیا در کار نیست. ماده § 25(2) موارد کاملاً ضروری را پوشش می‌دهد — یک کوکیِ سبد خرید، یک نشستِ احراز هویت، یک توکنِ CSRF — و همین فهرست، تمامِ ماجراست.

‏جریمه‌ها طبق § 28(1) No. 13 و § 28(2) از TDDDG تا 300,000 یورو برای هر تخلف می‌رسد. جریمه‌های GDPR طبق Article 83 (تا 20 میلیون یورو یا 4% گردش مالی جهانی) به‌صورت موازی برای لایه پردازش داده‌های شخصی اعمال می‌شود.

موضع DSK و اینکه چرا منافع مشروع نجات‌تان نمی‌دهد

کنفرانس حفاظت از داده‌ها (DSK) — نهاد هماهنگ‌کننده DPAهای فدرال و ایالتیِ آلمان — سندِ Orientierungshilfe für Anbieter:innen von digitalen Diensten نسخه 1.2 را در 20 نوامبر 2024 منتشر کرد. این راهنما در دو نکته کاملاً صریح است.

‏نکته اول: § 25 از TDDDG قانونِ خاص (lex specialis) است. برای هر ذخیره‌سازی یا دسترسی روی دستگاهِ کاربر، شرطِ رضایتِ § 25 (یا ضرورتِ سخت‌گیرانه) حاکم است. مفاد پایه قانونیِ GDPR در Article 6 پایه جایگزینی برای خودِ عملیاتِ ذخیره‌سازی یا دسترسی فراهم نمی‌کند.

‏نکته دوم: منافع مشروع نمی‌تواند جایگزین رضایت § 25 شود. حتی اگر اپراتور یک ارزیابیِ منافع مشروعِ کاملاً مستندِ Article 6(1)(f) داشته باشد، آن LIA فقط پردازشِ داده‌های شخصی پس از جمع‌آوری را پوشش می‌دهد، نه خودِ عملِ جمع‌آوری از طریق دسترسی به دستگاه کاربر را. این دو، تابع لایه‌های متفاوتی هستند و پایه‌های متفاوتی می‌خواهند.

اثرِ عملی این است: استقرارِ آنالیتیکسی که یک کوکی می‌گذارد، روی localStorage می‌نویسد یا یک شناسه سمت کلاینت را می‌خواند، § 25 از TDDDG را فعال می‌کند. آن استقرار به رضایت نیاز دارد. همین و بس. هیچ مقدار استدلالِ «منافع مشروع» نمی‌تواند شرطِ رضایت را در لایه § 25 پس بگیرد.

به همین دلیل است که موضع آلمان تا این اندازه از فرانسه سخت‌گیرانه‌تر است. معافیتِ Sheet 16 از CNIL، ماده Article 5(3) از ePrivacy را با یک استثنای تعریف‌شده برای سنجش مخاطب — که در خودِ انتقالِ ملی تعبیه شده — تفسیر می‌کند. ماده § 25(2) آلمان همان Article 5(3) از ePrivacy را بدون آن استثنای سنجش مخاطب تفسیر می‌کند. هر دو تفسیر با دستورالعمل پایه‌ای سازگارند؛ صرفاً در نقاط متفاوتی از اختیارِ کشورهای عضو که دستورالعمل اجازه می‌دهد، می‌نشینند.

تنها معماری بدون‌رضایت: فقط سمت سرور

تنها معماری‌ای که بدون رضایت از § 25 از TDDDG جان سالم به در می‌برد، معماری‌ای است که در آن سرورِ اپراتور هیچ اطلاعاتی را روی دستگاهِ بازدیدکننده ذخیره نمی‌کند و از آن نمی‌خواند. مرورگر فقط همان چیزی را می‌فرستد که به‌صورت پیش‌فرض و به‌عنوان بخشی از یک درخواست HTTP اجتناب‌ناپذیر می‌فرستد — هدرهای IP، User-Agent و Referer. سرور آن هدرها را می‌خواند، آنالیتیکس خود را استخراج می‌کند و هیچ چیزی پس نمی‌نویسد. نه کوکی. نه localStorage. نه پویشِ اثرانگشت مرورگر. نه ساختِ شناسه سمت کلاینت. نه هیچ دستوری به دستگاه برای فرستادنِ اطلاعات بیشتر.

این کار به‌کلی بیرون از § 25 از TDDDG می‌افتد. محرکِ «ذخیره‌سازی یا دسترسی روی دستگاهِ کاربر» در Article 5(3) از ePrivacy فعال نمی‌شود، چون هیچ تعاملِ دستگاهی فراتر از رفتارِ پیش‌فرضِ درخواستِ مرورگر رخ نمی‌دهد. سندِ EDPB Guidelines 2/2023 v2.0 صراحتاً همین معافیت را پوشش می‌دهد: جایی که اپراتور به دستگاه دستور نمی‌دهد اطلاعاتی بفرستد و چیزی روی حافظه دستگاه نمی‌نویسد یا از آن نمی‌خواند، ماده Article 5(3) اعمال نمی‌شود.

این همچنین تنها معماری بدون‌رضایتی است که هر 27 کشور عضو از جمله سخت‌گیرترین‌ها را راضی می‌کند. برای فرانسه بیش از حد لازم است؛ برای آلمان ضروری است. اپراتورهایی که ترافیک آلمانی دارند — حتی سهم کوچکی — باید بر اساس همان مبنای «فقط سمت سرور» طراحی کنند، چون هزینه ساختِ دو پشته (یکی برای آلمان، یکی برای همه‌جای دیگر) تقریباً همیشه از هزینه یک مبنای واحدِ سخت‌گیرانه بیشتر می‌شود.

ارزیابیِ منافع مشروعِ Article 6(1)(f) از GDPR — همچنان لازم است

دور زدنِ § 25 از TDDDG در لایه دستگاهِ کاربر، پرسشِ GDPR را از میان نمی‌برد. به‌محض اینکه سرور، IP و User-Agent و Referer را از درخواست بخواند، در حال پردازش داده‌های شخصی است. رأیِ Breyer از دیوان دادگستری اتحادیه اروپا (CJEU) (C-582/14، مورخ 19 اکتبر 2016) قطعی کرد که یک IP پویا در دستِ اپراتورِ یک وب‌سایت، داده شخصی است. User-Agent به‌تنهایی یک شناسه قابل‌اثرگیری است.

پایه قانونیِ این پردازش طبق Article 6 از GDPR به‌طور واقع‌بینانه Article 6(1)(f) است — منافع مشروع — برای سنجش مخاطبِ دستِ‌اول. DSK این موضع را در راهنمای 2024 خود پذیرفته است، اما تنها به این شرطِ صریح که شرطِ دسترسی به دستگاهِ کاربر در § 25 از TDDDG به‌طور مستقل برآورده شود (یعنی استثنای کاملاً ضروری اعمال شود، یا اصلاً هیچ دسترسی به دستگاه کاربر رخ ندهد). معماریِ «فقط سمت سرور» این شرط را به‌حکم ساختار خود برآورده می‌کند.

خودِ ارزیابیِ منافع مشروع باید طبق EDPB Guidelines 1/2024 مستند شود:

• ‏شناساییِ منفعت. بهره‌برداری، بهبود و ایمن‌سازیِ وب‌سایتِ متولّی (همان مؤلفه کارکردی که در بندهای 60 تا 64 رأیِ Breyer شناخته شده)؛ سنجش مخاطب و تعاملِ محتوا (همان مؤلفه تجاری که در بندهای 47 تا 49 رأیِ CJEU C-621/22 KNLTB مورخ 4 اکتبر 2024 شناخته شده).
• ‏ضرورت. سنجش مخاطب را نمی‌توان به‌طور معقول با ابزارهای کم‌تهاجمی‌تر و در عینِ تولیدِ متریک‌های موردنیاز به دست آورد. کمینه‌سازی: بدون شناسه پایدار؛ دور انداختنِ IP خام پیش از ذخیره‌سازی؛ نمکِ روزانه‌چرخان و محدود به دامنه سایت؛ کوتاه‌سازیِ /24 برای IPv4؛ کاهشِ User-Agent به نسخه‌های اصلی؛ کاهشِ منبع ورودی فقط به دامنه میزبان؛ تجمیع تا نزدیک‌ترین مضربِ 10.
• ‏موازنه. منافع فردِ موضوعِ داده: ماده Article 7 منشور (زندگی خصوصی) و Article 8 (حفاظت از داده). انتظاراتِ معقول: بازدیدکننده انتظار دارد اپراتور تعداد کلِ بازدیدها و محبوبیتِ صفحه‌ها را بداند، نه اینکه فرد را به‌صورت میان‌روزه یا میان‌سایتی زیر نظر بگیرد — معماری دقیقاً با همین انتظار می‌خواند. اثر: کمینه — بدون تبلیغاتِ رفتاری، بدون پروفایل‌سازی، بدون اشتراک‌گذاری با شخص ثالث، بدون تصمیم‌هایی که فردِ موضوعِ داده را تحت تأثیر بگذارد. تدابیر کاهنده: نابودیِ نمک در پایان روز، کوتاه‌سازیِ IP، سقفِ نگه‌داری، حقِ مخالفتِ Article 21، وجودِ DPA در جایی که اعمال‌پذیر است، میزبانی فقط در اتحادیه اروپا، و مسیرهای کدِ متن‌باز برای استقرارهای خودمیزبان.

‏ارزیابیِ منافع مشروع یک تمرینِ یک‌باره نیست. EDPB توصیه می‌کند که سالانه و در هر تغییر اساسی نوسازی شود — برای نمونه، با ارجاعی به CJEU که تحلیلِ Breyer را تحت تأثیر بگذارد، با تصویبِ Digital Omnibus، یا با به‌روزرسانیِ راهنماهای ملیِ آلمان.

جای Statnive Live کجاست

‏Statnive Live به‌حکم ساختار خود برای برآورده‌کردنِ § 25 از TDDDG ساخته شده است. گام‌های پیکربندیِ اپراتور برای یک سایت آلمانی چنین است:

1. ‏حوزه قضایی DE را انتخاب کنید. پنل سیاستِ سایت در Statnive Live یک فهرستِ enum با 11 حوزه قضایی نمایش می‌دهد. انتخابِ DE اعتبارسنجِ قاعده‌سخت را فعال می‌کند.
2. ‏اعتبارسنجِ قاعده‌سخت، حالتِ permissive را ممنوع می‌کند. یک اپراتور آلمانی نمی‌تواند حالتِ permissive را انتخاب کند — اعتبارسنج، ذخیره را با این خطا رد می‌کند: «Permissive consent mode is incompatible with § 25 TDDDG (Germany). Select consent-free or consent-required.» این کار هنگام ذخیره سیاست و دوباره هنگام بارگذاری سیاست در هر درخواست دریافت اعمال می‌شود؛ بنابراین پیکربندی را نمی‌توان از مسیرهای جانبی تغییر داد.
3. ‏پیش‌فرض روی consent-free. این کار کوکی‌ها، localStorage و اثرانگشت مرورگر را در ردیاب خاموش می‌کند؛ امضای بازدیدکننده با BLAKE3-HMAC و چرخشِ روزانه در سمت سرور را فعال می‌کند؛ تبدیلِ منبع ورودی به فقط‌میزبان را فعال می‌کند؛ کوتاه‌سازیِ IP را فعال می‌کند؛ و کمینه‌سازیِ User-Agent را فعال می‌کند. این معماری با مبنای «بدون ذخیره‌سازی یا دسترسی روی دستگاهِ کاربر» در § 25 از TDDDG می‌خواند.
4. ‏شناسه کوکیِ درهم‌سازی‌شده در حالت سکون، اما بدون تنظیمِ هیچ کوکی. وقتی consent-free فعال است، هیچ کوکیِ _statnive روی مرورگر تنظیم نمی‌شود. در آن حالت، هیچ کوکی‌ای برای درهم‌سازی در حالت سکون وجود ندارد. (در حالتِ consent-required یا hybrid با رضایتِ داده‌شده، یک UUID به مرورگر فرستاده می‌شود؛ ذخیره‌سازیِ سمت سرور به‌صورت SHA-256(master_secret || site_id || cookieID) با پیشوندِ h: است. مرورگر، UUID خام را می‌بیند؛ اما دیتابیس هرگز نمی‌بیند.)
5. ‏احترام به GPC و DNT. در حوزه قضایی DE، مقدار پیش‌فرضِ consent.respect_gpc = true است. بازدیدکنندگانی که Sec-GPC: 1 می‌فرستند، پیش از محاسبه شناسه بازدیدکننده متوقف می‌شوند — برای یک بازدیدکننده مخالف هیچ رکورد مستعارنامی ساخته نمی‌شود؛ پس چیزی برای حذف نیست، چون چیزی نوشته نشده بود. نوشته مربوط به GPC و حالتِ hybrid، طرح آزمونِ سرتاسری را پوشش می‌دهد.
6. ‏احترام به نقاط پایانیِ DSAR. نقاط پایانیِ POST /api/privacy/opt-out، GET /api/privacy/access و POST /api/privacy/erase روی هر استقرارِ Statnive Live و فارغ از حوزه قضایی در دسترس‌اند. اپراتور آلمانی این زیرساخت را دارد، هرچند در حالتِ consent-free، حجمِ درخواست‌های دسترسی و حذف روی یک استقرارِ بدون‌کوکی ذاتاً کم است — بیشتر بازدیدکنندگان به‌محض چرخشِ نمک، اصلاً هیچ رکوردِ فردی‌ای بر جای نمی‌گذارند.
7. ‏مسیرهای افشای عمومیِ حقوقی، در خودِ باینری تعبیه‌شده‌اند. مسیرهای /privacy، /legal/privacy-policy/en، /legal/privacy-policy/de، /legal/lia و /legal/dpa همگی به دست همان باینریِ Go سرو می‌شوند. مسیرِ /legal/privacy-policy/de همان بندِ آلمانیِ واژه‌به‌واژه‌ای را سرو می‌کند که در بخش بعد توضیح داده می‌شود.

فهرستِ enum با یازده حوزه قضایی (DE / FR / IT / ES / NL / BE / IE / UK / OTHER-EU / IR / OTHER-NON-EU) و چهار حالتِ رضایت (permissive / consent-free / consent-required / hybrid) با هم 44 خانه می‌سازند. ردیفِ DE فقط دو خانه معتبر دارد — consent-free و consent-required. کارِ اعتبارسنج این است که مانع از وجودِ آن 22 خانه دیگر شود.

بلوک سیاست حریم خصوصی به زبان آلمانی

اپراتوری که Statnive Live را در حالتِ consent-free برای یک سایت آلمانی اجرا می‌کند، می‌تواند بندِ زیر را در /datenschutz (یا صفحه حقوقیِ معادل) سرو کند. این متن، واژه‌به‌واژه از پژوهشِ research-53 §08 است و تحلیلِ § 25 از TDDDG بالا را بازتاب می‌دهد.

Reichweitenmessung. Diese Website verwendet [Statnive Live] zur rein server-seitigen Reichweitenmessung. Es werden keine Cookies, kein Local Storage und keine vergleichbaren Technologien auf Ihrem Endgerät gespeichert oder ausgelesen. Insbesondere findet kein Zugriff im Sinne des § 25 Abs. 1 TDDDG statt. Verarbeitet werden ausschließlich Daten, die Ihr Browser für die Auslieferung der Seite ohnehin überträgt (IP-Adresse, Browser-Kennung in stark reduzierter Form, aufgerufene URL, Referrer-Domain). Wir kürzen Ihre IP-Adresse vor jeder weiteren Verarbeitung um das letzte Oktett und ersetzen sie durch eine pseudonymisierte Signatur, deren Salt nach 24 Stunden vernichtet wird.

Rechtsgrundlage. Soweit personenbezogene Daten im Sinne der DSGVO verarbeitet werden, stützt sich die Verarbeitung auf Art. 6 Abs. 1 lit. f DSGVO (berechtigtes Interesse). Eine Interessenabwägung gemäß EDSA-Leitlinien 1/2024 wurde dokumentiert.

Widerspruchsrecht gemäß Art. 21 DSGVO: [OPT-OUT-BUTTON].

این بند هم‌زمان سه کار می‌کند. به بازدیدکننده می‌گوید چه اتفاقی می‌افتد (reine server-seitige Reichweitenmessung)؛ به رگولاتور می‌گوید چرا § 25 از TDDDG اعمال نمی‌شود (بدون هیچ ذخیره‌سازی یا دسترسی روی دستگاهِ کاربر)؛ و به فردِ موضوعِ داده می‌گوید پایه قانونیِ GDPR چیست (یعنی Article 6(1)(f) به‌علاوه یک LIA مستند) و چطور می‌تواند مخالفت کند (لینکِ مخالفتِ Article 21).

این بند جایگزینِ سیاست حریم خصوصیِ خودِ اپراتور نیست. اپراتور همچنان باید یک اطلاعیه کامل بدهد که هویتِ متولّی، اهداف، دسته‌های داده، مدتِ نگه‌داری، گیرندگان و حقوقِ برشمرده در ماده‌های Articles 13–22 از GDPR را پوشش دهد. بندِ بالا در بخشِ Reichweitenmessung از همان اطلاعیه گسترده‌تر جا می‌گیرد.

‏حقِ مخالفتِ Article 21 در Statnive Live به‌صورت یک کوکیِ کاملاً ضروری پیاده‌سازی می‌شود که انتخابِ کاربر را بیان می‌کند — و این کار طبق § 25(2)(ii) از TDDDG مجاز است، چون ترجیحِ خدمتی را که کاربر صراحتاً درخواست کرده (یعنی حقِ مخالفت) پیاده می‌کند. به‌جای آن، انصراف را می‌توان در سمت سرور و از طریق یک فهرستِ مهارسازی که بر امضای h: بازدیدکننده کلید خورده و TTL کافی دارد، پایدار کرد.

ردِ ممیزی — 8 رویداد حریم خصوصی

‏Statnive Live هشت رویداد ممیزیِ ساختاریافته منتشر می‌کند که سطحِ حریم خصوصی و حقوقی را پوشش می‌دهند. این‌ها همان شواهدِ پاسخ‌گوییِ Article 28(3)(h) هستند که برای یک DPO یا یک ممیز آماده‌اند:

• privacy.opt_out_received — یک مخالفتِ Article 21 ثبت شده است.
• privacy.dsar_access_requested — یک درخواستِ حقِ دسترسیِ Article 15 آغاز شده است.
• privacy.dsar_erase_requested — یک درخواستِ حقِ حذفِ Article 17 آغاز شده است.
• privacy.consent_given — تابعِ statnive.acceptConsent() فراخوانی شده است (مرتبط در حالت‌های consent-required و hybrid، نه consent-free).
• privacy.consent_withdrawn — تابعِ statnive.withdrawConsent() فراخوانی شده است.
• legal.lia_viewed — صفحه /legal/lia سرو شده است.
• legal.dpa_viewed — صفحه /legal/dpa سرو شده است.
• legal.privacy_policy_viewed — صفحه /legal/privacy-policy/{lang} سرو شده است.

برای یک استقرارِ آلمانیِ consent-free، ترکیبِ معمولِ رویدادها چنین است: opt_out_received (با حجمِ کم — بیشتر بازدیدکنندگان هرگز مخالفت نمی‌کنند، چون معماری اعتراض‌برانگیز نیست)، گاه‌به‌گاه dsar_*_requested (حقوقِ فردِ موضوعِ داده، فارغ از حالت، ویژگی‌هایی از جنسِ در دسترس‌بودنِ فنی‌اند)، و یک جریانِ آرام و پیوسته از legal.*_viewed (رصدِ شفافیت‌نمایی که نشان می‌دهد بازدیدکنندگان واقعاً صفحه‌های سیاست را می‌خوانند).

این رویدادها به هر مقصدِ لاگی که محیطِ اپراتور پشتیبانی کند منتشر می‌شوند — stdout/stderr در استقرارهای کانتینری، syslog روی هاست‌های سنتی، یا یک جدولِ ممیزیِ اختصاصی در راه‌اندازی‌های خودمیزبان. این رویدادهای ممیزی به‌صورتِ JSON ساختاریافته‌اند تا تمیز و بی‌دردسر در Loki، Elasticsearch یا هر خط‌لوله لاگِ ساختاریافته دیگری تجزیه شوند.

‏ردِ ممیزی همان چیزی است که اگر DPA برلین یا BayLDA باواریا بازرسی‌ای را آغاز کند، اپراتور به آن اشاره می‌کند. بندِ موجود در سیاست حریم خصوصی، موضعِ عمومیِ روبه‌بیرون است؛ رویدادهای ممیزی، همان شواهدِ هم‌زمانی هستند که نشان می‌دهند آن موضع واقعاً پیاده شده است.

این کار به اپراتور آلمانی چه می‌دهد

نتیجه عملی این است:

• ‏بدون نیاز به بنر کوکی برای جریانِ کارِ سنجش مخاطب، بر این مبنا که اصلاً هیچ ذخیره‌سازی یا دسترسی روی دستگاهِ کاربر رخ نمی‌دهد — یعنی سخت‌گیرانه‌ترین موضعِ کنونیِ اروپا، نه با تفسیرِ معافیتِ ePrivacy، بلکه به‌حکم ساختار، برآورده می‌شود.
• ‏یک LIA مستندِ Article 6(1)(f) به‌عنوان پایه قانونیِ GDPR برای پردازشِ داده‌های شخصی که سرور پس از خواندنِ IP و User-Agent و Referer هنگام دریافت انجام می‌دهد. قالبِ LIA در مسیرِ /legal/lia است؛ آن را با مشورتِ وکیل، برای زمینه پردازشِ اپراتور سفارشی کنید.
• ‏یک بلوک سیاست حریم خصوصی که نامِ § 25 Abs. 1 TDDDG را می‌برد و توضیح می‌دهد چرا اعمال نمی‌شود. این بلوک در مسیرِ /legal/privacy-policy/de قرار دارد و آماده چسباندن مستقیم در صفحه /datenschutz اپراتور است.
• ‏یک پیکربندی که هر 27 کشور عضو را راضی می‌کند، با استقرارِ سخت‌گیرانه‌ترین خانه. افزودنِ ترافیک فرانسوی، ایتالیایی یا هلندی نیازی به بازطراحیِ معماری ندارد؛ همان پیکربندیِ موجود برای Sheet 16 از CNIL، راهنمای کوکیِ 2021 از Garante، راهنمای سنجش مخاطبِ AEPD و موضعِ کوکیِ تحلیلیِ AP هلند هم واجد شرایط است. نقشه کشوربه‌کشور، تفاوت‌ها را گام‌به‌گام شرح می‌دهد.
• ‏سازگاری رو به جلو با پیشنهادِ Digital Omnibus Article 88a(3)(c). اگر متنِ کمیسیون دست‌نخورده تصویب شود، یک استقرارِ consent-free از Statnive Live از همان روزِ اول واجد شرایط است.

اما این کار چه چیزی نمی‌دهد: توانِ راه‌اندازیِ رایگانِ یک بنر رضایتِ آلمانی، یا اجرای GA4 در آلمان بر پایه منافع مشروع. هیچ‌کدام دست‌یافتنی نیست؛ راهنمای 2024 از DSK هر دو مسیر را می‌بندد.

پرسش‌های پرتکرار

آیا اپراتور آلمانی هنوز برای هر هدفی به بنر نیاز دارد؟

شاید — اما نه برای سنجش مخاطب. یک بنر رضایت فقط برای پردازشی لازم است که § 25(1) از TDDDG را فعال کند (ذخیره‌سازی یا دسترسی روی دستگاه) و بیرون از § 25(2)(i)-(ii) بیفتد. این شامل هر کوکیِ تبلیغاتیِ شخص ثالث، پیکسل‌های هدف‌گیریِ مجدد، ابزارک‌های اشتراک‌گذاری اجتماعی که کوکی می‌گذارند، ویدیوهای جاسازی‌شده YouTube/Vimeo که هنگام بارگذاری صفحه کوکی می‌گذارند، کوکی‌های نسخه‌های آزمونِ A/B و مانندِ این‌هاست. برای آن اهداف، اپراتور باید بنری بدهد که تجربه کاربری «رد به همان آسانیِ پذیرش» داشته باشد و در جایی که اعمال‌پذیر است، شناساییِ مقررات مدیریت رضایتِ آلمان را رعایت کند.

لایه سنجش مخاطب — یعنی شمارش بازدیدکنندگان، محبوبیتِ صفحه‌ها و تحلیلِ منابع ورودی — تحت شرایطِ این نوشته به بنر نیاز ندارد. این انتخابِ اپراتور است که آنالیتیکس را روی لایه «فقط سنجش مخاطب» یکپارچه کند، یا برای انتسابِ تجارت الکترونیک، آزمونِ A/B یا انتسابِ کمپین بازاریابی، یک لایه جداگانه پشتِ دروازه رضایت اضافه کند.

مقررات مدیریت رضایت (EinwV) چطور؟

مقررات مدیریت رضایتِ آلمان — Einwilligungsverwaltungsverordnung — در 20 دسامبر 2024 به دست Bundesrat تصویب شد و در 1 آوریل 2025 طبق § 26(2) از TDDDG اجرایی شد. این مقررات، خدماتِ مدیریت اطلاعات شخصی (PIMS) را به رسمیت می‌شناسد؛ وب‌سایت‌ها باید سیگنال‌های خدماتِ مدیریت رضایتِ شناخته‌شده را رعایت کنند. EinwV قاعده ماهویِ § 25 را تغییر نمی‌دهد — بلکه یک مسیرِ PIMS شناخته‌شده برای آن رضایتی اضافه می‌کند که قاعده در جای لازم می‌طلبد.

برای یک استقرارِ consent-free، مقررات EinwV عمدتاً بی‌ربط است، چون هیچ رضایتی طلب نمی‌شود. اما برای یک استقرارِ consent-required یا hybrid، مسیرِ شناساییِ EinwV همان سازوکارِ بلندمدت برای رعایتِ سیگنال‌های رضایتِ سطحِ مرورگر است — برای اینکه ببینید Statnive Live امروز چطور مدیریتِ سیگنالِ سطحِ مرورگر را پیاده می‌کند، به نوشته مربوط به GPC و حالتِ hybrid مراجعه کنید.

آیا رأیِ Planet49 از BGH چیزی را تغییر می‌دهد؟

رأیِ دیوان عالی فدرال آلمان در پرونده BGH I ZR 7/16 Planet49 (مورخ 28 می 2020، در پی رأیِ CJEU C-673/17 مورخ 1 اکتبر 2019) در حقوق آلمان تأیید کرد که چک‌باکس‌های از پیش تیک‌خورده رضایتِ معتبر تولید نمی‌کنند و رویکردهای انصرافی طبق § 15(3) قدیمیِ TMG پس از GDPR کافی نبودند. این رأی، جهتِ رضایت در § 25 را تقویت می‌کند — آن را تضعیف نمی‌کند. اپراتورهایی که رأیِ BGH Planet49 را به‌منزله نرم‌شدنِ رژیمِ رضایتِ آلمان تفسیر می‌کنند، رأی را اشتباه خوانده‌اند.

اگر LIA من خیلی دقیق باشد، می‌توانم در آلمان برای کوکی‌ها از منافع مشروع استفاده کنم؟

نه. راهنمای 2024 از DSK صریح است: منافع مشروع در لایه دسترسی به دستگاهِ کاربر، جایگزین رضایتِ § 25 از TDDDG نمی‌شود. یک LIA کاملاً مستند برای پایه Article 6 از GDPR در پردازشِ بعدیِ داده‌های شخصی لازم است، اما قفلِ معافیتِ ذخیره‌سازیِ کوکی را در لایه § 25 باز نمی‌کند. این همان موضعِ پیوسته EDPB Opinion 5/2019 است و در راهنمای فناوری‌های ذخیره‌سازی و دسترسیِ ICO بریتانیا (آوریل 2026) دوباره تأیید شده است.

راهِ راضی‌کردنِ قانون آلمان بدون رضایت، این است که اصلاً از همان ابتدا روی دستگاه ننویسید. کوکی را از معماری حذف کنید؛ آن‌گاه پرسشِ منافع مشروع، فقط پرسشِ Article 6 از GDPR می‌شود، نه پرسشِ § 25.

چه کنید و از چه چیزی صرف‌نظر کنید

بکنید	نکنید
حوزه قضایی DE را در Statnive Live انتخاب کنید؛ پیش‌فرض را روی حالتِ consent-free بگذارید (اعتبارسنجِ قاعده‌سخت آن را اعمال می‌کند).	یک سایت آلمانی را روی حالتِ permissive نگذارید — § 25 از TDDDG آن را ممنوع می‌کند؛ اعتبارسنج ذخیره را رد می‌کند.
در حالتِ اروپا، به‌صورت پیش‌فرض به GPC و DNT احترام بگذارید؛ دریافت را پیش از محاسبه امضای بازدیدکننده متوقف کنید.	آنالیتیکسِ بدون‌کوکی را به‌طور خودکار منطبق با § 25 نپندارید — DSK تأیید کرده که دسترسی به اطلاعاتِ دستگاهِ کاربر هم § 25 را فعال می‌کند، حتی بدون کوکی.
بندِ واژه‌به‌واژه Reichweitenmessung را در /datenschutz منتشر کنید که نامِ § 25 Abs. 1 TDDDG و حقِ مخالفتِ Article 21 را می‌برد.	بدون LIA مستند و افشای سیاست حریم خصوصی ادعا نکنید «در DE نیازی به بنر رضایت نیست». موضع DSK هر دو را لازم می‌داند.
یک ارزیابیِ منافع مشروعِ Article 6(1)(f) را طبق EDPB Guidelines 1/2024 برای پردازشِ داده‌های شخصی که سرور هنگام دریافت انجام می‌دهد مستند کنید.	بر منافع مشروع به‌عنوان جایگزین رضایتِ § 25 در لایه دسترسی به دستگاهِ کاربر تکیه نکنید. سندِ DSK با عنوان Orientierungshilfe نسخه 1.2 صریح است: نمی‌تواند.
پیش از انتشار، با وکیلِ مجربِ آلمانی — معمولاً یک Fachanwalt für IT-Recht (وکیل متخصص حقوق فناوری اطلاعات) — هم‌سنجی کنید.	پیش از رضایت، GA4 / Meta Pixel / Hotjar را در آلمان اجرا نکنید. BayLDA، NRW LDI، BlnBDI و HmbBfDI همگی اپراتورها را به همین دلیل جریمه کرده‌اند.

حرف آخر

ماده § 25 از TDDDG آلمان، سخت‌گیرانه‌ترین موضعِ کنونیِ اروپا درباره رضایتِ دستگاهِ کاربر است. در قانون آلمان هیچ معافیتی برای سنجش مخاطب وجود ندارد، DSK تأیید کرده منافع مشروع جایگزین شرطِ § 25 نمی‌شود، و جریمه‌ها طبق § 28(1) No. 13 تا 300,000 یورو برای هر تخلف به‌علاوه جریمه‌های GDPR طبق Article 83 می‌رسد.

تنها معماری بدون‌رضایتی که از آلمان جان سالم به در می‌برد، آن است که در آن هیچ ذخیره‌سازی یا دسترسی روی دستگاهِ کاربر رخ ندهد. حالتِ consent-free در Statnive Live به‌علاوه حوزه قضایی DE دقیقاً همان معماری است، که با یک اعتبارسنجِ قاعده‌سخت اعمال می‌شود و از ذخیره یک پیکربندیِ آلمانیِ permissive سر باز می‌زند. بلوک سیاست حریم خصوصی در مسیرِ /legal/privacy-policy/de نامِ § 25 Abs. 1 TDDDG و حقِ مخالفتِ Article 21 را می‌برد. هشت رویداد ممیزیِ حریم خصوصی، ردِ پاسخ‌گوییِ هم‌زمان را منتشر می‌کنند.

اپراتوری که برای آلمان پیکربندی می‌کند، به‌حکم ساختار، برای بقیه اتحادیه اروپا هم پیکربندی شده است. مبنای سخت‌گیرانه، رو به بالا بنا می‌شود. راهنمای جامعِ آنالیتیکس بدون‌رضایتِ اتحادیه اروپا در 2026 قابِ گسترده‌تر است؛ نوشته مربوط به Sheet 16 از CNIL، گزینه جایگزینِ فرانسوی است؛ و نقشه کشوربه‌کشور، بقیه کشورهای عضو را گام‌به‌گام مرور می‌کند. مسیرِ اپراتور آلمانی، همان مسیری است که این نوشته شرح داد.

---

این یک پژوهش در حوزه حریم خصوصی است، نه مشاوره حقوقی. ‏Statnive Live، که در حالتِ consent-free برای حوزه قضایی DE با consent.respect_gpc = true و یک ارزیابیِ منافع مشروعِ مستند پیکربندی شده، به‌گونه‌ای معماری شده که به‌عنوان یک استقرارِ بدون‌ذخیره‌سازی‌یا‌دسترسی‌روی‌دستگاهِ کاربر تحت § 25 از TDDDG واجد شرایط شود. این معماری محرکِ § 25(1) را برمی‌دارد؛ و LIA پایه Article 6(1)(f) از GDPR را برای پردازشِ بعدی پوشش می‌دهد. هر مشتری Statnive همچنان متولّیِ داده باقی می‌ماند و مسئولیتِ پیکربندی و DPIA خودش را بر عهده دارد. پیش از انتشار، با وکیلِ مجربِ آلمانی — یعنی DPO ثبت‌شده یا یک Fachanwalt für IT-Recht — هم‌سنجی کنید.

وضعیتِ ارجاع‌های مقرراتی تا 13 می 2026: TDDDG (در 14 می 2024 از TTDSG تغییر نام یافت؛ بدون هیچ اصلاحِ متنی در § 25 میان آن تاریخ و ماه می 2026)؛ § 25 TDDDG؛ § 28(1) No. 13 TDDDG؛ سندِ DSK با عنوان Orientierungshilfe für Anbieter:innen von digitalen Diensten نسخه 1.2 مورخ 20 نوامبر 2024 (همچنان معتبر؛ بدون نسخه جانشین تا ماه می 2026؛ تأیید می‌کند که ردیابیِ بدون‌کوکی هم وقتی به اطلاعاتِ دستگاهِ کاربر دسترسی پیدا کند، § 25 را فعال می‌کند)؛ Einwilligungsverwaltungsverordnung (EinwV) که در 20 دسامبر 2024 به دست Bundesrat تصویب شد و از 1 آوریل 2025 اجرایی شد؛ BGH I ZR 7/16 Planet49 مورخ 28 می 2020؛ CJEU C-673/17 Planet49 مورخ 1 اکتبر 2019 (ECLI:EU:C:2019:801)؛ CJEU C-582/14 Breyer مورخ 19 اکتبر 2016 (ECLI:EU:C:2016:779)؛ CJEU C-621/22 KNLTB مورخ 4 اکتبر 2024 (ECLI:EU:C:2024:857)؛ EDPB Guidelines 2/2023 v2.0 مورخ 7 اکتبر 2024؛ EDPB Guidelines 1/2024 مورخ 8 اکتبر 2024؛ پیش‌نویسِ EDPB Guidelines 01/2025 درباره مستعارسازی (به‌صورت پیش‌نویس در 16 ژانویه 2025 تصویب شد؛ نسخه نهایی تا ماه می 2026 هنوز منتشر نشده)؛ ‏EDPB-EDPS Joint Opinion 2/2026 مورخ 11 فوریه 2026 درباره Digital Omnibus؛ EDPB Opinion 5/2019. ادامه اجرای قانونِ § 25 از TDDDG در سال‌های 2024 تا 2026 به دست BayLDA / NRW LDI / BlnBDI / HmbBfDI علیه استقرارهای GA4 / Meta Pixel / Hotjar که بدون رضایت مستقر شده‌اند.