شما یک دیجیتال مارکتر هستید و می‌خواهید ترافیک یک اپلیکیشن را به درستی آنالیز کنید. برای این کار به یک پلتفرم اتریبیوشن یا استفاده از یک ترکر نیاز دارید. اما کدام ترکر را باید انتخاب کنید؟ پلتفرمی که کدهای منبع خود را در SDk باز و در دسترس عموم توسعه‌دهندگان قرار داده است یا پلتفرمی که دسترسی سفت و سختی برای SDK خود در نظر گرفته است؟ انتخاب هر کدام از این دو مسیر چه مزایا و معایبی دارد؟ توصیه متریکس به عنوان یک پلتفرم اتریبیوشن با رویکرد closed-source SDK چیست؟

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

منظور از Open-source SDK چیست؟

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

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

مزایای استفاده از Open-source SDK

حالا که open-source SDK انتخاب بسیاری از پلتفرم‌های اتریبیوشن است در ادامه به فواید این نوع از کیت‌ها می‌پردازیم:

شفافیت

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

تضمین کیفیت

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

قابلیت سفارشی‌سازی

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

فراگیری و محبوبیت

درحال حاضر، هر نرم‌افزاری در هر سطحی می‌تواند اپن سورس باشد و از آنجایی که به یک روند (trend) هم تبدیل شده است بسیاری از شرکت‌ها سعی می‌کنند به هر طریقی که می‌توانند به صورت open-source یکپارچه‌سازی را انجام دهند.

حال که با مزایای SDK های اپن سورس آشنا شدید، لازم است از زاویه دیگری نیز به آنها نگاهی بیندازیم:

معایب استفاده از Open-source SDK

در معرض خطر است

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

در واقع بازِ باز نیست!

آن دسته از پلتفرم‌های اتریبیوشن که ادعای open source بودن SDK خود را دارند باز هم کاملاً متن باز عمل نمی کنند، این یعنی کامیونیتی دولوپرها می توانند آن را ببینند اما نمی توانند آن را بهبود بخشند. داشتن یک open source SDK که دولوپرهای خارجی واقعاً نمی توانند در آن سهیم باشند به نوعی هدف کلی متن باز بودن آن را به هم می‌ریزد. در صورتی که یک SDK به لحاظ فنی باز است اما در برابر تغییرات یا ویرایش‌های مورد نیاز باز نیست؛ بنابراین از یکی از عناصر اصلی یک کد open-source محروم است. شرکت ادجاست (adjust) به عنوان یکی از پلتفرم‌های ارائه دهنده خدمات اتریبیوشن از همین دسته شرکت‌ها است که به رغم ادعا مبنی بر باز بودن SDK کاملاً باز نیست.

همه می‌توانند کد را کنترل کنند

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

میزان حجم

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

اجازه دهید تمام موارد بالا را در چند نکته زیر خلاصه کنیم:

• اپن سورس بودن فرایند هک کردن را سریع‌تر و ارزان‌تر می‌سازد یعنی متخلفان دقیقاً می‌دانند داده‌ها چطور جمع آوری می‌شود و درون اس دی کی بسته بندی می‌شود، کاری که به مراتب پیدا کردن محل داده‌ها را آسان تر می‌کند، داده‌هایی که به آسانی قابلیت جعل شدن دارند و «تقلب با کیفیت» (quality fraud) را خلق می‌کنند.
• در راهکارهای اپن سورس، سازوکارهای رمزنگاریِ پیاده‌سازی شده در کد در معرض خطر هستند و می‌توانند خوانده شود یا به راحتی برگردانده شوند.
• وقتی با راهکارهای open-source سر و کار داشته باشید، مسئولیت امنیت نرم‌افزار عمدتاً به دوش مشتری می‌افتد. در صورتی که مشتری تمامی گام‌های لازم را برای تأمین امنیت کد منبع را طی نکند به لحاظ ماهوی درک، برگرداندن و دستکاری کدها آسان‌تر خواهد بود.

چرا یک کیت اختصاصی (Closed-source SDK) به هنگام مقابله با تقلب از نوع SDK Spoofing ضروری است؟

اجازه دهید به نحو دیگری این سؤال را مطرح کنیم: وقتی پای شناسایی تقلب موبایلی مطرح باشد چرا یک open-source SDK راه حل مناسبی نیست؟

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

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

باز بودن کد منبع یک SDK بیش و پیش از هرچیز، داده‌های تبلیغ دهندگان را در برابر جعل کیت (SDK Spoofing) بی دفاع می‌کند.

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

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

بخش قابل توجهی از بحث‌های پیرامون جعل SDK یا SDK Spoofing به عنوان یکی از انواع شایع تقلب موبایلی مربوط به حملات شبکه از نوع MITM یا Man In The Middle است. اجازه دهید توضیحات بیشتر در مورد این نوع حملات را به مقاله دیگری موکول کنیم و بحث را با این سؤال ادامه دهیم:

چطور بهترین SDK را انتخاب کنیم؟

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

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

تطبیق پذیری بالا

یکی از مهمترین نکاتی که لازم است شما به عنوان تبلیغ دهنده به هنگام انتخاب پلتفرم اتریبیوشن بررسی کنید تعداد شبکه‌های تبلیغاتی است که آن SDK با آنها در ارتباط است. شما قطعاً نمی‌خواهید با کیت اتریبیوشنی اینتگریت شوید که بعد متوجه شوید نمی‌تواند شما را با شبکه‌های تبلیغاتی که در آینده انتخاب خواهید کرد پیوند دهد. از آنجایی که شما نمی‌توانید همیشه پیشبینی کنید که دقیقاً قرار است با کدام شبکه تبلیغاتی در آینده کار کنید، بهترین کار این است که یک کیت اتریبیوشن تطبیق پذیر (adaptable) انتخاب کنید.

ثبات

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

حجم پایین

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

عملکرد تخصصی

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

لینک‌دهی عمیق

در دنیای کنونی اپلیکیشن‌های موبایل، برخورداری از قابلیت‌های لینک دهی عمیق دیگر یک فیچر لوکس نیست بلکه قابلیتی پایه‌ای است. دقت کنید که ابزارهای اتریبیوشن شما قابلیت رصد لینک‌های عمیق (Deep Links) را در کنار لینک‌های عادی داشته باشند.

[metrix_cta link=”https://docs.metrix.ir/” text_link=”SDK متریکس را پیاده‌سازی کنید” params=”utm=college&utm=google” title=”پلتفرم ایرانی آنالیز موبایل مارکتینگ” content=”چطور SDK متریکس را در نسخه‌های مختلف اپلیکیشن خود پیاده‌سازی کنید” image=”https://blog.metrix.ir/wp-content/uploads/2018/12/favicon.png”]

سخن آخر

مسئله تقلب را شوخی نگیرید!

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