Раніше цього року в ході планового тесту на проникнення, проведеного незалежною компанією з питань безпеки, було виявлено проблему в тому, як наша платформа обробляла певні спільні URL-адреси зустрічей. Ми розпочали роботи з усунення цієї проблеми, і виправлення згодом було перевірено тією самою зовнішньою компанією, яка про неї повідомила.
Паралельно з нашими негайними заходами з усунення проблеми до нас звернувся незалежний дослідник у сфері безпеки, щоб повідомити про ту саму проблему. Його повідомлення надійшло до нас, коли ми вже працювали над виправленням. Проблема була вирішена незабаром після цього.
Ми лише зараз публічно висвітлюємо це питання у нашому блозі, оскільки в мережі почали з’являтися статті, що посилаються на висновки дослідника, і ми хочемо, щоб у відкритих джерелах було відображено те, що насправді сталося.
Що було доступним, а що — ні
Ця проблема стосувалася лише невеликої частини зустрічей, які користувачі явно налаштували як публічні. Публічний доступ на tl;dv — це налаштування, яке потрібно вмикати окремо; за замовчуванням воно вимкнене, і його вмикають свідомо, коли клієнт хоче, щоб зустріч була видимою за межами його команди.
Навіть у випадку тих публічних зустрічей, яких це стосувалося, їхній вміст не відображався під час звичайного перегляду або пошуку на сайті tl;dv: для доступу до нього були потрібні конкретні програмні дії з боку хакера, обізнаного в технічних питаннях.
У кількох окремих випадках користувачеві вдалося отримати URL-адреси зустрічей і увійти до чатів у режимі реального часу, використовуючи незнайоме ім’я та отримавши дозвіл на вхід від організатора вручну. У рамках наших негайних заходів з усунення проблеми ми повністю захистили цей канал доступу, щоб унеможливити отримання URL-адрес зустрічей таким чином.
Щодо засідань, які за замовчуванням мають статус «приватних» (а це становить переважну більшість активності на сайті tl;dv), доступ до будь-якого вмісту ніколи не надавався. Записи, стенограми та нотатки, створені за допомогою штучного інтелекту, щодо приватних засідань залишалися захищеними протягом усього часу.
Ширший контекст
Налаштування публічного доступу в продуктах на базі штучного інтелекту та SaaS продемонстрували подібні результати протягом останніх місяців. Anthropic Виявлено відкриті публічні артефакти в Claude та його екосистемі MCP через пошук Google. Компанії Lovable та Zoom обидві компанії працювали над випадками, коли налаштовані користувачами параметри публічного доступу забезпечували ширшу видимість, ніж очікували користувачі. Це категорія проблем користувацького досвіду, до якої галузь загалом ставиться дедалі уважніше.
Спільна риса: поняття «публічний» може мати різне значення для різних користувачів, і користувацький досвід, пов’язаний із вибором публічної видимості, має чітко роз’яснювати наслідки такого рішення. Ми переглядаємо підхід до того, як ще краще відображати ці варіанти вибору у нашому продукті, і сподіваємося незабаром впровадити відповідні зміни.
Наші подальші плани
Безпека — це не кінцева мета для жодної платформи. Ми продовжуємо інвестувати в незалежне тестування, у швидке усунення будь-яких виявлених проблем та в постійне вдосконалення методів захисту даних клієнтів.
Як зв’язатися з нами
З будь-якими питаннями щодо вашого облікового запису, будь ласка, пишіть на електронну адресу [email protected].
Алан Беттарел, технічний директор компанії «
», tl;dv
P.S. Так, на початку цього року наша команда також створила невеликий внутрішній додаток для прогнозування результатів Чемпіонату світу з футболу, який колеги з нетехнічних підрозділів написали на «Vibe» просто для розваги, і який розмістили на субдомені. Цей додаток не мав жодного зв’язку з даними клієнтів чи виробничими системами, і з того часу ми посилили контроль доступу до нього.



