Privacy (حریم خصوصی) در دنیای وب

Privacy (حریم خصوصی) در دنیای وب

Privacy از نظر لغوی به معنای حریم خصوصی است اما تعریف کامل آن شاید دشوارترین بخش این مقاله باشد! حریم خصوصی برای هر شخصی تعریف منحصربه‌فردی دارد و ممکن است اطلاعاتی که برای یک نفر حریم خصوصی تلقی می‌شود، برای شخص دیگری جزو معمولی‌ترین اطلاعات شمرده شود که فاش شدن یا نشدن آن‌ها اصلاً برایش حائز اهمیت نباشد و از همین روی تعریف دقیقی نمی‌توان از آن ارائه کرد اما به صورت عمومی اطلاعاتی مانند نام، نام خانوادگی، شماره تلفن، شغل، نشانی منزل یا محل کار و ... برای خیلی از افراد بخشی از حریم خصوصی به حساب می‌آید. به طور کلی، بیش از اهمیت تعریف حریم خصوصی و مباحث مربوط به آن، مسالۀ Privacy Protection (حفاظت از حریم خصوصی) مهم است؛ به عبارت دیگر، توانایی ممانعت در برابر افشای اطلاعاتی که هر نفر به عنوان حریم خصوصی خود در نظر می‌گیرد. همین تعاریف عیناً در وب هم وجود دارند با این تفاوت که در این پلتفرم افشای برخی اطلاعاتی که ممکن است شما به عنوان حریم خصوصی تلقی کنید لزوماً با اجازۀ شما نیست و بعضاً توانایی ممانعت یا همان Privacy Protection را ندارید! اگر دوست دارید بدانید که در وب چه ردپایی از شما باقی می‌ماند و چقدر توانایی پنهان کردن آن را دارید، در ادامه با سکان آکادمی همراه باشید.

پیش از پرداختن به مقولهٔ #حریم خصوصی می‌بایست کمی با سازوکار وب و اینترنت آشنا باشیم و در همین راستا در این مقاله تمرکز خود را روی این مسئله خواهیم گذاشت که وب چگونه کار می‌کند؛ سپس در مقالات مرتبط آتی بیشتر در مورد پرایوسی (حریم خصوصی) صحبت خواهیم کرد. 

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

گرچه برخی از این کارها از نظر ظاهری با هم تفاوت دارند، اما از نظر فنی اتفاقات یکسانی در پشت‌پرده رخ می‌دهد به طوری که وقتی پیجی را باز می‌کنید، یک Request (ریکوئست به معنی درخواست) از جنس HTTP برای سرور وب‌سایت مد نظر ارسال می‌شود و سرور هم یک Response (ریسپانس به معنی پاسخ) بر بستر پروتکل HTTP به مرورگرتان باز می‌گرداند (لازم به ذکر است که در ادامهٔ مقاله از اصطلاحات ریکوئست و ریسپانس به جای درخواست و پاسخ استفاده خواهد شد.)

مشابه همین اتفاق زمانی که در حال استفاده از یک شبکۀ اجتماعی هستید نیز روی می‌دهد چرا که این اتفاقات تحت عنوان یکسری پروتکل‌ها و استانداردها بین کلاینت و سرور در جریانند و تفاوت اصلی در واقع نوع پروتکل و روش‌های سرویس‌دهی توسط سرور می‌باشد. در همین راستا، بهتر است ببینیم هر کدام از تَسک‌ها (کارها) توسط چه پروتکل‌هایی انجام می‌شوند که در ادامه بیشتر این موضوع را خواهیم شکافت.

درآمدی بر پروتکل‌های مختلف
به طور کلی، از بین کارهای مهمی که با اینترنت انجام می‌دهیم هر کدام با یک پروتکل خاص منابع مورد نظر خود را از سرور دریافت می‌کند. مثلاً برای ارسال و دریافت ایمیل شما ریکوئست خود را با استفاده از پروتکل‌های SMTP ،POP3 و یا IMAP به سمت سرور ارسال ‌می‌کنید و برای باقی کارهای مهمی که انجام می‌دهید عموماً از پروتکل HTTP و یا ورژن امن آن HTTPS استفاده می‌کنید. بنابراین می‌توان گفت که پرکاربردترین پروتکلی که در دنیای اینترنت وجود دارد (HTTP(s است. استفاده از پروتکل HTTP به قدری در وب رایج است که می‌توان گفت وب بدون HTTP چیزی بی‌معنا است! بنابراین برای ادامۀ بحث نیاز به بررسی جزئی‌تر این پروتکل داریم.

HTTP که مخفف کلمات HyperText Transfer Protocol است، به عنوان مهم‌ترین استاندارد برای انتقال اطلاعات در اینترنت و به عبارتی شاکلۀ دنیای وب می‌باشد. این پروتکل در آخرین لایۀ OSI (که به لایۀ اپلیکیشن معروف است) فعال است و به صورت پیش‌فرض از پورت 80 استفاده می‌کند (برای کسب اطلاعات بیشتر، می‌توانید به آموزش نگاهی به پروتوکل HTTP و URL مراجعه نمایید.)

HTTP در قالب یکسری ریکوئست‌های کلاینت-سرور سعی در نزدیک کردن زبان انسان و ماشین دارد. همان‌طور که پیش از این اشاره‌ای کردیم، HTTPS نیز همان پروتکل HTTP است با این تفاوت که اطلاعات مابین سرور و کلاینت (مرورگر) رمزنگاری شده و کسی در بین راه قادر به فهم آن‌ها نمی‌باشد و این اطلاعات فقط در دو سَر کانکشن بامعنی می‌باشند و این در حالی است که پروتکل امن HTTPS به صورت پیش‌فرض از پورت 443 استفاده می‌کند به طوری که شبکه‌های اجتماعی، موتورهای جست‌وجو، درگاه‌های پرداخت اینترنتی و کلیۀ سایت‌هایی که اطلاعات مهمی دارند از این پروتکل برای انتقال امن دیتا مابین سرور خود و کلاینت‌ها استفاده می‌کنند (برای کسب اطلاعات بیشتر، به آموزش پروتکل امن SSL: سیگنالی هر چند کوچک برای رنکینگ بهتر سایت مراجعه نمایید.)

کلاینت چگونه ریکوئست را ارسال می‌کند؟
هنگامی که بر روی یک لینک کلیک کرده و یا یک آدرس را در قسمت Address Bar مرورگر وارد می‌کنیم، اتفاقات بسیاری رخ می‌دهد؛ بنابراین برای اینکه سیر بحث منظم‌تر باشد، اجازه بدهید این اتفاقات را دسته‌بندی کنیم.

ابتدا مرورگر از سیستم‌عامل ریکوئست یک پورت آزاد می‌کند سپس سیستم‌عامل از میان پورت‌های خالی خود یک پورت را به مرورگر می‌دهد و مرورگر با استفاده از آن پورت ریکوئست خود را روی پورت 80 یا 443 (بسته به اینکه از HTTP استفاده کنیم یا HTTPS) برای سرور به صورت یک HTTP Request ارسال می‌کند و این عمل با هر بار ریکوئست کلاینت مابین مرورگر و سیستم‌عامل اتفاق می‌افتد (برای کسب اطلاعات بیشتر، می‌توانید به آموزش آشنایی با پورت‌های پروتکل HTTP مراجعه نمایید.) بنابراین هر تَب و هر مرورگر پورت مخصوص به خودش را دارد و با هر بار تکرار این ریکوئست، این پورت ممکن است به کلی عوض بشود. در واقع، مرورگر ریکوئست شما را در پروتکل HTTP به صورت زیر در می‌آورد:

Request-method-name Request-URI HTTP-version
Request-header-name: Request-header-value1, Request-header-value2, ...

Request-message-body

همان‌طور که می‌بینید، خط اول از سه بخش تشکیل شده است که در بخش اول HTTP Method قرار می‌گیرد که می‌تواند یکی از متدهای PUT ،POST ،GET و یا UPDATE باشد (البته متدهای نام‌ برده شده به عنوان اصلی‌ترین متدها بوده و به غیر این موارد متدهای بیشتری نیز وجود دارند که برای کسب‌ اطلاعات بیشتر، می‌توانید به آموزش متدهای اصلی در پروتکل HTTP مراجعه نمایید.)

در بخش دوم مسیری قرار می‌گیرد که در سرور منبع قرار دارد و در بخش سوم ورژن HTTP که می‌خواهیم استفاده کنیم قرار خواهد گرفت (به این دلیل از لفظ منبع یا Resource استفاده می‌کنیم که ریکوئست شما ممکن است یک صفحۀ معمولی وب، نمایش یک ویدئو، دانلود یک فایل و ... باشد و هر کدام از این ریکوئست‌ها به یک فایل با فرمت مشخصی در سرور منتهی می‌شود.)

در خط دوم به بعد هِدِرهای HTTP قرار می‌گیرند که بسته به مرورگر، سرور و ... مقادیر مختلفی به صورت اصطلاحاً Key:Value در آن قرار می‌گیرند. Key در واقع Header Name می‌باشد و مهم‌ترین Header Name که در هِدِر باید وجود داشته باشد Host است که بیانگر سروری می‌باشد که ریکوئست کلاینت باید به سمت آن ارسال شود و از دیگر مقادیر مهم آن می‌توان به User Agent و Accept Language اشاره کرد.

بعد از یکسری Header Name مختلفی که در ریکوئست ما قرار گرفتند، یک خط خالی قرار می‌گیرد و پس از آن قسمت Body پُر می‌شود. به مقادیری که قبل از خط خالی قرار می‌گیرند به صورت کلی بخش HTTP Header گفته می‌شود و مقادیری که بعد از خط خالی می‌آیند بخش Body را تشکیل می‌دهند که البته بخش Body عموماً در Request حائز اهمیت نیست. برای روشن‌تر شدن مسئله، اجازه بدهید بحث را با یک مثال دنبال کنیم. مثلاً هنگامی که شما در مرورگر خود آدرس وب‌سایت سکان آکادمی را وارد می‌کنید، مرورگر ریکوئست شما را به صورت زیر در می‌آورد:

GET /index.html HTTP/1.1

Host: www.sokanacademy.com

خط اول به ما می‌گوید که با استفاده از ورژن 1.1 پروتکل HTTP یک فایل با فرمت html را که در مسیر / قرار دارد که احتمالاً همان جایی که وب‌سرور به عنوان روت می‌شناسد را از سرور درخواست می‌کنیم تا در اختیارمان قرار دهد (GET به معنای ریکوئست گرفتن منبع از سرور می‌باشد.) در خط دوم که هِدِرها از همین خط شروع می‌شوند، هِدِری به نام Host را می‌بینیم که مقدار آن همان اسم سروری است که ریکوئست ما باید به آن ارجاع داده شود و اینجا وب‌سایت www.sokanacademy.com می‌باشد. در اینجا کار مرورگر، یا در واقع کلاینت، تمام می‌شود و فعل و انفعالاتی در حین راه تا رسیدن به مقصد انجام می‌شود که در ادامه آن‌ها را بررسی می‌کنیم.

درآمدی بر DNS Server و Nat Server
حال بعد از اینکه مرورگر ریکوئست ما را به شکل قابل‌فهمی برای سرور تبدیل کرد، پورت را از سیستم‌عامل گرفته و به همراه آی‌پی سیستم شما برای سرور ارسال می‌کند و بعد از اینکه این ریکوئست از مرورگر جدا شد، اولین مسأله‌ای که باید روشن شود تبدیل Host Name به آی‌پی می‌باشد که توسط DNS Server انجام می‌شود. بعد از مشخص شدن آی‌پی سرور، ریکوئست شما به GateWay ارسال می‌شود و توسط دیوایس‌های شبکه (مثل مودم، سوئیچ، روتر و ...) به سمت سرور ارسال می‌شود.

خارج از مباحث روتینگ و سوئیچینگ که در این مقال نمی‌گنجند، مهم‌ترین اتفاقی که در این حین رخ می‌دهد تبدیل آی‌پی Private به Public و عوض کردن پورتی که از سیستم‌عامل گرفتید به پورت دیگری که Nat Server تشخیص می‌دهد می‌باشد. برای آنکه بتوان ریسپانسی به ریکوئست شما داد، ریکوئست باید یک آی‌پی منحصربه‌فرد داشته باشد و از آنجایی که آی‌پی‌های منحصربه‌فرد در سطح جهان محدود می‌باشند و امکان اختصاص آی‌پی یکتا به هر کلاینت عملاً امکان‌پذیر نیست، برای حل این مشکل آیپی‌های Private که فقط در محدودۀ لوکال شما معتبر می‌باشند در یک سروری که معمولاً در ISP شما قرار دارد به یک آی‌پی یکتای قابل‌ردگیری در اینترنت توسط Nat Server تبدیل می‌شود و برای اینکه ریکوئست‌های کلاینت‌های مختلف برای گرفتن ریسپانس اشتباه نشوند، به ازای هر پورت و آی‌پی Private یک پورت جدید در Nat Server (هر پورتی که خالی باشد) به آن اختصاص داده می‌شود که این تبدیل در یک جدولی به اسم Nat Table نگهداری می‌شود تا در هنگام گرفتن ریسپانس از سرور، هر ریکوئست به آی‌پی و پورت درستی ارجاع داده شود. بنابراین سرور شما در واقع Nat Server را به عنوان ریکوئست‌دهنده می‌شناسد و آی‌پی و پورتی که Nat Server به آن ارجاع می‌دهد را در نهایت به عنوان مبدأ ریکوئست در نظر می‌گیرد و جواب نهایی را به سمت آن ارسال می‌کند.

سرور چگونه ریکوئست را گرفته و به آن جواب می‌دهد؟
در سمت سرور ریکوئست‌هایی که به پورت 80 و یا 443 ارسال می‌شوند توسط وب‌سرور دریافت و تحلیل می‌شوند که این وب‌سرورها عموماً برنامه‌هایی نظیر Apache و Nginx می‌باشند که به محض نصب بر روی یک سیستم، پورت‌های HTTP را اِشغال کرده و اصطلاحاً روی این پورت‌ها Listen می‌کنند که برای کسب اطلاعات بیشتر، می‌توانید به آموزش آشنایی با وب سرور و نحوهٔ عملکرد آن مراجعه نمایید.

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

به ریسپانسی که از سمت سرور ارسال می‌گردد اصطلاحاً HTTP Response گفته می‌شود که به غیر از خط اول ریسپانس، باقی موارد آن کاملاً شبیه ریکوئست می‌باشد (البته در اینجا برخلاف ریکوئست، قسمت Body بسیار مهم بوده و در واقع منبعی هست که کاربر آن را درخواست کرده و در مرورگرش نمایش داده خواهد شد.) به طور کلی، ساختار HTTP Response به صورت زیر می‌باشد:

HTTP-version Status-code Reason-phrase
Response-header-name: Response-header-value1, Response-header-value2, ...

Response-message-body

خط اول همانند ریکوئست، شامل سه بخش می‌باشد که در بخش اول ورژن HTTP که می‌خواهیم استفاده کنیم را قرار می‌دهیم، در بخش دوم کدی که سرور به ما برمی‌گرداند و در بخش سوم توضیح مختصر این کد قرار دارد (به این کد Status Code و به خط اول Status Line نیز گفته می‌شود.) کدی که سرور در این بخش قرار می‌دهد برای مرورگر قابل‌فهم است و بیان می‌کند که ریکوئستش در سمت سرور با چه وضعیتی روبه‌رو شده است. مثلاً ممکن است منبعی که آن را ریکوئست کرده در سرور موجود نباشد یا دسترسی به آن ممنوع باشد و یا حتی اروری داخل سرور رخ داده باشد که در حال حاضر قادر به ارائۀ سرویس برای ریکوئست شما نباشد و در آخر ممکن است منبع شما را با موفقیت در این ریسپانس فرستاده باشد. در هر صورت، مرورگر در سمت کلاینت باید کاملاً از Status Code مطلع باشد (برای کسب اطلاعات بیشتر، می‌توانید به آموزش آشنایی با پیام‌های HTTP مراجعه نمایید.)

در صورت موفقیت، سرور کد وضعیت 200 را برمی‌گرداند و از کدهای معروف دیگر می‌توان به 404، 403، 500 و ... اشاره کرد که احتمالاً‌ با کد 404 بارها و بارها در وب‌گردی مواجه شده باشید! در بخش Body ریسپانس، سرور فایل ریکوئستی شما را قرار می‌دهد که در صورتی که شما ریکوئست دیدن یک صفحۀ وب را کرده باشید، سرور کدهای HTML را در اینجا قرار می‌دهد. به عنوان مثال داریم:

HTTP/1.1 200 OK
Date: Mon, 27 Jul 2009 12:28:53 GMT
Server: Apache/2.2.14 (Win32)
Last-Modified: Wed, 22 Jul 2009 19:15:56 GMT
Content-Length: 88
Content-Type: text/html
Connection: Closed

<html>
<body>
<h1>Hello, World!</h1>
</body>
</html>

پس از ارسال این ریکوئست، وب‌سرور سوکت مورد نظر را می‌بندد و از همین روی HTTP را یک پروتکل Stateless (بدون حالت) می‌نامند؛ به عبارت دیگر، اصولاً هیچ‌گونه حافظه‌ای از کاربری که به صورت مداوم به آن ریکوئست می‌دهد ندارد و هر ریکوئست ارسال شده از طرف کاربر را به نوعی پردازش می‌کند که گویی کاربر جدیدی است (این مسئله در موارد متعددی می‌تواند برای ما مشکل‌ساز باشد که برای حل آن از مفهوم Session استفاده می‌کنند که خارج از این بحث است.)

در اینجا همانند ریکوئست، پیامی که سرور ارسال می‌کند بعد از طی مسیرهای مختلفی که وظیفۀ روتینگ و ... را به عهده دارند به مهم‌ترین بخش خود یعنی Nat Server می‌رسد. Nat Server ریکوئست سرور را گرفته به Nat Table مراجعه می‌کند و آی‌پی و پورتی که سرور برای آن فرستاده است را به آی‌پی و پورت لوکال تبدیل می‌کند و به سمت کلاینت (مرورگر کاربر) می‌فرستد.

و اما در بخش انتهایی پروتکل HTTP، سیستم‌عامل پس از گرفتن ریسپانس، آن را به برنامه‌ای که پورت را اشغال کرده است هدایت می‌کند و مرورگر بعد از گرفتن آن قسمت، Body را به شکلی ساختاریافته و زیبا در اختیار کاربر قرار می‌دهد. مثلاً اگر در Body کدهای HTML وجود داشته باشد، مرورگر وظیفه دارد تا این کدها را تفسیر کند و به صورت اَشکال و متون قابل‌درک توسط کاربر تبدیل کند.

بعد از بررسی جزئی پروتکل HTTP و آشنایی با دنیای وب و مبانی آن در این مقاله، در پست بعدی قصد داریم مسئلۀ تبادل اطلاعاتی که به صورت ناخواسته بین کلاینت و سرور صورت می‌گیرند را زیر ذر‌ه‌بین ببریم و ببینیم Privacy (حریم خصوصی) به چه شکلی نقض می‌شود! با سکان آکادمی همراه باشید.



محمد طاهری