Безпекова політика
MODERATION
POLICY.
Як LUMYN реагує на зловживання при збереженні архітектури Zero-Knowledge та абсолютної приватності користувачів.
← Назад до оновлень
// Підхід
Privacy-first модерація
LUMYN ніколи не читає ваші повідомлення — це технічно неможливо завдяки E2E шифруванню. Але це не означає відсутності відповідальності. Наш підхід до безпеки будується на технічних обмеженнях, а не на стеженні.
Zero-Knowledge гарантія. Сервер LUMYN ніколи не зберігає контент повідомлень та не має технічної можливості їх розшифрувати. Приватні ключі зберігаються виключно на пристроях користувачів.
Немає бекдорів
Не існує жодного технічного способу передати вміст приватних чатів третім особам, включаючи правоохоронні органи.
Мінімальні метадані
Сервер не зберігає хто кому і коли писав. Лише тимчасова черга для доставки, яка очищається одразу після успішного отримання.
Без номера телефону
Ідентифікація через криптографічний ключ, а не SIM-карту. Анонімна реєстрація без прив'язки до реальної особи.
Rate limiting
Технічні обмеження на рівні сервера запобігають масовому спаму та DDoS атакам без доступу до вмісту повідомлень.
// Процес
Abuse Response Flow
Оскільки ми не можемо читати повідомлення, наша відповідь на abuse будується виключно на технічних сигналах та скаргах користувачів.
01
Отримання скарги
Користувач надсилає abuse-report через форму підтримки. Скарга фіксується з пріоритетом на основі типу: spam, harassment, або security incident.
support form · email
02
Технічна верифікація
Перевірка технічних сигналів: rate limit violations, аномальна активність акаунту, підозрілі патерни підключень. Без аналізу вмісту повідомлень.
server logs · rate metrics
03
Прийняття рішення
На основі технічних даних: попередження, тимчасове обмеження швидкості, або блокування публічного ключа. Рішення приймається вручну розробником.
manual review
04
Апеляція
Кожен заблокований акаунт має право на апеляцію через форму підтримки. Розгляд в межах 48 годин з детальним поясненням рішення.
48h SLA
05
Security Incident Response
Критичні інциденти (вразливості в протоколі, компрометація сервера) обробляються за окремим процесом з пріоритетом 24/7. Сповіщення публікуються в Telegram-каналі та оновленнях.
critical priority · public disclosure
// Технічний периметр
Anti-spam захист
Технічні обмеження на рівні Socket.IO сервера, що не потребують доступу до вмісту повідомлень.
→
Rate Limiting
Обмеження кількості повідомлень на секунду per user. Перевищення ліміту призводить до тимчасового throttling без блокування акаунту.
→
Connection throttling
Обмеження на частоту reconnect спроб. Захищає від flood атак на рівні підключень.
→
Public key blocklist
Зловживаючі акаунти блокуються за публічним ключем. Оскільки ключ не пов'язаний з особою, це не порушує анонімність інших користувачів.
→
FCM push обмеження
Push-сповіщення через Firebase мають окремі rate limits для запобігання notification spam.
Повідомити про зловживання
Якщо ви зіткнулися з порушенням або знайшли вразливість — напишіть нам. Security-репорти обробляються у пріоритетному порядку.