هک شدن حساب اینستاگرام؛ مشکل آزاردهنده کاربران میلیاردی این شبکه اجتماعی

کریستا، فردی که در صفحه‌ی ورزشی اینستاگرامش بیش از ۴ هزار و ۵۰۰ فالوور داشت، چند روز پیش متوجه موضوعی عجیب شد؛ او از اکانت اینستاگرام خود لاگ‌اوت شده بود.

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

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

مقاله‌ی مرتبط:

• کودک ۱۰ ساله اینستاگرام را هک کرد و ۱۰ هزار دلار جایزه گرفت

تصویر پروفایل اکانت مگان (همچون ده‌ها قربانی دیگری که ناراحتی‌شان از هک‌شدن را به وب‌سایت Mashable گزارش کرده‌اند) عوض شده بود و او در اکانتش اطلاعات تمامی مخاطبینش را داشت؛ اطلاعاتی که اکنون به ایمیلی با دامین ru. (متعلق به روسیه) لینک شده بودند.

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

طبق داده‌های منتشرشده از سوی پلتفرم تحیلی تاک‌واکر، طی هفت روز گذشته بیش از ۵هزار توییت از سوی ۸۹۹ اکانت منتشر شده است که محتوای آن‌ها، به هک‌شدن پروفایل اینستاگرام‌شان اشاره داشته است.

گرچه اینستاگرام (که هم‌اکنون تعداد کاربرانش عدد ۱ میلیارد نفر را رد کرده) مدعی است که شدت این هک‌ها زیاد نیست، اما با بررسی داده‌های به‌دست‌آمده از توییتر، نتایج به شکلی دیگر رقم می‌خورند. از اول ماه آگوست، کاربران Twitter در تقریبا ۷۹۸ توییت به‌طور مستقیم و با منشن کردن اکانت رسمی اینستاگرام در این شبکه‌ی اجتماعی، از واژه‌ی «هک» استفاده کرده‌اند؛ گفتنی است که این رقم در همین بازه‌ی زمانی در ماه جولای، ۴۰ توییت بود.

حتی مدتی است که گزارشات هک‌شدن اکانت‌های اینستاگرام روی انجمن ردیت هم زیاده شده‌اند و با بررسی آمار ارائه‌شده از سوی ابزار گوگل ترندز، می‌توان متوجه شد که میزان سرچ جمله‌ی «هک شدن اینستاگرام» در روزهای هشتم و یازدهم آگوست، به‌شکلی محسوس جهش داشته است.

در همین رابطه، نماینده‌ای از شرکت اینستاگرام در اطلاعیه‌ای گفته است:

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

هنوز مشخص نیست که هکرها دقیقا چگونه به اطلاعات این حساب‌های کاربری دسترسی پیدا می‌کنند. وب‌سایت Mashable از میان قربانی‌های اینستاگرام، موارد مشابهی را پیدا کرده است (مثل عوض شدن تصویر پروفایل به شخصیتی از فیلم‌های دیزنی و پیکسار، عوض‌شدن بخش Bio و یک‌سری ایمیل مشابه با دامین ru.). در بیشتر این نمونه‌ها، کاربرانی که حساب‌شان هک شده است، ویژگی احراز هویت دومرحله‌ای را فعال نکرده بودند؛ با این حال در موارد انگشت‌شماری، حتی با وجود فعال بودن این ویژگی امنیتی، اکانت کاربران هک شده است.

کریس وزینچکی، یکی دیگر از قربانیان است که اطلاعات حساب کاربری‌اش، از جمله ایمیل لینک‌شده به اکانتش تغییر کرده بودند

همان‌طور که در تصویر بالا می‌توانید ببینید، حتی احراز هویت دومرحله‌ای نیز نتوانست اکانت کریس وزینچکی را از خطر هک شدن محافظت کند. وزینچکی می‌گوید اکانتش ۱۰ روز پیش هک شده است و در آن زمان به ایمیل شخصی‌اش پیامی از سوی اینستاگرام آمده و گفته شده است که ایمیل اکانت اینستاگرامش به ایمیلی با دامین ru. تغییر کرده و احرار هویت دومرحله‌ای نیز غیرفعال شده است. متاسفانه از آنجا که او ایمیل‌ را دیر خواند، نتوانست به‌موقع اقدام کند و به همین دلیل اکانت اینستاگرامش را با ۶۶۰ فالوور از دست داد.

برای عده‌ای از کاربران، دسترسی مجدد به اکانت اینستاگرام‌شان موضوعی فراتر از یک مشکل شخصی ساده است

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

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

وزینچکی در گزارشش به وب‌سایت Mashable می‌گوید:

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

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

ابیگل نواک، کاربر دیگری که از قربانیان هک اینستاگرام به حساب می‌آید، جملات جالبی را به زبان آورده است:

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

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

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

اگر نتوانم حساب کاربری‌ام را پس بگیرم، ارتباطاتم با حامیان مالی با مشکل رو‌به‌رو می‌شود.

این درحالی است که برخی از کاربران اینستاگرام توانسته‌اند پروسه‌ی بازیابی اکانت را به‌سلامت طی کنند و اکانت‌شان را پس بگیرند؛ برای مثال، کاربری گفته است که پس از گزارش هک شدن اینستاگرامش، توانسته آن را بازیابی کند. او صراحتا اشاره کرده است که «پروسه‌ی بازیابی، بسیار استرس‌زا است.»

هک‌شدن اکانت‌های اینستاگرام، موضوع جدیدی نیست. این شبکه‌ی اجتماعی با دارا بودن بیش از ۱ میلیارد کاربر در سراسر جهان، مدت‌ها است که مورد توجه هکرها قرار گرفته است.

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

انتشار عکسی قدیمی در توییتر سامسونگ و ادعای ثبت‌شدن آن توسط گلکسی ای 8

هواوی سال ۲۰۱۶ عکسی را روی خروجی اکانت رسمی خود در گوگل‌پلاس قرار داد و گرچه به‌طور مستقیم به ثبت‌شدن آن توسط گوشی پی ۹ اشاره نکرده بود، اما به‌طور ضمنی اعلام کرده بود که دوربین دوگانه‌ی به‌کار رفته در این اسمارت‌فون، تصویر یادشده را ثبت کرده است. مدت زیادی نگذشته بود که مشخص شد آن تصویر قبلا توسط دوربین ۲۶۰۰ دلاری Canon EOS 5D Mark III و با بهره‌گیری از لنز ۱۹۰۰ دلاری EF70-200 f/2.8L IS II USM گرفته شده است.

روز گذشته داستان مشابهی برای شعبه‌ی برزیلی سامسونگ اتفاق افتاد. توییتر سامسونگ برزیل در روز شانزدهم آگوست، عکس زوج جوانی را منتشر کرد و ادعا کرد که تصویر یادشده توسط دوربین سلفی گوشی گلکسی A8 2018 ثبت شده است؛ اما آن‌طور که مشخص شده، این عکس در حقیقت در سال ۲۰۱۵ و با عنوان «پرتره‌ای از یک زوج زیبایِ خوشحالِ خودمانی» گرفته شده است. جالب اینجا است که توییتر سامسونگ برزیل باری دیگر این اشتباه را تکرار کرد؛ این صفحه برای پروموت کردن عکس قبلی، تصویر دیگری را زیر پست قبلی منشن کرد که نهایتا مشخص شد توسط Getty Images گرفته شده است.

کاربری در توییتر، در بخش کامنت‌های پست یادشده این موضوع را به Samsung اطلاع داد و این شرکت هم، در پاسخ عذرخواهی کرد و گفت:

معذرت می‌خواهیم؛ حق با شما است. بسیاری از تصاویری که ما در توییترمان پست می‌کنیم، توسط گوشی‌های هوشمند خودمان ثبت شده‌اند، اما بعضی دیگر -مثل این عکس- [تصاویر اختصاصی نیستند، اما] بیان‌گر نگرش کاربران هدف ما هستند.

دارپا هنوز از وب به‌عنوان سلاح استفاده می‌کند

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

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

اینترنت در اصل یکی از پروژه‌های نظامی ایالات متحده بوده است

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

شاید این داستان‌ها برای برنامه‌نویسان جوان که پس از ۱۹۸۹ متولدشده‌اند، به‌نظر عجیب یا حتی شگفت‌انگیز برسد؛ به‌ویژه اگر اهل ایالات متحده یا اتحاد جماهیر شوروی نبوده باشید، تشخیص دوست و دشمن برایتان دشوار می‌شود. اروپا از هر دو طرف (شرق و غرب) با دو پروپاگاندای قدرتمند احاطه شده بود و هنوز هم آثار این جنگ فرهنگی باقی مانده است.

پروتکل اینترنت به‌اندازه‌ای مفید بود که برای ساخت مجموعه‌ پروتکل‌های سطح بالاتر به‌کار رفت: در درجه‌ی اول TCP/IP و UDP/IP و سپس پروتکل‌های کاربردی مثل DNS (یک نوع دفتر تلفن سلسله‌مراتبی)، FTP (انتقال فایل بهینه) و SMTP (ایمیل) برای برطرف کردن نیازهای مشخص ساخته شدند.

سیستم نام دامنه‌

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

بااین‌حال، خیلی زود مشخص شد به‌روزرسانی دستی این دفترچه‌های تلفنی (کاملا توزیع‌شده) آزاردهنده، غیربهینه و پر از خطا است. مرکز اطلاعات شبکه‌ی مؤسسه‌ی پژوهشی استانفورد (NIC) بین دسامبر ۱۹۷۳ و مارس ۱۹۷۴ به‌عنوان منبع رسمی فایل‌های هاست اصلی درنظر گرفته شد. امروزه وجود چنین سیستم توزیع‌شده‌ای کمی عجیب است (باوجود نگرانی‌های مربوط به نقطه‌ی مستقل خطاها و پروتکل‌های یکپارچه)؛ اما SRI تقریبا به‌مدت یک دهه خدمات خوبی را به اینترنت ارائه داد.

زندگی در آن زمان، بسیار ساده بود: برای ارسال یک ایمیل UUCP به کاربری به‌نام giacomo که در سروری به‌نام tesio کار می‌کرد، فقط کافی بود مسیر سرور خود را با آدرس‌هایی مثلaserver!anotherserver!yetanotherserver!tesio!giacomo انتخاب کنید. در این عبارت aserver!anotherserver!yetanotherserver!tesio توالی مرتبی از سرورها برای اتصال و انتقال پیغام بود.

با رشد شبکه بین مارس و اکتبر ۱۹۸۲، سیستم نام دامنه‌ی مدرن طراحی شد و خیلی زود در سراسر دنیا توسعه یافت. اسامی هاستی که امروزه برای ایمیل، مرور وب، به‌روزرسانی‌های نرم‌افزاری و بسیاری از کارهای ضروری به‌کار می‌برید، در همین بازه‌ی زمانی متولد شدند. در این اثنا، ARPANETهنوز هم تحت کنترل ارتش ایالات متحده قرار داشت.

محدوده‌ی DNS Root

قدمت صفحه‌ی ویکی‌پدیا در DNS Root به ۱ آگوست ۲۰۰۳ بازمی‌گردد. این بخش به‌مدت دو سال عنوانی به‌نام اصول محدوده‌ی DNS root داشت اما در ژوئن ۲۰۰۵ حذف شد. مؤلف صفحه‌ی اصلی این صفحه این ویژگی را یک موضوع بسیار جذاب می‌دانست اما برای نوشتن در مورد آن تردید داشت. این بخش کاملا پیچیده است و نوشتن در مورد آن بدون دسته‌بندی منابع اصلی دشوار است؛ بنابراین به‌سختی می‌توان آن را با یک دیدگاه بی‌طرفانه نقد کرد. ویکی‌پدیا در این باره نوشته است:

سرورهای DNS برای عملکرد اینترنت ضروری هستند. این سرورها، ایستگاه‌های بالقوه‌ی خطا برای کل اینترنت هستند. به همین دلیل تعداد زیادی از سرورهای root در سراسر دنیا توزیع شده‌اند. نکته‌ی جالب اینجاست که از میان سیزده DNS Root ، ده Root تحت مدیریت سازمان‌های آمریکایی قرار داشتند. Root zone توسط Verisign توزیع شده بود که مدیریت مستقیم a.root-server.net و j.root-server.net را برعهده داشت (هر دو وب‌سایت با مجوز منقضی SSL روی HTTPS قرار گرفته‌اند). مسلما برای کاهش خطر حملات DDoS، این سرورها نباید فیزیکی باشند؛ اما کلاستر سرورها از طریق آدرس‌دهی انی‌کست (همه‌پخشی) در سراسر جهان توزیع شدند.

از تاریخ ۳۰.۷.۲۰۱۸، سیستم root server شامل ۹۳۱ نماینده است که توسط ۱۲ اپراتور مستقل root server اداره می‌شوند

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

سرورهای Root تحت مدیریت سازمان‌های ژاپنی (چپ)، اروپا (مرکز) و ایالات متحده‌ی آمریکا (راست)

در اینجا Great Firewall یا دیوار آتش بزرگ، معنای کاملا متفاوتی را به‌خود می‌گیرد. از ۹۳۱ سرور روت، ۸۱۰ سرور تحت کنترل ایالات متحده هستند. ازنظر تئوری، ایالات متحده می‌تواند ارزان‌ترین Ddos تاریخ را بر اساس قانون انکار موجه (plausible deniability) ایجاد کند؛ به‌موجب این قانون که در دهه‌ی ۱۹۶۰ توسط سازمان سیا به‌‌کار برده شد، این سازمان از ارائه‌ی برخی اطلاعات به مقامات (مثلا رئیس جمهور) درباره‌ی برخی فعالیت‌های بدنام خود، خودداری می‌کرد. برای شبیه‌سازی حمله‌ی موفق DDoS می‌توان سرورها را در یک منطقه خاموش کرد تا کل DNS Rootهای دیگر تحت ترافیک قانونی از هم بپاشند.

ورود به وب

در مارس ۱۹۸۹، جوانی به‌نام تیم برنرز لی، طرح یک پیشنهاد برای سیستم مدیریت اطلاعاتی را به رئیس خود مایکل سندال می‌دهد. «مبهم ولی هیجان‌انگیز»، کلماتی که سندال روی طرح پیشنهادی او نوشت و به برنرز لی اجازه داد کار خود را ادامه دهد. دو سال بعد، اولین مرورگر و اولین سرور وب ساخته شدند. URI (شناسه‌ی منبع جهانی)، HTML (زبان نشانه‌گذاری ابَرمتن) و HTTP (پروتکل انتقال ابرمتن)، تنها راه‌حل‌های موجود برای مشکلات آن زمان نبودند؛ اما توانستند تا اندازه‌ای در رقابت بین پروتکل‌ها برنده شوند و در سطح گسترده‌ای تطبیق داده شوند.

تا معرفی SSL در ۱۹۹۴ توسط Netscape Navigator، هیچ راهی برای احراز هویت یک سرور HTTP یا انتقال محرمانه‌ی داده‌ها وجود نداشت؛ اما این مسئله مشکل‌ساز نبود زیرا HyperTextها یا ابرمتن‌ها بیشتر واسطه‌های فرهنگی بودند تا محیط‌هایی برای بازار و کسب‌وکار. با وجود بعضی نواقص فنی، این پروتکل و زبان بسیار ساده بودند و موفقیت آن‌ها به‌قدری وسیع بود که مرورگرهای زیادی توسعه یافتند.

سیر زمانی مرورگرهای وب

جنگ مرورگرها

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

با وجود تمام این رقابت‌ها در اواخر سال ۲۰۰۴ تنها یک مرورگر مستقل توانست برنده شود. این مرورگر اینترنت اکسپلورر ۶ بود که ۹۲ درصد از وب را تحت پوشش خود قرار داد. در آن زمان فناوری‌هایی مثل XHTML، CSS، XSLT، XSD، Atom و RSS در عرضه‌ی توسعه‌ی وب رونق پیدا کرده بودند. ایده‌ی XHTML توزیع آسان محتوای وب ماشینی بود به‌طوری‌که برای انسان هم به‌راحتی قابل‌نوشتن باشد. با ورود CSS و XSL، جداسازی کامل نمایش و محتوا در نیمه‌ی راه خود قرار گرفت. با XSL-FO امکان استخراج محتوا از صفحات وب و تولید گزارش‌های PDF از آن‌ها فراهم شد.

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

HTML5

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

با ظهور HTML5 کاربرد جاوا اسکریپت شکل جدی‌تری به خود گرفت

جاوا اسکریپت در سال ۱۹۹۵ توسط برندن ایچ اختراع شد. جاوا اسکریپت تقریبا به‌مدت ده سال وظیفه‌ی خود را به‌خوبی انجام داد و یک زبان کوچک و ابزاری برای انتقال تصاویر روی صفحات وب، ارزیابی اولیه‌ی فرم و چند وظیفه‌ی کوچک دیگر در رابطه با DOM بود. در آن زمان، مرور وب با غیرفعال‌سازی جاوا اسکریپت هم رایج بود و هر توسعه‌دهنده‌ی حرفه‌ای وب به تست وب‌سایت‌ها برای جاوا اسکریپت هم می‌پرداخت و از آن زمان تلاش‌های زیادی برای قابل‌دسترس ساختن وب انجام شد.

اما ناگهان در سال ۲۰۰۴، اپل، موزیلا و اپرا با XHTML تمایل خود به W3C و عدم تمایل به HTML را نشان دادند و حتی به نیازهای توسعه‌دهندگان وب بی‌اعتنایی کردند. آن‌ها برای حل مشکل WHATWG (مخفف گروه کاری فناوری برنامه‌ی ابرمتن وب) را ساختند. WHATWG انجمنی متشکل از افراد علاقه‌مند به HTML و فناوری‌های مرتبط با آن بود. به این صورت توانستند ۸ درصد وب را پوشش دهند. آن‌ها مفهوم Living Standards را معرفی کردند. Living Standards شامل مستنداتی است که ازنظر طراحی ناپایدارند و کسی نمی‌تواند به‌طور کامل آن‌ها را به‌روزرسانی کند.

این گروه در سال ۲۰۰۷، W3C را قانع کردند تا برای نسخه‌ی فعلی پیش‌نویس‌های ناپایدار و همان چیزی که امروزه به‌نام HTML5 شناخته می‌شود، بازاریابی کنند. HTML5 ربطی به HTML نداشت و بیشتر مربوط به جاوا اسکریپت بود. تا HTML4 وب یک ابرمتن (HyperText) بود. پروتکل و زبان‌های نشانه‌گذاری، عملکرد شفافی داشتند. هدف HTML4، ارائه‌ی متن‌های مرتبط به مردم بود؛ مثل یک کتابخانه‌ی عمومی با تعداد زیادی مرجع میانی. با ظهور HTML5، وب به پلتفرمی برای پیاده‌سازی و توزیع نرم‌افزار تبدیل شد. تغییرات مثبت در زبان نشانه‌گذاری بسیار کم بودند. تنها تغییر قابل‌توجه، منسوخ شدن XHTML بود و حتی بسیاری در این مورد متعجب شدند.

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

و در نهایت جاوا اسکریپت به یک سلاح تبدیل شد...

کنارگذاشته‌شدن XHTML توسط W3C در سال ۲۰۰۷ تعجب بسیاری را برانگیخت. بسیاری از افراد، زیرساخت‌های خود را بر اساس XML/XHTML ساخته بودند. جاوا اسکریپت در HTML4 مشکلاتی داشت؛ اما در کل یک مورد جدی محسوب نمی‌شد. با ظهور HTML5، تعداد زیادی از مشکلات امنیتی آن آشکار شد.

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

یک سلاح دقیق

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

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

ورود به WebAssembly

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

جاوا اسکریپت حتی به‌عنوان یک سلاح هم مشکلات زیادی دارد! اگر کد جاوا اسکریپت نفوذی را به یک کاربر ارسال کنید احتمال دستگیر شدن شما پایین است؛ اما ارسال آن به هکرها و توسعه‌دهندگان وب این احتمال را بالا می‌برد. اینجاست که به یک فرمت دودویی نیاز خواهید داشت که هیچ انسانی قادر به خواندن آن نباشد! و تنها چیزی که باید حذف کنید، دکمه‌ی View Source است.

مقاله‌های مرتبط:

• فایرفاکس به جدیدترین پروتکل امنیتی اینترنت تجهیز شد
• تفاوت HTTP و HTTPS به زبان ساده

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

ردیابی پیش‌فرض داد‌ه‌های کاربر، مشکل رایج حریم خصوصی

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

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

مقاله‌های مرتبط:

• انتقاد از گوگل به دلیل جمع آوری اطلاعات مکانی کاربران
• هرآنچه گوگل و فیسبوک در مورد شما می‌دانند

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

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

اغلب سرویس‌های ردیابی اطلاعات، به‌صورت پیش‌فرض فعال هستند

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

مجله‌ی کسب‌وکار هاروارد در سال ۲۰۰۸ تحقیقی منتشر کرد که به‌صورت مستقیم به فعال‌سازی پیش‌فرض‌ها و جمع‌آوری اطلاعات کاربران پرداخت. در این مقاله به نمایش گزارش‌های خرید کاربران در فیسبوک در سال ۲۰۰۷ اشاره شده بود. مولفان آن مقاله به این نکته اشاره داشتند که تمامی اطلاعات در مورد رفتارهای مشتریان، برای همه‌ی دوستان آنها قابل مشاهده است؛ مگر این که خودشان از این بخش برنامه خارج شوند.

کاربران عموما تغییری در تنظیمات پیش‌فرض سیستم‌ها ایجاد نمی‌کنند

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

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

نتفلیکس بخش نقد کاربران را از وب‌سایت حذف کرد

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

در صفحه‌ی Help وب‌سایت این شرکت آمده است:

کاربران نت‌فلیکس تا اواسط سال ۲۰۱۸ می‌توانستند نقدهایشان را در وب‌سایت Netflix.com منتشر کنند؛ از آن زمان به بعد، به‌علت کاهش استقبال از نقدهای کاربران، این بخش از سایت حذف شد. 

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

مقاله‌های مرتبط:

• داستان برند: نتفلیکس؛ انقلابیِ بی‌رحم دنیای رسانه
• نتفلیکس چگونه پول در می‌آورد؟

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

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

جالب است بدانید که نقدهای کاربران، تنها از طریق وب‌سایت نت‌فلیکس در دسترس بودند و هرگز در اپلیکیشن‌های رسمی این شرکت دیده نشدند. نت‌فلیکس به کاربرانش امکان می‌داد که در صفحه‌ی فیلم‌ها و سریال‌ها، نقدی با حداقل ۸۰ و حداکثر ۱۹۹۹ کاراکتر بنویسند و نمره‌ی نهایی آن را با سیستم پنج‌ستاره اعلام کنند.

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