Software Engineer Labdon
625 subscribers
43 photos
4 videos
2 files
804 links
👑 Software Labdon

حمایت مالی:
https://www.coffeete.ir/mrbardia72

ادمین:
@mrbardia72
Download Telegram
🔵 عنوان مقاله
Ad and PR Giant Dentsu Says Hackers Stole Merkle Data (3 minute read)

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

#حمله_سایبری #نفوذ_داده #امنیت_اطلاعات #نشت_اطلاعات #Dentsu #Merkle #تبلیغات_دیجیتال #حریم_خصوصی

🟣لینک مقاله:
https://www.securityweek.com/ad-and-pr-giant-dentsu-says-hackers-stole-merkle-data/?utm_source=tldrinfosec


👑 @software_Labdon
👍1
🔵 عنوان مقاله
Architecture Tests

🟢 خلاصه مقاله:
** تاراس Kizlo در ادامهٔ مجموعهٔ خود دربارهٔ سطوح تست، سراغ موضوع کمتر مطرح‌شده‌ای رفته است: تست‌های معماری. او توضیح می‌دهد که این تست‌ها مجموعه‌ای از قواعد اجرایی‌اند که مرزهای معماری، وابستگی‌های مجاز، نبود حلقه‌های وابستگی و قواعد نام‌گذاری/لایه‌بندی را بررسی می‌کنند تا از فرسایش تدریجی طراحی جلوگیری شود. مقاله نشان می‌دهد چگونه می‌توان این قواعد را کنار تست‌های معمول و در CI/CD اجرا کرد و با ابزارهایی مثل ArchUnit یا NetArchTest آن‌ها را به شکست‌پذیر کردن بیلد گره زد. توصیه‌های عملی شامل شروع از چند قانون پرتأثیر، پرهیز از قواعد شکننده، همگام‌سازی با تصمیم‌های معماری و به‌روزرسانی مداوم تست‌هاست. نتیجهٔ نهایی: تست‌های معماری قصد طراحی را به قراردادهای قابل اجرا تبدیل می‌کنند و به‌عنوان گاردریل‌های ماندگار، ساختار سالم کد را حفظ می‌کنند.

#ArchitectureTests #SoftwareArchitecture #SoftwareTesting #CleanArchitecture #CI/CD #ArchUnit #NetArchTest #CodeQuality

🟣لینک مقاله:
https://cur.at/WG4foAM?m=web


👑 @software_Labdon
به اون کاری که امروز کردی نگو "ریفکتور" (Refactor). اگه تست نداره، اون فقط یه "گندکاریِ تمیزه".
این فقط یه جمله‌ی قشنگ نیست؛ این یه زخمه که من هنوز یادمه.
اوایل کارم، میخواستم قهرمان باشم. ‍️ تو یه پروژه‌ی لگسی، یه "God Function" هزار خطی پیدا کردم و گفتم: "من اینو تمیز میکنم!"
نشستم و تیکه‌تیکه‌اش کردم. ۵۰ تا تابع کوچولوی تر و تمیز. اصل DRY رو پیاده کردم. ظاهر کد عالی شد. "تمیز" و "حرفه‌ای". احساس غرور میکردم.
مشکل چی بود؟ اون کد اصلی لعنتی، یه دونه هم تست خودکار نداشت.
اونجا بود که فاجعه اتفاق افتاد.  کاری که من انجام دادم، "ریفکتور" نبود؛ "تغییر دادنِ کورکورانه" بود.
اون کد "تمیز" من، چند تا باگ جدید و پنهان داشت. چرا؟ چون اون "کد اسپاگتی" زشت، پر از منطق‌های تجاری پنهان و وابستگی‌های زمانی بود که فقط تو همون حالت کار میکرد.
من "بدهی فنی" رو پرداخت نکردم؛ من یه بدهی کم‌بهره (مثل تکرار کد که فهمیدنش ساده بود) رو برداشتم و با یه بدهی پربهره (مثل یه "انتزاع اشتباه" که حالا دیباگ کردنش غیرممکنه) عوض کردم.
این "تله‌ی کد تمیز"ئه. مهم‌ترین تعریفی که تو این صنعت باید بلد باشیم مال مایکل فدرز (Michael Feathers) ئه: "کد لگسی، کدیه که تست نداره." همین.
تو یه سیستم لگسی، قانون اول "تمیز کن" نیست. قانون اول اینه: "اول امنش کن." برو "تست‌های مشخصه‌یابی" (Characterization Tests) بنویس تا رفتار فعلیِ سیستم (با همه‌ی باگ‌هاش) رو قفل کنی. وقتی اون تور ایمنی رو ساختی، اونوقت حق داری که شروع به تمیزکاری کنی.

<Hossein Moradi/>
1👍1
🔵 عنوان مقاله
Understanding Playwright Agents

🟢 خلاصه مقاله:
**عرضه اخیر Playwright Agents یک گام مهم در خودکارسازی آزمون‌های مرورگری است: به‌جای نوشتن تک‌تک گام‌ها، هدف را توصیف می‌کنید و عامل‌ها با برنامه‌ریزی، اجرا و پایش تکرارشونده، مسیر رسیدن به آن هدف را در مرورگرهای واقعی پیدا می‌کنند. این رویکرد با تکیه بر نقاط قوت Playwright—پوشش چندمرورگری، ابزارهای رهگیری و انتخاب‌گرهای پایدار—زمان ساخت تست را کاهش می‌دهد و نگه‌داری را آسان‌تر می‌کند. معماری هسته شامل سه بخش برنامه‌ریز، اجراکننده و ناظر است که با ترکیب منطق قطعی و استدلال مدل‌محور تلاش می‌کند هم انعطاف‌پذیر باشد و هم قابلیت بازپخش و مشاهده‌پذیری را حفظ کند. Sławomir Radzymiński در یک بررسی عمیق، نحوه کار داخلی این عامل‌ها، الگوی حلقه تصمیم‌گیری، ساخت مدل از DOM و مثال‌های عملی (ورود، پرداخت، و پایدارسازی سناریوهای شکننده) را توضیح می‌دهد و در کنار آن، محدودیت‌ها و بهترین‌روش‌ها را نیز بیان می‌کند: تعریف هدف شفاف، استفاده از data-testid پایدار، محدود کردن عمق اکتشاف، و پین‌کردن محیط در CI. مسیر پیشنهادی پذیرش نیز استفاده از Agent برای اکتشاف و تولید تست‌های اولیه و سپس تثبیت آن‌ها به اسکریپت‌های قطعی Playwright است.

#Playwright #PlaywrightAgents #E2ETesting #BrowserAutomation #TestAutomation #LLM #QA #DevTools

🟣لینک مقاله:
https://cur.at/NqUSz5D?m=web


👑 @software_Labdon
🔵 عنوان مقاله
Improved BRICKSTORM YARA Rules (GitHub Repo)

🟢 خلاصه مقاله:
به‌روزرسانی تازه‌ای از سوی Florian Roth بر پایه گزارش Google درباره بدافزار BRICKSTORM منتشر شده که مجموعه قوانین YARA را در یک مخزن GitHub به‌طور شفاف‌تر، سریع‌تر و قابل اتکاتر می‌کند. او با حذف regexهای غیرضروری، کاهش خطای مثبت و بهبود کارایی اسکن را هدف گرفته و با شفاف‌سازی encoding رشته‌ها و توالی‌های بایتی، از رفتار یکسان قوانین در حالت‌های مختلف اطمینان داده است. همچنین با ساده‌سازی و یکپارچه‌سازی قواعد، نگهداشت و فهم آن‌ها آسان‌تر شده است. افزوده‌شدن metadata شامل ارجاع به گزارش Google، اطلاعات نویسنده و نسخه، شفافیت و قابلیت پیگیری را افزایش می‌دهد و استقرار و بهبود مستمر قوانین را برای تیم‌های دفاعی ساده‌تر می‌کند.

#YARA #BRICKSTORM #MalwareDetection #ThreatIntel #Google #FlorianRoth #CyberSecurity #GitHub

🟣لینک مقاله:
https://github.com/Neo23x0/signature-base/blob/master/yara/apt_cn_brickstorm_sep25.yar?utm_source=tldrinfosec


👑 @software_Labdon
🔵 عنوان مقاله
Debugging Mobile Web Apps Shouldn't Be This Hard, So I Built a Logger

🟢 خلاصه مقاله:
به‌گفته‌ی Nishant Bhandari، دیباگ اپلیکیشن‌های وب موبایل بیش از حد دشوار شده است؛ ابزارهای دسکتاپ و ریموت همیشه شرایط واقعی دستگاه را نشان نمی‌دهند. او برای ساده‌سازی این روند، ابزار متن‌باز interactive-logger را معرفی می‌کند؛ ابزاری سبک که با افزودن یک قطعه کوچک، لاگ‌ها و خطاها را همان‌جا روی دستگاه و به‌صورت لحظه‌ای نمایش می‌دهد تا بازتولید و اشتراک‌گذاری باگ‌ها سریع‌تر و دقیق‌تر انجام شود. تمرکز این راهکار روی سادگی و کارکرد در سناریوهای رایج وب موبایل (مانند PWA و WebView) و بدون وابستگی به فریم‌ورک است.

#MobileWeb #Debugging #DevTools #OpenSource #Logging #WebDev #JavaScript #Frontend

🟣لینک مقاله:
https://cur.at/vp45Wp0?m=web


👑 @software_Labdon
🔵 عنوان مقاله
Google Sues to Disrupt Chinese SMS Phishing Triad (2 minute read)

🟢 خلاصه مقاله:
Google در دادگاه Southern District of New York علیه ۲۵ نفر مرتبط با ابزار چینی Lighthouse شکایت کرده است؛ ابزاری از نوع phishing-as-a-service که با پیامک‌های جعلی به نام USPS، اپراتورهای عوارض جاده‌ای، پلتفرم‌های تجارت الکترونیک و مؤسسات مالی، بیش از یک میلیون قربانی را در ۱۲۰ کشور هدف قرار داده است. این شبکه با هدایت کاربران به وب‌سایت‌های موبایلی جعلی، داده‌های کارت پرداخت را جمع‌آوری می‌کند و سپس با سوءاستفاده از فرایندهای ثبت‌نام قانونی Apple Pay و Google Pay، از طریق فریب کاربران برای ارائه کدهای یکبارمصرف، کارت‌های سرقت‌شده را به کیف‌پول‌های موبایلی متصل می‌سازد. هدف شکایت، مختل‌کردن زیرساخت این عملیات و بازدارندگی از الگوهای مشابه در مقیاس جهانی است.

#Cybersecurity #Phishing #SMSPhishing #Google #ApplePay #GooglePay #PhaaS #Fraud

🟣لینک مقاله:
https://krebsonsecurity.com/2025/11/google-sues-to-disrupt-chinese-sms-phishing-triad/?utm_source=tldrinfosec


👑 @software_Labdon
🔵 عنوان مقاله
Vulnerability in Dolby Decoder Can Allow Zero-Click Attacks (2 minute read)

🟢 خلاصه مقاله:
پژوهشگران Google's Project Zero یک آسیب‌پذیری ناشی از buffer overflow را در Dolby's Unified Decoder پیدا کرده‌اند؛ مولفه‌ای که در Android برای decode کردن محلی تمام پیام‌ها و پیوست‌های صوتی به‌کار می‌رود. این نقص می‌تواند به remote code execution منجر شود و به‌دلیل اجرای خودکار فرآیند decode در مسیر رسانه‌ای سیستم، امکان حملات zero-click را فراهم می‌کند؛ بدون اینکه کاربر کاری انجام دهد. از آنجا که بسیاری از اپ‌ها در Android برای پردازش‌های پس‌زمینه (مثل پیش‌نمایش یا استخراج اطلاعات صوتی) به همین decoder تکیه می‌کنند، سطح حمله گسترده است. توصیه می‌شود به‌محض انتشار، به‌روزرسانی‌های امنیتی Android و سازندگان دستگاه اعمال شود و از سخت‌سازی مسیرهای رسانه‌ای، sandboxing و شیوه‌های ایمن حافظه استفاده شود.

#Android #Security #Vulnerability #ZeroClick #RCE #Dolby #ProjectZero #Cybersecurity

🟣لینک مقاله:
https://www.securityweek.com/vulnerability-in-dolby-decoder-can-allow-zero-click-attacks/?utm_source=tldrinfosec


👑 @software_Labdon
🔵 عنوان مقاله
How I Automated Test Scope Analysis with a CLI Tool

🟢 خلاصه مقاله:
** Josphine Job روند ساخت یک ابزار CLI با Node.js را توضیح می‌دهد که با استفاده از GitHub API تغییرات کد را به‌سرعت تحلیل می‌کند و پیشنهادهای هوشمند برای محدودهٔ تست ارائه می‌دهد. این ابزار با دریافت اطلاعات PR و commitها، فایل‌های تغییرکرده را بررسی و وابستگی‌ها را تحلیل می‌کند و سپس با لایهٔ هوش مصنوعی، سناریوهای تست اولویت‌دار (از واحد تا یکپارچه) پیشنهاد می‌دهد. خروجی می‌تواند در ترمینال، به‌صورت Markdown/JSON، یا به‌عنوان کامنت CI روی PR نمایش داده شود. ملاحظاتی مانند کش‌کردن، رعایت حریم خصوصی، و fallback آفلاین در نظر گرفته شده و هدف، کوتاه‌کردن چرخهٔ بازخورد و افزایش پوشش و اعتماد به تغییرات کد است.

#TestAutomation #CLI #NodeJS #GitHubAPI #AIinTesting #DevTools #CICD #SoftwareQuality

🟣لینک مقاله:
https://cur.at/SDG4cgz?m=web


👑 @software_Labdon
Forwarded from Linux Labdon
کاهش هزینه سیستم‌های هوش مصنوعی با Semantic Caching

با رشد مدل‌های زبانی بزرگ و پیشرفته، هزینه و زمان پاسخ‌دهی هم به شدت افزایش پیدا کرده. مدل‌هایی مثل GPT-5 یا Claude برای کارهای پیچیده فوق‌العاده‌اند، ولی استفاده از اون‌ها هم پرهزینه و هم کند محسوب می‌شه. از طرف دیگه، AI Agentها واقعاً «توکن‌خور» هستن؛ یعنی برای انجام یک کار معمولاً چندین مرحله طی می‌کنن: تحقیق، برنامه‌ریزی، عمل و بازتاب و تکرار. همین باعث می‌شه چندین بار با مدل تماس بگیرن و در نتیجه هزینه و تأخیر افزایش پیدا کنه و متن‌های طولانی‌تر تولید بشه. برای مثال، یه بنچمارک اخیر از TheAgentCompany در ۲۰۲۵ نشون داده اجرای کامل یک Agent گاهی تا ۶.۸ دلار هزینه داره.

یکی از مشکلات اصلی در دنیای واقعی، تکراری بودن سوال‌هاست، مخصوصاً توی پشتیبانی مشتری. کاربران دائماً سوال‌های مشابهی می‌پرسن: مثل «چطور پولم رو پس بگیرم؟» یا «شرایط بازگشت وجه چیه؟» و Agent مجبور می‌شه هر بار پاسخ رو از صفر تولید کنه. نتیجه‌ش افزایش هزینه، طولانی شدن زمان پاسخ و فشار بیشتر روی سیستم‌های RAG و زیرساخت‌هاست.

در نگاه اول، ممکنه فکر کنیم کش کلاسیک کفایت می‌کنه. ایده‌ی کش ساده اینه که اگر یک سوال قبلاً پاسخ داده شده، دوباره سراغ مدل نریم. ولی مشکل اینجاست که کش سنتی دنبال Exact Match یا تطابق دقیق متنه. سوال‌هایی که از نظر معنی یکی هستن ولی عبارت‌هاشون فرق می‌کنه، مثل: «می‌خوام پولم رو پس بگیرم»، «چطور می‌تونم درخواست بازگشت وجه بدم؟» و «سیاست بازگشت پولتون چیه؟»، همه Cache Miss می‌شن و کش عملاً استفاده نمی‌شه.

اینجاست که Semantic Caching وارد می‌شه. به جای تطابق کلمه‌به‌کلمه، کش به معنی و مفهوم جمله نگاه می‌کنه. مزیت اصلی‌ش اینه که Recall و Hit Rate بالاتره و احتمال استفاده از کش و صرفه‌جویی خیلی بیشتر می‌شه. البته چالشش هم اینه که گاهی ممکنه جواب بی‌ربط بده یا همون «False Positive» رخ بده.

روش کار Semantic Caching ساده است ولی هوشمندانه: ابتدا سوال کاربر به Embedding یا بردار عددی تبدیل می‌شه. بعد با بردارهای موجود در کش با Semantic Search مقایسه می‌شه. اگر فاصله معنایی کم باشه، پاسخ از کش برگردونده می‌شه؛ در غیر این صورت به RAG یا LLM می‌ریم. در نهایت سوال و پاسخ جدید هم ذخیره می‌شه تا دفعه بعدی قابل استفاده باشه.

پیاده‌سازی Semantic Caching با چالش‌هایی همراهه؛ مثل دقت (Accuracy) که آیا کش جواب درست می‌ده، کارایی (Performance) و میزان Cache Hit، سرعت سرویس‌دهی، آپدیت‌پذیری کش و اینکه آیا می‌تونیم کش رو گرم، تازه‌سازی یا پاکسازی کنیم. همچنین مشاهده‌پذیری (Observability) مهمه تا بتونیم hit rate، latency، صرفه‌جویی هزینه و کیفیت کش رو بسنجیم.

معیارهای اصلی سنجش کش شامل Cache Hit Rate هست که نشون می‌ده چند درصد درخواست‌ها از کش پاسخ داده می‌شن و Precision/Recall/F1 Score که کیفیت و دقت پاسخ‌ها رو مشخص می‌کنه. برای بهبود دقت و کارایی کش هم می‌تونیم Threshold فاصله رو تنظیم کنیم، Reranker اضافه کنیم مثل Cross-encoder یا LLM-as-a-judge، از Fuzzy Matching برای تایپوها استفاده کنیم و فیلترهای اضافی مثل تشخیص پرسش‌های زمان‌محور (Temporal) یا تشخیص کد (Python، Java و…) اعمال کنیم تا سوالات اشتباه وارد کش نشن.

یه مثال واقعی از این تکنولوژی پروژه waLLMartCache در Walmart هست. اون‌ها با نوآوری‌هایی مثل Load Balancer برای توزیع کش روی چند Node و Dual-tiered Storage که L1 = Vector DB و L2 = In-memory Cache مثل Redis هست، هم سرعت و هم دقت رو بالا بردن. Multi-tenancy هم باعث شده چند تیم یا اپلیکیشن از یک زیرساخت مشترک استفاده کنن. Decision Engine هم شامل تشخیص کد و زمانه و اگر سوال مناسب کش نباشه مستقیماً به LLM یا RAG می‌ره. نتیجه‌ش رسیدن به دقت نزدیک ۹۰٪ بوده.

<Reza Jafari/>

👉 https://t.iss.one/addlist/AJ7rh2IzIh02NTI0
2