اگر سرور برای رونویسی یا ترجمه به صوت یا متن آشکار دسترسی داشته باشد، آن قابلیت دیگر در همان مرز رمزنگاری سرتاسری پیام اصلی قرار ندارد.
Livara: پیام صوتی خصوصی با رمزگذاری سرتاسری
Livara فایل‌های صوتی را پیش از آپلود رمزگذاری می‌کند و کلید هر پیوست را داخل پیام رمزگذاری‌شدهٔ LVR1 یا LGS1 منتقل می‌کند. این طراحی برای چت‌های مستقیم و گروه‌های خصوصی است و به سرور اجازه نمی‌دهد برای تحویل پیام، صوت یا متن آشکار آن را بخواند. Livara قابلیت رونویسی یا ترجمهٔ ابری را به‌عنوان بخشی از مرز E2EE معرفی نمی‌کند.
پردازش ابری: راحتی بیشتر، دامنهٔ اعتماد گسترده‌تر
در پیام‌رسانی که ویس یا متن را برای رونویسی و ترجمه به سرور می‌فرستد، پردازش ابری می‌تواند قابلیت‌های فوری و کاربردی ارائه دهد؛ اما سرور یا پردازشگر باید داده‌ای قابل‌فهم برای مدل دریافت کند. میزان حفاظت به محل پردازش، نگه‌داری خروجی، استفادهٔ شخص ثالث و مستندات فنی همان سرویس بستگی دارد.
### verdict برای محتوای صوتی خصوصی، Livara برندهٔ این مقایسه است، چون رمزگذاری فایل و انتقال کلید را در چت‌های مستقیم و گروهی داخل مرز E2EE نگه می‌دارد و سرور را برای رونویسی یا ترجمهٔ پیام صوتی به محتوای آشکار متکی نمی‌کند. پردازش ابری در قابلیت‌های هوش مصنوعی ممکن است راحت‌تر باشد، اما باید به‌عنوان انتخابی با افشای بالقوهٔ محتوا و نه E2EE کامل معرفی شود.
رونویسی خودکار پیام صوتی در پیام‌رسان و ترجمه پیام در چت امن فقط قابلیت‌های راحتی نیستند؛ آن‌ها درباره این پرسش تصمیم می‌گیرند که چه کسی محتوای صوتی شما را می‌بیند. اگر ویس برای پردازش به سرور فرستاده شود، سرویس می‌تواند متن آشکار آن را تولید کند؛ بنابراین ادعای رمزنگاری سرتاسری باید جداگانه برای خود فایل صوتی و برای قابلیت‌های پردازشی بررسی شود.
پاسخ کوتاه این است: رونویسی یا ترجمه الزاماً رمزنگاری سرتاسری را از بین نمی‌برد، اما اجرای آن روی سرور با E2EE واقعی برای همان محتوای پردازش‌شده سازگار نیست. در Livara، پیام صوتی و فایل پیش از آپلود رمزگذاری می‌شوند و کلید فقط از مسیر رمزگذاری‌شدهٔ چت خصوصی منتقل می‌شود؛ سرور به متن یا صدای آشکار دسترسی ندارد.
Key takeaways
- اگر سرور پیام صوتی را برای تبدیل گفتار به متن دریافت کند، باید محتوای صوتی یا متن استخراج‌شده را در نقطه‌ای پردازش کند و این با محرمانگی کامل محتوای پیام نزد سرور سازگار نیست.
- ترجمه پیام در چت امن زمانی با E2EE واقعی هم‌راستا می‌ماند که ترجمه روی دستگاه گیرنده انجام شود یا معماری‌ای که محرمانگی آن قابل‌راستی‌آزمایی است، متن را به سرور نفرستد.
- رمزنگاری ویس در پیام‌رسان باید هم فایل صوتی را پیش از آپلود بپوشاند و هم کلید آن را فقط از مسیر رمزگذاری‌شده به گیرنده برساند.
- وجود عبارت «رمزنگاری سرتاسری» برای چت، به‌تنهایی ثابت نمی‌کند که رونویسی، ترجمه، پشتیبان‌گیری یا تماس صوتی نیز همان مرز امنیتی را دارند.
- Livara پیام‌های صوتی مستقیم و گروهی را در قالب چت خصوصی با رمزنگاری سرتاسری محافظت می‌کند، اما کانال‌ها عمداً عمومی و رمزنگاری‌نشده هستند.
آیا سرور پیام صوتی من را می‌شنود؟
اگر رونویسی یا ترجمه روی سرور انجام شود، پاسخ عملی این است که سرور باید به داده‌ای قابل‌پردازش دسترسی داشته باشد؛ این می‌تواند فایل صوتی آشکار، بخشی از صوت، یا متن آشکار تولیدشده از آن باشد. حتی اگر فایل در مسیر انتقال رمزگذاری شده باشد، رمزگشایی در سرور برای اجرای قابلیت، مرز E2EE را برای آن عملیات تغییر می‌دهد.
«رمزنگاری سرتاسری» یا E2EE یعنی محتوا از دستگاه فرستنده تا دستگاه گیرنده رمزگذاری می‌شود و سرویس واسط نباید بتواند متن یا فایل را به شکل آشکار بخواند. این تعریف تضمین نمی‌کند که هر قابلیت جانبی هم خصوصی باقی می‌ماند؛ باید مشخص شود پردازش در کدام دستگاه و با کدام کلید انجام می‌شود. مقایسه‌های فنی میان پیام‌رسان‌ها، از جمله Signal vs WhatsApp: What End-to-End Encryption Actually Protects و E2EE Messaging: What’s Encrypted, What’s Not، نشان می‌دهند متن پیام، متادیتا و قابلیت‌های جانبی مرزهای رمزگذاری یکسانی ندارند.
گزارش Messaging App Encryption Comparison نیز میان حفاظت از محتوای پیام، متادیتا و معماری اعتماد تفاوت می‌گذارد. این تفکیک مهم است: ممکن است متن اصلی پیام E2EE باشد، اما یک سرویس رونویسی ابری متن جدیدی تولید کند که دیگر در همان مرز رمزنگاری قرار ندارد.
در Livara، پیام صوتی در چت مستقیم یا گروه خصوصی یک پیوست رمزگذاری‌شده است: هر پیوست کلید محتوای تازهٔ خود را دارد، فایل پیش از آپلود رمزگذاری می‌شود و کلید داخل پیام رمزگذاری‌شدهٔ LVR1 یا LGS1 قرار می‌گیرد. سرور برای تحویل فایل لازم نیست صدای آشکار یا متن آن را ببیند؛ جزئیات الگوریتم‌ها در بخش رمزنگاری ویس آمده است.
این مرز را نباید با متادیتا اشتباه گرفت. Livara برای همگام‌سازی بلادرنگ، متادیتای استاندارد مسیریابی مانند فرستنده، مقصد و زمان تحویل را ذخیره می‌کند. E2EE محتوای صوت را می‌پوشاند، اما به‌طور خودکار همه اطلاعات پیرامون ارسال را حذف نمی‌کند.
رونویسی خودکار پیام صوتی در پیام‌رسان چگونه حریم خصوصی را تغییر می‌دهد؟
رونویسی خودکار پیام صوتی در پیام‌رسان، گفتار را به متن قابل جست‌وجو یا قابل خواندن تبدیل می‌کند. اگر این تبدیل روی سرور انجام شود، سرور یا پیمانکار پردازشگر باید به صوت یا خروجی متنی دسترسی موقت یا دائمی داشته باشد؛ بنابراین این قابلیت می‌تواند سطح افشای محتوا را بیشتر از ارسال یک فایل صوتی رمزگذاری‌شده کند.
قابلیت رونویسی و نقض حریم خصوصی را هم نمی‌توان دو موضوع جدا از هم دید: هرچه خروجی متنی بیشتر ذخیره، ایندکس یا به سرویس دیگری سپرده شود، دامنهٔ افشا بزرگ‌تر می‌شود. این موضوع حتی زمانی مهم است که خود فایل صوتی پس از پردازش حذف شود؛ متن رونویسی‌شده یک نسخهٔ مستقل از محتوای خصوصی است و ممکن است در حافظه، صف پردازش، گزارش خطا، تاریخچهٔ گفتگو یا سامانهٔ جست‌وجو باقی بماند. نمی‌توان بدون مستندات فنی گفت که حذف واقعاً انجام می‌شود یا نسخه‌ای از متن نگه‌داری نمی‌شود.
سه پرسش مرزی باید پاسخ روشن داشته باشند:
آیا رونویسی روی دستگاه انجام می‌شود؟
اگر صوت بدون خروج از دستگاه به متن تبدیل شود، سرویس ابری لازم نیست محتوای صوت را ببیند. اما ادعای «روی دستگاه» باید با مستندات، کد قابل بررسی، مجوزهای شبکه یا آزمایش عملی پشتیبانی شود؛ صرف نمایش یک گزینه در رابط کاربری برای اثبات آن کافی نیست.
آیا متن رونویسی‌شده هم رمزگذاری می‌شود؟
اگر متن تولیدشده در چت ذخیره یا برای گیرنده ارسال می‌شود، باید مانند متن معمولی داخل همان کانال E2EE قرار بگیرد. بااین‌حال، رمزگذاری متن پس از تولید، افشای احتمالی آن در مرحلهٔ پردازش سرور را جبران نمی‌کند؛ باید هر دو مرحله جداگانه بررسی شوند.
آیا ارائه‌دهندهٔ هوش مصنوعی شخص ثالث دخیل است؟
اگر سرویس پیام‌رسان صوت را به یک API بیرونی بفرستد، دامنهٔ اعتماد از خود پیام‌رسان فراتر می‌رود. نام شرکت پردازشگر، محل پردازش، سیاست نگه‌داری، استفاده برای آموزش و امکان حذف باید مشخص باشد؛ در غیر این صورت کاربر نمی‌داند چه نهادی به محتوای قابل‌فهم دسترسی پیدا کرده است.
برای بررسی اصول پایه، راهنمای رمزنگاری سرتاسری چه چیزی را محافظت می‌کند توضیح می‌دهد که رمزگذاری محتوا با پنهان‌کردن متادیتا یا کنترل قابلیت‌های پس از رمزگشایی یکسان نیست.
ترجمه پیام در چت امن چگونه با E2EE سازگار می‌شود؟
ترجمه پیام در چت امن فقط زمانی با E2EE کامل سازگار است که متن یا صوت برای ترجمه از دستگاه‌های دو طرف خارج نشود، یا راهکاری ارائه شود که بدون آشکارکردن محتوای قابل‌خواندن به سرویس ترجمه کار کند. در معماری معمول ترجمهٔ ابری، متن باید به سرویس ترجمه برسد و این یعنی آن سرویس می‌تواند محتوای متن را پردازش کند.
برای پیام صوتی، زنجیره حتی طولانی‌تر است: صوت به متن تبدیل می‌شود، متن به موتور ترجمه می‌رود و ترجمه به کاربر برمی‌گردد. هر مرحله می‌تواند مرز امنیتی جداگانه‌ای داشته باشد. اگر صوت و متن اصلی با E2EE محافظت شوند اما ترجمه در سرور انجام شود، نمی‌توان کل جریان را «کاملاً سرتاسری» نامید.
این نتیجه به معنای بد بودن ترجمهٔ ابری نیست؛ به معنای شفاف‌بودن هزینهٔ حریم خصوصی است. کاربر ممکن است برای سرعت، کیفیت زبانی یا مصرف کمتر باتری، پردازش ابری را انتخاب کند. مسئله این است که گزینهٔ انتخابی باید روشن باشد و برنامه نباید قابلیت ابری را با حفاظت سرتاسری یکی معرفی کند.
در یک طراحی خصوصی‌تر، ترجمه روی دستگاه گیرنده انجام می‌شود. در این حالت پیام ابتدا به‌صورت رمزگذاری‌شده تحویل می‌شود، دستگاه آن را پس از رمزگشایی ترجمه می‌کند و سرور متن را نمی‌بیند. این طراحی محدودیت‌هایی مانند نیاز به مدل محلی، مصرف فضای ذخیره‌سازی، مصرف باتری و پشتیبانی زبانی دارد؛ اما مرز اعتماد را کوچک‌تر نگه می‌دارد.
رمزنگاری ویس در پیام‌رسان باید دقیقاً چه چیزی را بپوشاند؟
رمزنگاری ویس در پیام‌رسان فقط رمزگذاری کانال انتقال نیست؛ باید خود محتوای فایل، کلید محتوا و مسیر تحویل آن را نیز پوشش دهد. اگر فایل فقط هنگام انتقال رمزگذاری شود و روی سرور به شکل آشکار ذخیره شود، هر کسی که به ذخیره‌سازی دسترسی دارد ممکن است بتواند آن را بخواند.
در Livara، پیوست‌های صوتی پیش از آپلود با یک کلید محتوای تصادفی ۳۲ بایتی و تازه رمزگذاری می‌شوند. پیام حاوی کلید از طریق پروتکل خصوصی همان گفتگو منتقل می‌شود: LVR1 برای پیام‌های مستقیم و LGS1 برای گروه‌های خصوصی. LVR1 یک دابل‌راتچ ترکیبی پساکوانتومی دارد که در آن راتچ ECDH P-256 و راتچ دوره‌ای ML-KEM-768 کنار هم اجرا می‌شوند و هر کلید پیام از هر دو منبع مشتق می‌شود.
برای این مشتق‌سازی، Livara از HKDF-SHA-256 استفاده می‌کند و فایل‌ها با AES-256-GCM، نانس ۱۲ بایتی و تگ ۱۶ بایتی محافظت می‌شوند. این نام‌ها مهم‌اند، چون «رمزنگاری نظامی» یا «رمزگذاری قوی» بدون تعیین الگوریتم، اندازه کلید، مدیریت نانس و احراز اصالت، معیار فنی کاملی نیستند.
برای گروه‌های خصوصی، LGS1 از sender key استفاده می‌کند؛ هر کلید فرستنده داخل پوشش‌های جفت‌به‌جفت LVR1 مهروموم می‌شود. بنابراین پیام صوتی گروهی نیز در همان مرز رمزنگاری ترکیبی پساکوانتومی قرار می‌گیرد. این حفاظت به پیام‌ها و پیوست‌های چت خصوصی محدود است؛ رسانهٔ تماس صوتی و تصویری پساکوانتومی نیست.
کانال‌ها عمداً جریان‌های عمومی پخش هستند و E2EE نیستند. محتوای کانال برای مخاطبان خوانا است تا Livara بتواند گزارش‌ها را بررسی کند و در صورت استفادهٔ سوءاستفاده‌گرانه، محتوا یا کانال را حذف کند. خصوصی‌بودن چت مستقیم و گروهی نباید به کانال‌های عمومی تعمیم داده شود.
هوش مصنوعی و رمزنگاری سرتاسری را چگونه هم‌زمان ارزیابی کنیم؟
هوش مصنوعی و رمزنگاری سرتاسری الزاماً دشمن یکدیگر نیستند؛ تعارض زمانی ایجاد می‌شود که مدل هوش مصنوعی برای کارکردن به محتوای آشکار روی سرور نیاز داشته باشد. پرسش درست این نیست که «آیا برنامه هوش مصنوعی دارد؟» بلکه این است که «کدام دستگاه یا سرویس، در چه لحظه‌ای، متن یا صوت آشکار را می‌بیند؟»
یک ارزیابی عملی را می‌توان با چهار لایه انجام داد:
لایهٔ اول: محل پردازش
بررسی کنید قابلیت روی دستگاه اجرا می‌شود، روی سرور پیام‌رسان، یا نزد یک ارائه‌دهندهٔ بیرونی. عبارت‌هایی مانند «پردازش امن» به‌تنهایی مشخص نمی‌کنند که داده برای مدل قابل‌خواندن است یا نه.
لایهٔ دوم: مسیر داده
با مستندات فنی یا بررسی شبکه مشخص کنید چه چیزی ارسال می‌شود: فایل کامل، قطعه‌ای از صوت، متن خام، متن رمزگذاری‌شده یا فقط یک درخواست محلی. اگر قابلیت هنگام قطع شبکه کار نمی‌کند، این نشانه‌ای از وابستگی به سرویس آنلاین است، هرچند به‌تنهایی اثبات قطعی افشای محتوا نیست.
لایهٔ سوم: چرخهٔ عمر خروجی
بپرسید متن رونویسی یا ترجمه کجا ذخیره می‌شود، چه کسی می‌تواند آن را حذف کند، آیا برای آموزش استفاده می‌شود و آیا در پشتیبان‌گیری قرار می‌گیرد. خروجی قابلیت نیز دادهٔ خصوصی است و باید جدا از فایل اصلی حسابرسی شود.
لایهٔ چهارم: امکان بررسی فنی
به مشخصات پروتکل، کد، تست‌بردار و آزمایش مستقل توجه کنید. در Livara، Proof Lab امکان بررسی آفلاین تمامیت APK اندروید را با چک‌سام SHA-256 منتشرشده فراهم می‌کند و مشخصات پروتکل و تست‌بردارهای قابل بررسی نیز منتشر شده‌اند. این‌ها ابزار بررسی‌اند، نه گواهی امنیتی: Livara ادعای ممیزی مستقل پروتکل‌هایش را مطرح نمی‌کند.
برای مقایسهٔ منظم‌تر، چک‌لیست ۱۲ پرسشی انتخاب پیام‌رسان امن را کنار مستندات هر برنامه بگذارید. اگر پاسخ قابلیت صوتی در آن چک‌لیست جداگانه وجود ندارد، باید آن را یک ابهام باز بدانید، نه یک قابلیت خصوصیِ اثبات‌شده.
کدام گزینه برای پیام صوتی خصوصی امتیاز بیشتری می‌گیرد؟
در جدول زیر، «Livara» با «پیام‌رسان دارای رونویسی یا ترجمهٔ ابری» مقایسه می‌شود. ستون دوم یک دستهٔ معماری است، نه نام یک محصول مشخص؛ بنابراین امتیاز آن دربارهٔ هر برنامه‌ای صدق نمی‌کند مگر اینکه همان طراحی و افشاگری را داشته باشد.
| معیار | Livara | پیام‌رسان دارای پردازش ابری صوت و متن |
|---|---|---|
| رمزگذاری فایل صوتی پیش از آپلود | ۱۰ از ۱۰ | ۰ تا ۵ از ۱۰، بسته به طراحی |
| انتقال کلید داخل چت خصوصی E2EE | ۱۰ از ۱۰ | ۰ تا ۵ از ۱۰، بسته به طراحی |
| پردازش صوت یا متن روی سرور | ۱۰ از ۱۰ برای عدم نیاز به آن | ۰ تا ۳ از ۱۰ |
| شفافیت الگوریتم و مرزهای امنیتی | ۹ از ۱۰ | ۰ تا ۶ از ۱۰، بسته به مستندات |
| رونویسی و ترجمهٔ فوری ابری | ۰ از ۱۰ به‌عنوان قابلیت داخلی | ۸ تا ۱۰ از ۱۰ |
| حفاظت از محتوای پیام خصوصی | ۱۰ از ۱۰ | ۰ تا ۷ از ۱۰، بسته به مسیر پردازش |
Livara برای کسی مناسب‌تر است که اولویت او محرمانگی محتوای ویس و نداشتن پردازش ابری اجباری است. پیام‌رسان ابری برای کسی ممکن است راحت‌تر باشد که کیفیت یا سرعت رونویسی و ترجمه را بر کاهش دامنهٔ اعتماد مقدم می‌کند؛ اما نباید این انتخاب را با E2EE کامل برای قابلیت صوتی اشتباه گرفت.
امتیازها حکم آزمایشگاه مستقل یا رتبه‌بندی همهٔ محصولات بازار را ندارند. آن‌ها امتیاز مقایسه‌ای بر اساس معیارهای تعریف‌شده در این مقاله‌اند و در مورد یک سرویس مشخص باید با مستندات همان سرویس بازبینی شوند.
برای انتخاب پیام‌رسان امن چه پرسش‌هایی دربارهٔ صوت بپرسم؟
پیش از فعال‌کردن رونویسی یا ترجمه، از ارائه‌دهنده بخواهید به پرسش‌های زیر پاسخ دقیق بدهد:
- آیا فایل صوتی قبل از آپلود روی دستگاه رمزگذاری می‌شود؟
- آیا سرور می‌تواند فایل را برای تولید متن رمزگشایی کند؟
- آیا متن رونویسی‌شده از ابتدا تا انتها در همان چت خصوصی رمزگذاری می‌شود؟
- آیا پردازشگر شخص ثالث به صوت یا متن دسترسی دارد؟
- خروجی قابلیت چه مدت نگه داشته می‌شود و برای چه هدفی استفاده می‌شود؟
- آیا قابلیت بدون اتصال به سرور کار می‌کند؟
- آیا مشخصات پروتکل، نسخهٔ برنامه و چک‌سام قابل بررسی هستند؟
- آیا چت گروهی، فایل‌های صوتی و پیام‌های ویرایش‌شده همان حفاظت پیام متنی را دارند؟
برای بررسی تغییر کلیدهای گفتگو نیز می‌توانید روش بررسی چت رمزگذاری‌شده با safety number را بخوانید. Safety number به دو نفر اجازه می‌دهد اثرانگشت کلیدها را خارج از کانال مقایسه کنند؛ این کار جایگزین بررسی معماری رونویسی نیست، اما برای تشخیص تغییر کلید در گفتگو مفید است.
در نهایت، به صفحهٔ امنیتی و مدل تهدید هر سرویس نگاه کنید. Livara در مرزهای امنیتی منتشرشدهٔ خود توضیح می‌دهد چه چیزهایی رمزگذاری سرتاسری هستند و چه چیزهایی مانند متادیتای استاندارد مسیریابی در سامانه باقی می‌مانند.
Frequently asked questions
آیا رونویسی خودکار همیشه رمزنگاری سرتاسری را نقض می‌کند؟
خیر. اگر رونویسی کاملاً روی دستگاه انجام شود و متن خروجی نیز مانند پیام عادی در کانال E2EE قرار گیرد، خود قابلیت الزاماً E2EE را نقض نمی‌کند. مشکل زمانی ایجاد می‌شود که صوت یا متن برای پردازش به سرور یا سرویس ثالث فرستاده شود و آن سرویس بتواند محتوای آشکار را بخواند.
آیا رمزگذاری فایل صوتی و متن یک چیز است؟
خیر. رمزگذاری فایل صوتی از محتوای شنیداری محافظت می‌کند، اما متن رونویسی‌شده یک نسخهٔ جداگانه از همان محتوا است. اگر سرور متن را تولید کند، ممکن است در مرحلهٔ پردازش آن را ببیند، حتی اگر فایل اصلی هنگام ذخیره‌سازی و انتقال رمزگذاری شده باشد.
آیا ترجمهٔ پیام در چت امن می‌تواند خصوصی بماند؟
بله، به شرطی که ترجمه روی دستگاه انجام شود یا معماری فنی قابل‌راستی‌آزمایی، محتوای قابل‌خواندن را از سرور و پردازشگر بیرونی پنهان کند. ترجمهٔ ابری معمولاً نیازمند ارسال متن آشکار است؛ بنابراین باید به‌عنوان یک قابلیت با مرز حریم خصوصی متفاوت از E2EE پیام اصلی معرفی شود.
آیا Livara پیام‌های صوتی را رمزگذاری سرتاسری می‌کند؟
بله، در چت‌های مستقیم و گروه‌های خصوصی: فایل صوتی مانند دیگر پیوست‌ها پیش از آپلود رمزگذاری می‌شود و کلید آن تنها از مسیر رمزگذاری‌شده (LVR1 یا LGS1) به گیرنده می‌رسد. جزئیات الگوریتم‌ها در بخش رمزنگاری ویس آمده است. این ادعا شامل کانال‌ها نیست؛ کانال‌ها عمداً عمومی و رمزنگاری‌نشده‌اند.
آیا E2EE متادیتای ارسال پیام صوتی را هم پنهان می‌کند؟
خیر. E2EE محتوای پیام را پنهان می‌کند، نه همهٔ اطلاعات پیرامون تحویل آن؛ متادیتای استاندارد مسیریابی در Livara برای همگام‌سازی بلادرنگ باقی می‌ماند. حفاظت از صدا با حذف کامل ردپای ارتباطی یکسان نیست.
Sources
- Messaging App Encryption Comparison: Protocol, Metadata, and Trust، برای تفکیک محتوای پیام، متادیتا و مدل اعتماد در پیام‌رسان‌ها.
- Signal vs WhatsApp: What End-to-End Encryption Actually Protects، برای توضیح تفاوت میان حفاظت از محتوای پیام و سایر داده‌های پیرامونی.
- E2EE Messaging: What’s Encrypted, What’s Not، برای مقایسهٔ عملی مرزهای رمزگذاری و متادیتا در پیام‌رسان‌ها.
