لاگ‌های سرور و حریم خصوصیمیزبان شما لاگ‌برداری را متوقف کرد. سرور شما نه.

اکنون شما طرفی هستید که به او نامه می‌نویسند

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

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

یک خط از لاگ دسترسی واقعاً چه چیزی در خود دارد

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

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

نُه جایی که پشتهٔ شما یک بازدیدکننده را ثبت می‌کند

تقریباً هر بحثی دربارهٔ لاگ‌برداری، دربارهٔ همان ردیف اول است. همانی است که مردم می‌دانند وجود دارد، و به‌هیچ‌وجه افشاگرترین چیز روی آن ماشین نیست.

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

دو فیلدی که بیش از خودِ آدرس لو می‌دهند

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

آدرس ارجاع‌دهنده خواننده را توصیف می‌کند، نه درخواست را

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

user agent، هستهٔ اولیهٔ یک اثر انگشت است

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

رازها به این دلیل واردِ لاگ می‌شوند که در URL بوده‌اند

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

• لینک‌های بازنشانی رمز عبور. یک توکنِ یک‌بارمصرف در query string، به‌صورت متن‌ساده هم در لاگ دسترسی ثبت می‌شود، هم در پشتیبانِ آن لاگ، و هم در هر پراکسی‌ای که میان خواننده و شما قرار دارد.
• لینک‌های دعوت و لغو اشتراک. همان شکل، اما عمرِ طولانی‌تر، و معمولاً اصلاً منقضی نمی‌شوند.
• شناسه‌های نشست که در URL منتقل می‌شوند. در کدهای جدید کمیاب‌اند، در کدهای قدیمی هنوز حضور دارند، و برای هر کسی که آن فایل را در اختیار داشته باشد، یعنی تصاحبِ کاملِ یک حساب.
• کلیدهای API که در اختیار مرورگر گذاشته می‌شوند. کلیدی در query string، یعنی کلیدی در لاگ، کلیدی در ارجاع‌دهنده‌ای که برای یک شخص ثالث فرستاده می‌شود، و کلیدی در تاریخچهٔ خواننده.
• جعبهٔ جست‌وجو. جست‌وجویی در سایت که با GET ارسال شود، هر عبارتی را که تابه‌حال کسی در سایت شما تایپ کرده، درست کنارِ آدرسِ همان کسی که تایپش کرده، ثبت می‌کند.

راه‌حل، یک تنظیمِ لاگ‌برداری نیست. مقدار را به داخل یک هدر یا بدنهٔ درخواست منتقل کنید، جایی که هیچ قالبِ پیش‌فرضی آن را ثبت نمی‌کند، و هر چه از قبل نوشته شده را هم بچرخانید (rotate). یک فیلترِ لاگ که توکن‌ها را حذف می‌کند، خودش چیزِ دومی می‌شود که باید نگه‌داری شود، و همان اولین باری که کسی یک پارامتر جدید اضافه کند، از کار می‌افتد.

چه چیزی می‌تواند از شما مطالبه شود، و توسط چه کسی

دیگر راهنماهای این مجموعه دربارهٔ ابزارهای قانونی‌ای‌اند که به یک شرکت میزبانی، در یک حوزهٔ قضاییِ انتخاب‌شده برای همین منظور، می‌رسند. اما ابزاری که به لاگ‌های خودِ شما می‌رسد ساده‌تر است: مستقیماً به خودتان ابلاغ می‌شود، همان‌جا که هستید، و محل قرارگیریِ ماشین اصلاً بخشی از موضوع نیست.

• یک مطالبهٔ حقوقیِ مدنی در کشور خودتان. کسی که به‌خاطر یک کامنت، یک نشتِ اطلاعات یا یک خرید طرح دعوی می‌کند، از گردانندهٔ سایت می‌خواهد آنچه را در اختیار دارد ارائه دهد. آن گرداننده شما هستید، و دو هفته لاگ دسترسی چیزی نیست که دستور به ارائه‌اش سخت باشد.
• درخواستِ یک خواننده. طبق قانون حفاظت از داده‌های اروپا، هر شخص می‌تواند بپرسد شما چه چیزی دربارهٔ او نگه داشته‌اید، و یک آدرس هم می‌تواند داده شخصی محسوب شود: دیوان دادگستری اتحادیهٔ اروپا در سال ۲۰۱۶، در Case C-582/14، دقیقاً همین را حکم داد؛ جایی که یک آدرس پویا در اختیار گردانندهٔ یک سایت، داده شخصی شناخته شد، چون مسیری قانونی برای شناساییِ مشترک وجود داشت. دورهٔ نگه‌داری هم باید توجیه‌پذیر باشد — Article 5(1)(e) می‌گوید نه بیشتر از آنچه ضروری است، و “بسته همین‌جوری فرستاده شد” یک هدف محسوب نمی‌شود.
• هر کسی که ماشین را نفوذ کند. محتمل‌ترین خوانندهٔ لاگ دسترسیِ شما، اصلاً یک دادگاه نیست. لاگ‌ها به‌ندرت رمزنگاری می‌شوند، به‌ندرت پایش می‌شوند، و تقریباً هیچ‌وقت در مدل تهدید (threat model) گنجانده نمی‌شوند، و روی هر سروری که به شکل معمول ساخته شده باشد، در یک مسیرِ قابل‌پیش‌بینی قرار دارند.
• هر کسی که پشتیبان‌های شما به او می‌رسد. یک نسخهٔ خارج از محل، یعنی یک نسخه در یک شرکت دیگر، زیرِ یک حوزهٔ قضاییِ دیگر، پاسخگو به ابزارهای قانونی‌ای که شما هرگز نخوانده‌اید.

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

کمتر نگه‌داشتن، بدون کور شدن

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

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

شخص‌ثالث‌هایی که خوانندگانِ شما را به‌جای شما لاگ می‌کنند

همهٔ آنچه تا این‌جا گفته شد، دربارهٔ فایل‌هایی روی ماشینی است که خودتان کنترلش می‌کنید. اما مرورگری که صفحهٔ شما را بار می‌کند، به هر origin دیگری که صفحه نامش را می‌برد هم یک اتصال باز می‌کند، و هر کدام از آن‌ها آدرس، user agent، و یک ارجاع‌دهنده را که می‌گوید کدام صفحهٔ شما خوانده می‌شده، دریافت می‌کنند — پیش از این‌که کسی به بنرِ رضایت پاسخ داده باشد، چون درخواست از قبل رفته.

• یک فونت که از سرورِ کسِ دیگری سرو می‌شود. یک خط در یک stylesheet، و همینْ خوانندهٔ هر صفحه را به یک شخص ثالث افشا می‌کند، آن‌هم برای فایلی که می‌توانستید در همان دایرکتوریِ بقیهٔ سایت میزبانی‌اش کنید.
• یک ویدیو یا نقشهٔ جاسازی‌شده. به‌محضِ دیده‌شدن بار می‌شود، روی هر صفحه‌ای که در آن ظاهر شود، چه کسی دکمهٔ پخش را بزند چه نزند.
• یک ویجتِ چت یا یک tag manager. از همان ابتدا طراحی‌شده که روی هر صفحه حاضر باشد، و قادر است کدهای بیشتری را که شما هرگز بازبینی نکرده‌اید، بار کند.
• یک ردیابِ خطا. مفیدترینِ این ابزارها و در عین حال افشاگرترین‌شان: کارش این است که وضعیتِ نشستِ یک شخصِ دیگر را برایتان بفرستد.
• یک CDN جلوی کل سایت. این استدلالی بر ضدِ داشتنِ آن نیست — یک معاملهٔ معقول است — اما در عین حال شرکتی است که هر درخواست را پیش از خودِ شما می‌بیند، لاگ‌های خودش را نگه می‌دارد، و پاسخگوی حوزهٔ قضاییِ خودش است.

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

این مجموعه دربارهٔ این موضوع چه می‌تواند بکند، و چه کاری از دستش برنمی‌آید

ترسیمِ صادقانهٔ این مرز، بیشتر از هر دلگرمی‌ای ارزش دارد، پس بگذارید از این طرفِ ماجرا بگوییمش.

• لاگ‌های دسترسیِ HTTP خودِ ما روی یک تایمرِ بیست‌وچهارساعته نابود می‌شوند، و نه سابقهٔ آدرسی باقی می‌ماند، نه سابقهٔ محلِ ورود، و نه هیچ اثر انگشتی که از آن جان سالم به در ببرد. آنچه واقعاً باقی می‌ماند، به‌طور کامل به‌صورت فهرست منتشر شده، و به هفت سابقه می‌رسد.
• آنچه از مسیرِ فرایندِ قانونی می‌رسد، در گزارش شفافیت شمارش می‌شود، و این‌که یک دستورِ معتبر واقعاً چه چیزی به بار می‌آورد، از پیش نوشته شده، نه چیزی که در همان لحظه تصمیم گرفته شود.
• روی یک VPS یا یک سرورِ اختصاصی، لاگ‌هایی که در این صفحه توصیف شدند، داخلِ سیستم‌عاملِ خودِ شما هستند. ما نه آن‌ها را می‌خوانیم، نه به‌جایی می‌فرستیم، و نه حتی می‌توانیم به‌جای شما پیکربندی‌شان کنیم — تک‌مستأجری (single tenancy) از هر دو طرف برش می‌خورد، و دقیقاً هدف از آن هم همین است.
• چیزی که ما می‌توانیم برعهده بگیریم، همان لایهٔ زیرین است: هیچ سابقهٔ هویتی هنگام ثبت‌نام، تسویه‌حساب فقط به‌صورت on-chain، و ماشینی در حوزهٔ قضاییِ انتخابیِ خودتان، نه همان حوزه‌ای که صادرکنندهٔ کارتتان در آن قرار دارد.

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

یک ممیزیِ یک‌ساعته از لاگ‌های خودتان

هیچ‌یک از موارد زیر به ابزاری که باید بخرید نیاز ندارد، و هر گام چیزی را به شما می‌گوید که گام پیش از آن نگفته بود.

1. یک خط از لاگ دسترسیِ خودتان را چاپ کنید و آن را همان‌طور که یک غریبه می‌خواند، فیلد به فیلد، با صدای بلند بخوانید.
2. هر فایلی را که زیرِ دایرکتوریِ لاگِ شما قرار دارد فهرست کنید، و بعد آن‌هایی را که در سالِ گذشته بازشان کرده‌اید علامت بزنید. آن‌هایی که علامت نخورده‌اند، خالصانه فقط ریسک‌اند.
3. تنظیماتِ چرخش را بخوانید و تعدادِ روزهایی را که واقعاً نگه می‌دارد بنویسید، نه همان عددی که یادتان می‌آید زمانی با آن موافقت کرده بودید.
4. پشتیبانِ ماهِ گذشته را در یک دایرکتوریِ موقت بازیابی کنید و دنبالِ همان لاگی بگردید که فکر می‌کردید دو هفته پیش حذف شده.
5. در لاگ دسترسیِ خودتان دنبالِ واژه‌های token، reset، key، session و password بگردید. هر چیزی که پیدا کنید، رازی است که از قبل روی دیسک نوشته شده و باید عوض (rotate) شود، نه فقط تعمیر.
6. صفحهٔ اصلیِ خودتان را با پنلِ network مرورگر باز بارگذاری کنید و هر دامنه‌ای را که تماس گرفته شده و مالِ خودتان نیست بنویسید. هر کدام از آن‌ها، شرکتی است که خوانندگانِ شما را زیرِ دورهٔ نگه‌داریِ خودش نگه می‌دارد.
7. بررسی کنید کدام هدر، آدرسِ واقعی را پشتِ پراکسی یا CDN شما حمل می‌کند، و مطمئن شوید که origin آن را ثبت می‌کند یا نه. یک CDN جلوی لاگ‌کردنِ origin را نمی‌گیرد؛ فقط فیلد را جابه‌جا می‌کند.
8. آخرین رویداد را در ردیابِ خطای خودتان باز کنید و بشمارید چند جزئیات از یک خوانندهٔ واقعی داخلِ payload آن هست.
9. سه عددِ نگه‌داری را عمداً تعیین کنید — امنیت، آنالیتیکس، پشتیبان‌ها — و آن‌ها را جایی بنویسید که بعدی‌ترین کسی که به سرور دست بزند، پیدایشان کند.
10. فهرست را بنویسید: چه چیزی وجود دارد، کجا، چه‌مدت، و اگر فردا صبح یک دستورِ معتبر برسد، چه چیزی ارائه خواهید داد. اگر نوشتنِ این سند برایتان ناخوشایند است، همین، مفیدترین ساعتِ این فهرست است.

پرسش‌هایی که واقعاً پرسیده می‌شوند

هر قیمت در این مجموعه به‌طور کامل و در یک مکان منتشر شده است. کل کاتالوگ را ببینید