چگونه اطلاعات ویکی پدیا را استخراج و تحلیل کنیم؟

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

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

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

• تولید مقاله برای ویکیپدیا به کمک هوش مصنوعی
• ۱۷ حقیقت جالب در خصوص ویکی‌پدیا
• پلتفرم صوتی ویکیپدیا تا سال ۲۰۱۷ عرضه می‌شود

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

در آموزش زیر، روی ابزار Mixnode تمرکز می‌کنیم که استخراج و تحلیل داده‌ها از ویکی‌پدیا با استفاده از کوئری‌های SQL را فراهم می‌آورد. برای استفاده از این ابزار باید با SQL آشنا باشید.

Mixnode چگونه کار می‌کند؟

Mixnode اجازه می‌دهد با وب مانند پایگاه داده برخورد کنید. با استفاده از Mixnode می‌توانید کوئری بنویسید و آن را روی وب اجرا کنید. با اجرای کوئری مدنظر Mixnode به‌طور خودکار صفحات لازم برای پاسخ به کوئری را پیدا می‌کند.

مثال‌های زیر نحوه‌ی کارکرد Mixnode و استخراج و تحلیل داده‌‌ها را شفاف‌تر می‌کند.

مثال ۱: به‌دست‌آوردن آدرس تمامی صفحات ویکی‌پدیا

select 
    url
from 
    pages
where 
    url_domain = 'wikipedia.org' 

• متغیر url نمایانگر آدرس صفحه است
• pages جدولی است که هر ردیف آن مطابق با صفحه‌ی منحصربه‌فرد در وب است
• با url_domain = 'wikipedia.org' مطمئن می‌شویم که فقط صفحات ویکی‌پدیا و ساب‌دامین‌های آن (مانند en.wikipedia.org) مدنظر قرار می‌گیرند. اگر بخواهید فقط در ویکی‌پدیای فارسی جست‌وجو کنید، کافی است عبارت fa.wikipedia.org را جایگزین کنید.

مثال ۲: به‌دست‌آوردن آدرس و عنوان تمامی مقالات ویکی‌پدیا

select 
    url, 
    css_text_first(content, 'h1#firstHeading') as title
from 
    pages
where 
    url_domain = 'wikipedia.org' 
    and
    url like '%/wiki/%'

• css_text_first(content, 'h1#firstHeading') عنوان مقاله‌ی ویکی‌پدیا را خروجی می‌دهد. با نگاهی به سورس HTML مقالات ویکی‌پدیا، پی می‌بریم h1#firstHeading مسیر CSS برای عنوان مقاله است. css_text_first نیز تابعی است که اجازه‌ی استخراج اولین مورد از انتخابگر CSS را می‌دهد. content در اینجا سورس کامل HTML صفحه است.

• ازآنجایی‌که قصد داریم عناوین مقالات را به‌دست آوریم و می‌دانیم در آدرس مقالات ویکی‌پدیا از /wiki/ استفاده می‌شود، از url like '%/wiki/%' استفاده می‌کنیم تا مطمئن شویم نتایجمان فقط به مقالات مربوط‌ می‌شود.

مثال ۳: به‌دست‌آوردن عناوین تمامی مقالات شامل زیررشته‌ی Elon Musk

select 
    url, 
    css_text_first(content, 'h1#firstHeading') as title
from 
    pages
where 
    url_domain = 'wikipedia.org' 
    and
    url like '%/wiki/%'
    and
    contains(content, 'Elon Musk')

• contains() تابعی است که اجازه‌ی بررسی وجود یک زیررشته در یک رشته را می‌دهد. با استفاده از contains(content, 'elon musk') مطمئن می‌شویم که در نتایجمان عبارت Elon Musk موجود است.

مثال ۴: مرتب‌سازی مقالات ویکی‌پدیا براساس تعداد ارجاعات

select 
    url, 
    css_text_first(content, 'h1#firstHeading') as title,
    cardinality(css_text(content, 'ol.references li')) as reference_count
from 
    pages
where 
    url_domain = 'wikipedia.org' 
    and
    url like '%/wiki/%'
order by reference_count desc

• بررسی کد منبع یک مقاله‌ی ویکی‌پدیا نشان می‌دهد تمامی ارجاعات و منابع با انتخابگر ol.references قابل‌دسترسی است. css_text(content, 'ol.references li') متن تمامی منابع مقاله را به ما می‌دهد و ازآنجایی‌که فقط به تعداد نیاز داریم، پس از تابع cardinality() استفاده می‌کنیم که اندازه‌ی یک آرایه را برمی‌گرداند. desc در خط آخر مقالات را به‌صورت نزولی برایمان مرتب می‌کند. برای مرتب‌سازی به‌صورت صعودی از asc استفاده کنید.

مثال ۵: مرتب‌سازی مقالات ویکی‌پدیا براساس طول مقاله

select
    url,
    css_text_first(content, 'h1#firstHeading') as title,
    cardinality(words(css_text_first(content, '#content'))) as article_length
from 
    pages
where 
    url_domain = 'wikipedia.org' 
    and
    url like '%/wiki/%'
order by article_length desc

• words() آرایه‌ای شامل تمامی کلمات یک متن را برمی‌گرداند. استفاده از cardinality(words(css_text_first(content, '#content'))) as article_length، تعداد کلمات یک مقاله را به ما می‌دهد.

مثال ۶: اندازه‌ی میانگین یک مقاله‌ی ویکی‌پدیا

select
    avg(cardinality(words(css_text_first(content, '#content')))) as average_article_length
from 
    pages
where 
    url_domain = 'wikipedia.org' 
    and
    url like '%/wiki/%'

• تابع avg() میانگین داده‌های ورودی‌اش را برمی‌گرداند که در اینجا، تعداد کلمات تمامی مقالات ویکی‌پدیاست.

مثال ۷: مرتب‌سازی مقالات ویکی‌پدیا براساس بحث‌های آن

select
    url,
    remove_left(css_text_first(content, 'h1#firstHeading'), 'Talk:') as title,
    cardinality(words(css_text_first(content, '#content'))) as discussion_length
from 
    pages
where 
    url_domain = 'wikipedia.org' 
    and
    url like '%/wiki/Talk:%'
order by discussion_length desc

• مباحث درباره‌ی یک مطلب در آدرسی مشابه /wiki/Talk: قرار دارند؛ به‌همین‌دلیل از این عبارت استفاده می‌کنیم.

مثال ۸: پیداکردن تمامی مقالات ویکی‌پدیا که لینکی به zoomit.ir دارند

select
    url,
    css_text_first(content, 'h1#firstHeading') as title
from 
    pages
where 
    url_domain = 'wikipedia.org' 
    and
    url like '%/wiki/%'
    and
    contains_any(content, array['href="https://www.zoomit.ir', 'href="http://www.zoomit.ir', 'href="https://zoomit.ir', 'href="http://zoomit.ir'])

دیدگاه شما چیست؟ تجربه‌ی استفاده از این ابزار را داشته‌اید؟ ابزارهای دیگری برای تحلیل و استخراج داده‌ها از ویکی‌پدیا می‌شناسید؟ نظرات خود را با ما و کاربران زومیت به‌اشتراک بگذارید.

معرفی ۲۷ مورد برای افزایش بازدید وب سایتتان

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

 

۲-با تبدیل محتوا پست جدیدی داشته باشید (یکی یا چند پست را به یک ایبوک تبدیل کنید)

ایبوک

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

۳-با پادکست محتوای سایت تان را تکمیل کنید

پادکست

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

۴-آسمان خدشه (skyscraper) بسازید

آسمان خراش

سعی کنید درمورد یک سوژه که چند کلیدواژه مهم را بهمراه دارد کامل تر از مطالب سایت های رقیب بنویسید طوری که اگر کاربر به سایت شما راز میزند و مطلب طولانی و کامل شمارا میخواند ا دیگر منظور مطالعه مطلب دیگری به سرش نزند. اصطلاحا به مطالب طولانی مطالب آسمان خراش(sky scraper) گفته می شود که تاثیر احسان در افزایش بازدید سایت و سئو دارد.

۵-استفاده از دکمه های به اشتراک گذاری مطلب

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

۶- CTR صفحات را افزایش دهید

افزایش نرخ کلیک

احتمالا مطالب و صفحات بسیاری در سایت شما هستند که ورودی خوبی از گوگل ندارند چون با کلیدواژه های پیوسته در آن مطلب در نتایج گوگل نیستند گرد از مهم ترین دلایل عدم به کارگیری عناوین جذاب و مرتبط در متای عنوان می باشد پیش از اینکه کاربر با سایت شما آشنا شود کلیدواژه خود را در گوگل جستجو میکند و این برای کاربران و گوگل مهم است که عناوین شما جذاب باشد. در تصویر با سرچ “ریتارگتینگ چیست” مدیااد لینک ۱ گوگل میباشد و یگانه از دلایل آن به کارگیری متای جذاب است.

ریتارگتینگ چیست

۷-ویدئو مارکتینگ را جدی بگیرید!

ویدئو مارکتینگ

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

تلاش‌های Archive.org برای تهیه آرشیو از گوگل پلاس ادامه دارد

گوگل قرار است از ابتدای آوریل پیش‌رو، حذف داده‌های مربوط‌به شبکه‌ی اجتماعی مهجورمانده‌ی خود یعنی گوگل پلاس (+Google) را آغاز کند. از همین رو، سایت‌های Internet Archive وArchiveTeam اعلام کرده‌اند که در تلاش هستند تا مطالبی را که کاربران این پلتفرم به‌صورت عمومی منتشر کرده‌اند، در سایت Archive.org ذخیره و حفظ کنند.

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

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

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

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

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

گوگل پلاس رسما به‌تاریخ پیوست؛ بررسی دلایل شکست پروژه‌ای بزرگ

گوگل‌پلاس (+Google) به‌عنوان سرویسی نوآور در سال ۲۰۱۱ با وعده‌هایی هیجان‌انگیز برای رقابت با غول‌هایی نظیر فیسبوک و توییتر معرفی شد. درواقع، این سرویس چهارمین تلاش گوگل برای موفقیت در حوزه‌ی شبکه‌های اجتماعی بود.

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

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

گوگل‌پلاس چه‌ سرویسی بود؟

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

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

گوگل‌پلاس از همان ابتدا برای شکست‌خوردن ساخته‌ شده بود

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

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

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

مشکل از کجا شروع شد؟

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

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

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

گوگل‌پلاس در ابتدا سیاست سخت‌گیرانه‌ای برای نام کاربرانش داشت

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

درحالی‌که مردم قبلا در شبکه‌های اجتماعی نظیر فیسبوک با مفهومی همچون «لایک» و در توییتر با مفهوم «توییت‌های محبوب» مواجه شده بودند، در گوگل‌پلاس به گزینه‌ای به‌نام «پلاس وان» (Plus One) برمی‌خوردند. درواقع، داستان از این قرار بود که «اگر از پستی خوشتان می‌آمد، باید آن را پلاس وان می‌کردید».

تدابیر گوگل چه بود؟

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

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

آنان مدعی بودند گوگل از موفقیت آن‌ها برای محبوب‌ترکردن گوگل‌پلاس سوء‌استفاده می‌کند. اِما بلکری یوتیوبری بود که آهنگ جالبی در‌این‌زمینه نوشت که ویدئو مربوط‌به آن شدیدا فراگیر شد. 

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

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

یکی از دلایل مهم‌ فعال‌شدن جامعه‌ی کاربری این بود که دیدگاه‌های پای ویدئوهای یوتیوب و ویدئوهای پسندیده‌شده و نیز بررسی‌های نوشته‌شده در پلی‌استور، به‌طور خودکار در گوگل‌پلاس هم منتشر می‌شدند. گوگل در اطلاعیه‌ای اعلام کرد شمار کاربران این سرویس مرز ۵۰۰ میلیون نفر را رد کرده است؛ اما سؤالی که خیلی‌ها از خود پرسیدند، این بود: «از این تعداد چند نفر واقعا در این سرویس به‌طور منظم فعال هستند و با آن تعامل می‌کنند؟»

روری سلان‌جونز، خبرنگار بی‌بی‌سی، در سال ۲۰۱۱ درباره‌ی گوگل‌پلاس نوشته است:

به پروفایل افرادی سر زدم که برای عضویت در گوگل‌پلاس دعوتشان کرده بودم و متوجه اتفاق جالبی شدم. میزان حضور آن‌ها در دنیای درخشان جدید گوگل خیلی کم بود؛ تاحدی‌که بعضی از آن‌ها اصلا در این سرویس حضور نداشتند. سؤال مهم اینجا است: ۷۵۰ میلیون نفری که در فیسبوک ثبت‌نام کرده‌اند یا ۱۰۰ میلیون نفری که به‌گفته‌ی توییتر در این سرویس حضور دارند، به استفاده از سرویس دیگری نیاز پیدا می‌کنند؟

دلیل تعطیلی گوگل‌پلاس چه بود؟

در آوریل‌۲۰۱۴ و به‌دنبال جدایی مؤسس گوگل‌پلاس از گوگل، بُروز تغییراتی جدی در این سرویس را شاهد بودیم؛ تغییراتی که با سرعت سریعی رخ دادند. برای مثال، ویژگی‌های موفقی همچون Hangouts و Photos به‌صورت رسمی از گوگل‌پلاس جدا شدند و به‌عنوان سرویس‌هایی مستقل شروع‌به‌کار کردند. 

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

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

هم‌اکنون کاربران کمی از گوگل‌پلاس استفاده می‌کنند و با آن تعامل دارند؛ ۹۰ درصد از دوره‌های زمانی صرف‌شده‌ی کاربران در گوگل‌پلاس، به کمتر ۵ ثانیه می‌رسد.

جالب است بدانید گوگل دو وب‌سایت با نام‌های Google Graveyard و Google Cemetery دارد که در آن‌ها، توضیحاتی درباره‌ی سرویس‌های شکست‌خورده‌اش می‌دهد. نام گوگل‌پلاس اکنون در این وب‌سایت‌ها به‌‌عنوان پروژه‌ای شکست‌خورده به‌چشم می‌‌خورد. 

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

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

• HTTP2 چیست و چگونه بر آینده‌ اینترنت تأثیر می‌گذارد؟
• تفاوت HTTP و HTTPS به زبان ساده
• چرا HTTPS بهتر و ایمن‌ تر از HTTP است

استفاده‌ی گسترده از پروتکل امنیتی HTTPS موجب شده قفل‌های سبزرنگ را در بسیاری از وب‌سایت‌ها در سرتاسر جهان شاهد باشیم. بسیاری از وب‌سایت‌های پربازدیدی که روزانه به آن‌ها سر می‌زنید، مانند زومیت، از پروتکلی به‌نام پروتکل امنیتی لایه‌ی انتقال (Transport Layer Security) یا به‌اختصار TLS بهره می‌برند. این پروتکل داده‌های مبادله‌شده میان مرورگر و سِرور را رمزنگاری می‌کند تا از دید افراد دیگر مخفی بماند؛ اما جدیدترین یافته‌های محققان دانشگاه کافوسکاری ونیز در ایتالیا و دانشگاه تکنیکال وین در اتریش نشان داده که تعداد درخورتوجهی از وب‌سایت‌های رمزنگاری‌شده همچنان درمعرض خطر هستند.

در تحلیل ۱۰,۰۰۰ وب‌سایت اول بهره‌مند از این پروتکل براساس شرکت تحلیل الکسا که به آمازونتعلق دارد، ۵۵۰ وب‌سایت (۵.۵ درصد) آسیب‌پذیری‌های جدی مربوط‌به TLS داشتند. این مشکلات ناشی از نحوه‌ی اجرای TLS و باگ‌های شناخته‌شده‌ی این پروتکل و نسل قبل آن (Secure Socket Layer (SSL است. باوجوداین، بدترین قسمت ماجرا آن است که در این وب‌سایت‌ها همچنان قفل سبزرنگ نمایان می‌شود.

ریکاردو فوکاردی، محقق امنیت شبکه و رمزنگاری در دانشگاه کافوسکاری ونیز می‌گوید:

ما چیزهایی یافته‌ایم که مرورگر نیز شناسایی نمی‌کند. ما به‌دنبال مشکلاتی از TLS هستیم که تاکنون به آن‌ها اشاره‌ای نشده‌ است.

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

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

از میان ۱۰,۰۰۰ وب‌سایت برتر، ۵۵۰ وب‌سایت دچار آسیب‌پذیری TLS اند

مشکلات در دو دسته‌ی دیگر بسیار جدی‌تر هستند. دسته‌ی دوم می‌تواند به دسترسی مهاجم به تمام اطلاعات و رمزگشایی تمام ترافیک میان مرورگر و سِرور منجر شود. بدتر از همه، وضعیت دسته‌ی سوم است که به مهاجم نه‌تنها اجازه‌ی رمزگشایی تمام ترافیک، بلکه اجازه‌ی تغییر آن را نیز می‌دهد. نکته‌ی طعنه‌آمیز اینجا است که پروتکل HTTPS از ابتدا برای مقابله با این‌ نوع حملات طراحی شده که به «حملات مرد میانی» (Man-in-the-Middle) موسوم‌اند.

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

محققان می‌گویند یکی از فرضیات آنان دراین‌زمینه آن است که مشکلات ریزامنیتی TLS در صفحه‌ی وب می‌تواند بسیاری از صفحات دیگر را نیز تهدید کند. برای مثال، فرض کنید صفحه‌ی اصلی Example.com بدون مشکل و TLS داشته باشد؛ اما mail.example.com آسیب‌پذیری‌های TLS داشته باشد. باتوجه‌به ارتباط این دو، تمامی ارتباطات مطمئن این دو هم تضعیف می‌شود؛ بدین‌ترتیب، آسیب‌پذیری کوچکی به‌واسطه‌ی لینک‌ها و ارتباط‌ها تقویت می‌شود.

نفوذپذیری‌ها به مهاجمان اجازه‌ی رمزگشایی تمام داده‌ها و حتی تغییر آن‌ها را می‌دهد

در فضای امروزی وب، بسیاری از وب‌سایت‌ها به یکدیگر وابسته هستند و ارتباطات میان وب‌سایت‌ها و وب‌سرویس‌ها بسیار زیاد است. برای درک این موضوع کافی است بدانید در آن جمعیت ۵.۵ درصدی از ۱۰,۰۰۰ وب‌سایت برتر که آسیب‌پذیر تشخیص داده شدند، ۲۹۲ وب‌سایت تحت‌تأثیر مستقیم باگ TLS و ۵,۲۸۲ درمعرض آسیب‌پذیری ناشی‌ از سایر ‌وب‌سایت‌ها قرار داشتند. از این تعداد، بیش از ۴,۸۰۰ وب‌سایت در دسته‌ی سوم (خطرناک‌ترین) و ۷۳۳ وب‌سایت در دسته‌ی دوم و ۹۱۲ وب‌سای در دسته‌ی اول (کمترین خطر) قرار می‌گیرند.

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

نظر مترجم

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