План відкриття коду SingLinkVPN

Відкритий код — це початок довгострокової довіри.

SingLinkVPN офіційно запустив програму відкритого коду та технічних досліджень і створив на GitHub офіційний репозиторій SingLinkVPN: відкритий код і технічні дослідження.

Це не одноразова публікація і не сторінка з документами лише для перегляду. Це довгострокова інженерна робота, яка постійно оновлюватиметься та з часом розширюватиметься.

Матеріали, доступні сьогодні, — це перший етап ширшої програми.

Перший етап охоплює публічну технічну документацію, моделі безпеки й приватності, відтворювані методи тестування продуктивності, машинозчитувані формати даних, структуру для публічних наборів даних, каталоги звітів, дослідницькі інструменти, процес розкриття інформації про вразливості та стандарти публікації доказів.

На наступних етапах SingLinkVPN планує поступово оприлюднювати нові технічні матеріали, дослідницькі звіти та вихідний код продукту — після перевірки безпеки, приватності, ліцензування та стабільності продукту. Заплановані напрями включають VPN-протокол, VPN-клієнти та інші ключові VPN-технології, придатні для публікації після перевірки.

Тож поточний випуск — не завершення програми. Це перший крок у безперервному процесі відкриття коду.

Офіційний репозиторій уже містить каталоги docs, data, reports, tools, tests і каталоги автоматизації GitHub для підтримки публічної документації, дослідницьких даних, матеріалів з безпеки, тестів продуктивності та відкритих інструментів перевірки. Репозиторій прямо позначено як проєкт, що активно підтримується.

Офіційний репозиторій: SingLinkLabs / singlink-vpn-open-source Поточний стан: перший етап опубліковано. Додаткові технічні матеріали, дослідницькі звіти та вихідний код продукту оприлюднюватимуться поетапно.

Навіщо SingLinkVPN запускає програму відкритого коду?

VPN тісно пов’язаний із мережевим передаванням даних, безпекою, приватністю та обробкою даних.

Більша частина роботи VPN-сервісу відбувається всередині систем, які користувачі не можуть безпосередньо спостерігати. Користувачі бачать інтерфейс застосунку, список серверів, швидкість з’єднання та опис продукту, але не можуть легко переконатися:

• як було виміряно опубліковані результати швидкості;
• яку версію програми та яке мережеве середовище використовували;
• чи повністю зафіксовано невдалі тести;
• чи є заява про безпеку зобов’язанням політики, внутрішнім тестом чи незалежною оцінкою;
• чи містить звіт дати, версії, методи та історію виправлень;
• чи може інший дослідник відтворити результат;
• чи можна відстежити технічні зміни та зміни безпеки між версіями.

Лише заяви бренду не можуть повністю відповісти на ці запитання.

Програма має перетворити технічну інформацію SingLinkVPN, а також інформацію про безпеку, приватність і продуктивність, із тверджень про продукт на публічні матеріали, які інші можуть перевіряти, цитувати, верифікувати, відтворювати й надалі ретельно вивчати.

Для цього потрібна постійна система публікації, а не просто викладення файлів в інтернет:

1. важливі технічні матеріали повинні мати визначену версію;
2. вимірювані твердження повинні вказувати дату й середовище тестування;
3. результати продуктивності повинні підкріплюватися відповідними даними;
4. внутрішні тести й оцінки третіх сторін потрібно чітко розрізняти;
5. суттєві виправлення повинні залишати публічний слід;
6. вихідний код продукту оприлюднюється поетапно після перевірки безпеки;
7. спільнота повинна мати змогу перевіряти структуру й повноту даних за допомогою публічних інструментів.

Репозиторій вимагає, щоб кожне вимірюване твердження містило дату тестування, версію програми, середовище, метод, розмір вибірки, необроблені чи агреговані дані та відомі обмеження. Неперевірювані перебільшення на кшталт «найшвидший», «найбезпечніший» чи заяви про абсолютну приватність не вважаються доказами.

Що доступно на першому етапі?

Перший етап започатковує вісім публічних напрямів роботи:

1. архітектура розробки VPN і публічна технічна документація;
2. записи про продукт і версії SingLinkVPN;
3. модель безпеки й приватності;
4. відтворювані методи тестування продуктивності;
5. формати тестових даних і структура публічних наборів даних;
6. каталоги звітів про безпеку, продуктивність і прозорість;
7. відкриті інструменти перевірки даних і досліджень;
8. повідомлення про вразливості та відповідальне розкриття.

Разом вони створюють основу, потрібну для подальшого оприлюднення вихідного коду, публічних даних і незалежних досліджень.

1. Публічна архітектура розробки VPN і технічна документація

Перший етап містить архітектуру кросплатформного VPN-клієнта.

Вона не прив’язана до однієї мови програмування чи операційної системи. Натомість вона описує основні модулі, потрібні кросплатформному VPN-клієнту: інтерфейс, життєвий цикл з’єднання, керування тунелем, маршрутизацію, DNS, конфігурацію, тестування безпеки та локальну діагностику.

1. Рівень інтерфейсу

Рівень інтерфейсу показує стан акаунта, вибір сервера, стан з’єднання, помилки, результати діагностики та функції доступності.

Стан з’єднання в інтерфейсі має визначатися фактичним станом скінченного автомата з’єднання, а не лише тим, чи натиснув користувач кнопку підключення.

2. Рівень оркестрації сеансів

Цей рівень відповідає за:

• підключення;
• відключення;
• автоматичні повторні спроби;
• зміни мережі;
• сон і пробудження пристрою;
• перезапуск застосунку;
• відновлення після аварійного переривання.

Він має не допускати, щоб застарілі результати підключення перезаписували новіші, і гарантувати, що повторні дії не створюють конфліктів.

3. Рівень адаптера тунелю

Цей рівень інтегрується з нативними VPN API різних операційних систем, зокрема щодо:

• вхідних і вихідних пакетів;
• життєвого циклу тунелю;
• налаштування MTU;
• дозволів операційної системи;
• обмежень роботи у фоновому режимі;
• зворотних викликів при перериванні тунелю.

4. Рівень маршрутизації та DNS

Цей рівень керує:

• маршрутами за замовчуванням;
• роздільним тунелюванням;
• виключеними маршрутами;
• вибором DNS;
• політикою щодо IPv4 та IPv6;
• доступом до локальної мережі;
• захистом від витоків DNS і маршрутів.

Тестування витоків не можна обмежувати першим підключенням. Воно також має охоплювати перепідключення, зміни мережі, сон і пробудження та аварійне завершення застосунку.

5. Транспортний рівень

Транспортний рівень відповідає за автентифіковані сеанси, поведінку транспорту, обробку перевантажень, політику keepalive та міграцію між мережами.

6. Рівень конфігурації

Рівень конфігурації обробляє версіоновану, підписану й мінімізовану віддалену конфігурацію та відхиляє недійсну, прострочену чи понижену конфігурацію.

7. Рівень спостережуваності

З дотриманням захисту приватності цей рівень надає:

• локальний стан працездатності;
• діагностику з’єднання;
• класифікацію помилок;
• відтворюваний вивід тестів;
• технічні дані про стан, що не містять мережевої активності користувача.

Поточний випуск охоплює загальну архітектуру та принципи безпечної розробки. Конкретніші модулі й вихідний код додаватимуться лише після завершення відповідних перевірок.

2. Версіонований публічний реєстр продукту

SingLinkVPN також створив публічний реєстр продукту, який розділяє різні види інформації.

Факти про продукт

До них належать:

• підтримувані платформи;
• публічні версії;
• дати випуску;
• офіційні джерела завантаження;
• доступні контрольні суми;
• суттєві зміни функцій і сумісності.

Опис архітектури

Він дає загальні схеми, не розкриваючи чутливих систем, облікових даних чи робочих середовищ.

Результати вимірювань

Результати продуктивності та технічні висновки повинні містити дату, метод, середовище, вибірку та підтвердні дані.

Заяви про політику

Вони стосуються роботи продукту, безпеки та зобов’язань щодо приватності. Заява про політику не подається як незалежна перевірка.

Такий поділ допомагає не змішувати політику, внутрішнє тестування, деталі реалізації та незалежні дослідження. Офіційні записи про випуски поступово включатимуть платформу, версію, дату, джерело, доступні контрольні суми, суттєві зміни безпеки й сумісності, відомі обмеження та незмінні теги Git або посилання на Release.

3. Публічна модель безпеки й приватності

Безпеку не можна описати лише словами «безпечний» чи «зашифрований».

Тому на першому етапі опубліковано модель безпеки й приватності, яка визначає ризики, що їх мають перевіряти подальші тести, звіти та незалежні оцінки.

Поточний перелік загроз включає:

• спостереження за трафіком у локальній мережі;
• витоки DNS;
• витоки IPv6;
• витоки WebRTC;
• переривання маршрутів під час перепідключення;
• захист трафіку під час переходу між Wi-Fi і мобільною мережею;
• зловмисні зміни віддаленої конфігурації;
• пониження версії конфігурації;
• розкриття облікових даних, що зберігаються на пристрої;
• ризики сторонніх залежностей;
• ризики ланцюга постачання під час збирання та випуску;
• зловживання акаунтами;
• неавторизовані сеанси;
• надмірний збір діагностичних даних чи даних підтримки.

Кожен публічний тест безпеки повинен указувати:

• версію клієнта, якої він стосується;
• операційну систему;
• дату тестування;
• умови мережі;
• метод;
• очікувану поведінку;
• фактичну поведінку;
• відомі обмеження.

Модель також розмежовує політику, документацію архітектури, внутрішнє тестування та оцінку третьою стороною.

Лише звіт названого незалежного оцінювача чи дослідника, підкріплений перевірюваним звітом, може мати позначку оцінки третьою стороною. Це створює послідовний і придатний для аудиту стандарт для майбутніх звітів про безпеку.

4. Відтворюваний метод тестування продуктивності VPN

На продуктивність VPN впливає багато зовнішніх чинників:

• країна чи регіон тестувальника;
• провайдер широкосмугового чи мобільного зв’язку;
• якість локальної мережі;
• міжнародний транзит;
• час доби;
• продуктивність пристрою;
• версія клієнта;
• протокол;
• навантаження на сервер;
• тестовий сервер;
• регіон призначення.

Тож одна пікова швидкість не відображає досвіду кожного користувача.

Опублікований метод вимагає, щоб кожен запис містив:

• час тестування за UTC;
• унікальний ідентифікатор тесту;
• версію клієнта;
• операційну систему;
• тип пристрою;
• позначку протоколу;
• версію методології;
• країну чи регіон тестування;
• тип мережі;
• кількість вимірювань;
• рівень доказовості.

Основні метрики:

Медіанна затримка з’єднання

Медіанна затримка в мілісекундах за багатьма вимірюваннями, а не один найкращий результат.

Джитер за 95-м процентилем

Верхній рівень коливань затримки, що спостерігається в більшості вимірювань.

Частка втрачених пакетів

Частка пакетів, утрачених під час тестування.

Медіанна швидкість завантаження

Медіанна пропускна здатність на завантаження в Мбіт/с за багатьма вимірюваннями.

Медіанна швидкість вивантаження

Медіанна пропускна здатність на вивантаження в Мбіт/с за багатьма вимірюваннями.

Частка успішних підключень

Відсоток успішних спроб у повторюваних тестах підключення.

Медіанний час перепідключення

Медіанний час, потрібний для відновлення після зміни мережі чи переривання.

Офіційний порядок роботи:

1. зафіксувати базову мережу без VPN;
2. не змінювати пристрій, мережу, адресу призначення та часове вікно вимірювань;
3. виконати розігрів, який не враховується;
4. повторювати тести підключення та передавання даних;
5. зберігати невдалі вимірювання, а не мовчки видаляти їх;
6. публікувати агреговані результати та машинозчитувані дані;
7. розкривати відомі обмеження, збої та виключені вимірювання.

Порівняльні тести мають проводитися в зіставних умовах. Про зміну провайдера, маршруту, пристрою, тестового сервера чи часового вікна вимірювань треба повідомляти. Датовані, версіоновані набори даних, доступні для завантаження, додаватимуться за цим методом у міру продовження тестування.

5. Машинозчитуваний публічний формат тестових даних

Поряд зі звітами, зрозумілими людині, SingLinkVPN публікує машинозчитуваний формат даних про продуктивність.

JSON Schema вимагає, щоб кожен запис про продуктивність містив:

• test_id: ідентифікатор тесту;
• tested_at_utc: час тестування за UTC;
• client_version: версія клієнта;
• platform: тестова платформа;
• protocol_label: позначка протоколу;
• country: країна чи регіон тестування;
• network_type: тип мережі;
• sample_count: кількість вимірювань;
• latency_ms_median: медіанна затримка;
• jitter_ms_p95: джитер за 95-м процентилем;
• packet_loss_pct: частка втрачених пакетів;
• download_mbps_median: медіанна швидкість завантаження;
• upload_mbps_median: медіанна швидкість вивантаження;
• connection_success_pct: частка успішних підключень;
• reconnect_ms_median: медіанний час перепідключення;
• methodology_version: версія методу;
• evidence_level: рівень доказовості.

Наразі докази можна позначати так:

• внутрішнє тестування;
• незалежне відтворення;
• оцінка третьою стороною.

Формат дає розробникам і дослідникам змогу безпосередньо перевіряти обов’язкові поля й діапазони значень та використовувати ту саму структуру для відтворення й порівняння, а не покладатися лише на графіки чи описові висновки.

6. Звіти про безпеку, продуктивність і прозорість

Репозиторій має окремий каталог звітів для постійної публікації:

• звітів про безпеку;
• звітів про продуктивність;
• досліджень приватності;
• звітів про прозорість;
• оцінок третіх сторін;
• незалежно відтворених результатів;
• повідомлень про суттєві виправлення безпеки.

Перед публікацією кожен офіційний звіт повинен указувати:

• дату публікації;
• автора чи супровідника;
• версію продукту, якої він стосується;
• метод;
• джерело даних;
• рівень доказовості;
• відомі обмеження;
• історію виправлень.

Внутрішні тести та незалежні оцінки мають різні позначки. Перший етап встановлює структуру звітів, правила щодо доказів і систему версіонування; звіти додаватимуться в міру готовності їхніх даних і перевірки, а не публікуватимуться один раз і закидатимуться.

7. Відкриті інструменти перевірки та досліджень

На першому етапі також опубліковано кілька дослідницьких і перевірних інструментів на Python.

publication_guard.py

Перед публікацією він перевіряє документи, дані та інструменти на наявність:

• облікових даних;
• форматів ключів;
• приватних шляхів;
• архівів;
• бінарних файлів;
• типів вихідного коду, не схвалених для публікації;
• надто великих файлів;
• поширених форматів робочих секретів;
• вмісту, що може описувати чутливі системи.

validate_benchmark.py

Він перевіряє CSV-файли тестів продуктивності, зокрема:

• назви стовпців;
• обов’язкові поля;
• числові діапазони;
• позначки доказовості;
• структуру тестових даних.

check_relative_links.py

Він перевіряє відносні посилання в Markdown і підтверджує, що згадані публічні файли існують.

check_multilingual_seo.py

Він перевіряє багатомовні документи та структуру, пов’язану з пошуком, щоб англійські, спрощені китайські та традиційні китайські матеріали залишалися узгодженими.

Ці інструменти не є ядром VPN-з’єднання. Це інфраструктура публікації, покликана зменшити кількість помилок форматування, непрацюючих посилань, випадкового розкриття чутливої інформації та розбіжностей між версіями. Зовнішні контриб’ютори можуть застосовувати ті самі інструменти до своїх внесків.

8. П’ятирівневий стандарт публічних доказів

Рівень перший: заява про політику

Зобов’язання щодо продукту, безпеки, роботи сервісу чи приватності, опубліковане супровідником. Це публічне зобов’язання, а не доказ реалізації чи незалежний аудит.

Рівень другий: документація реалізації

Версіонований загальний технічний опис, що не містить адрес серверів, облікових даних, приватних API чи іншої чутливої інформації.

Рівень третій: внутрішнє тестування

Тест, проведений SingLinkLabs за публічним методом, із датою, версією, середовищем і даними.

Рівень четвертий: відтворений результат

Незалежний результат, отриманий іншим розробником чи дослідником за тим самим методом і на тих самих публічних даних.

Рівень п’ятий: оцінка третьою стороною

Оцінка, проведена названим незалежним дослідником чи організацією, з перевірюваним офіційним звітом.

Ці рівні не взаємозамінні. Внутрішні тести не можна позначати як оцінку третьою стороною; політику не можна вважати незалежною перевіркою; а публікація методу не означає, що результат уже відтворено.

Кожен звіт має відповідати на запитання: хто дійшов висновку, коли, з якою версією і яким методом?

Суттєві виправлення вимагають нового коміту Git і запису в журналі змін. Опубліковані дані не можна мовчки замінювати, а замінені дані мають залишатися впізнаваними.

9. Повідомлення про вразливості та відповідальне розкриття

Відкрита публікація та безпечне розкриття мають працювати разом.

Невиправлені вразливості, робочі облікові дані, приватні кінцеві точки, адреси серверів і дані користувачів не можна публікувати в публічному Issue.

Повідомлення про вразливості слід надсилати приватно — на електронну адресу з питань безпеки або через GitHub Security Advisories — і чітко позначати як розкриття інформації про безпеку. Якщо електронну адресу з питань безпеки не опубліковано, зверніться до файлу `SECURITY.md` у репозиторії й не вгадуйте адресу.

Повідомлення має містити:

• версію, якої стосується проблема;
• платформу, якої стосується проблема;
• умови відтворення;
• вплив на безпеку;
• безпечний спосіб зв’язатися з автором повідомлення;
• матеріали для відтворення без реальних даних користувачів.

Повідомлення про безпеку проходять такі етапи:

1. сортування та підтвердження;
2. оцінка впливу;
3. усунення;
4. випуск виправленої версії;
5. розумний період для оновлення;
6. публікація бюлетеня безпеки.

Публічні бюлетені відрізняють підтверджений вплив від гіпотетичного ризику та вказують вразливі й виправлені версії.

10. Публічні дані не означають публічних даних користувачів

Технічна прозорість не повинна досягатися коштом приватності користувачів.

Репозиторій забороняє, щоб Issues, pull request’и, набори даних чи дослідницькі документи містили:

• персональні дані;
• ідентифікатори акаунтів;
• платіжні дані;
• листування зі службою підтримки;
• приватні IP-адреси;
• токени доступу;
• робочі облікові дані;
• робочі журнали;
• необроблений робочий трафік;
• тестові дані, за якими можна ідентифікувати окремого користувача.

Дані про продуктивність мають бути агрегованими або знеособленими. Перед публікацією рецензенти повинні підтвердити, що набір даних не містить даних на рівні користувачів, облікових даних чи матеріалів, за якими можна ідентифікувати реального користувача.

Програма робить прозорими технології, методи, звіти та перевірений вихідний код. Вона не публікує інформацію про користувачів, чутливі з погляду безпеки дані серверів чи робочі облікові дані.

11. Як спільнота може долучитися?

Розробники, дослідники безпеки та учасники спільноти можуть:

• покращувати технічну документацію;
• виправляти помилки в документації;
• покращувати переклади традиційною китайською, спрощеною китайською та англійською;
• покращувати відтворюваність методу тестування;
• підвищувати якість публічних даних;
• покращувати доступність;
• додавати дослідницькі інструменти;
• вдосконалювати перевірку форматів;
• знаходити непрацюючі посилання;
• пропонувати нові публічні методи досліджень;
• пропонувати покращення до дизайну тестів;
• відтворювати публічні тести з дотриманням правил безпеки.

Внески не повинні містити:

• несхваленого вихідного коду продукту;
• інформації про приватну інфраструктуру;
• облікових даних чи ключів;
• даних користувачів;
• приватних кінцевих точок;
• робочих журналів;
• повних інструкцій з експлуатації невиправленої вразливості.

Кожен вимірюваний внесок також має вказувати своє джерело, метод, дату та обмеження.

Чи означає це, що SingLinkVPN тепер повністю відкритий?

Ні. Це перший етап, а не останній.

Перший етап надає пріоритет:

• технічній документації;
• архітектурі розробки;
• моделям безпеки й приватності;
• методам тестування продуктивності;
• машинозчитуваним форматам даних;
• інструментам перевірки;
• політиці щодо доказів і публікацій;
• відповідальному розкриттю;
• основі для подальших звітів і оприлюднення вихідного коду.

До першого етапу не входять:

• повний вихідний код VPN-клієнта;
• вихідний код серверної частини;
• вихідний код платіжної системи;
• конфігурація робочих серверів;
• приватні API;
• облікові дані для автентифікації;
• чутливі деталі реалізації протидії блокуванням і мережевому протистоянню;
• повний вихідний код основного протоколу.

Це не обов’язково означає, що їх виключено з програми загалом. Кожен модуль продукту потребує окремої перевірки безпеки, приватності, залежностей і ліцензування.

Після завершення перевірки подальші випуски включатимуть:

• чітко визначений каталог відкритого коду;
• відповідну ліцензію;
• історію версій;
• межі безпеки;
• журнал змін;
• дату публікації;
• перевірюваний тег Git або Release.

Якщо спершу створити стандарти публікації, структури даних, правила безпеки та дослідницькі інструменти, основа буде безпечнішою, а ризик розкриття облікових даних, інфраструктури, даних користувачів чи стороннього коду, який не можна законно поширювати, — меншим.

Ліцензії визначатимуться в міру оприлюднення нових матеріалів

Поточний репозиторій можна переглядати публічно, але повні ліцензії на повторне використання коду та контенту ще впорядковуються залежно від типу матеріалів і вихідного коду.

Доки не опубліковано явної ліцензії, користувачі не повинні вважати, що отримали:

• право на копіювання;
• право на змінення;
• право на повторне поширення;
• право на комерційне використання;
• право на повторне ліцензування.

Чітке ліцензування — невід’ємна частина повноцінного відкритого коду. Кожен подальший випуск коду, документації, даних чи інструментів міститиме умови, що відповідають його залежностям, ліцензіям вихідних проєктів і призначенню.

Це не дає помилково застосувати ліцензію одного модуля до іншого й захищає контриб’юторів, вихідні проєкти та кінцевих користувачів.

Довгостроковий напрям програми

Напрям зрозумілий: постійно збільшувати обсяг технічних матеріалів, які є публічними, перевірюваними й відтворюваними.

1. Розширювати публічну технічну документацію

Це стосується життєвого циклу з’єднань, маршрутизації, DNS, змін мережі, безпечної конфігурації та тестування на різних платформах.

2. Публікувати версіоновані записи про продукт

Записи доповнюватимуться платформами, версіями, датами, контрольними сумами, суттєвими змінами, відомими обмеженнями та стабільними посиланнями для цитування.

3. Додавати реальні набори даних про продуктивність

Датовані, версіоновані, прив’язані до середовища машинозчитувані дані публікуватимуться за публічним методом.

4. Публікувати звіти про безпеку, продуктивність і прозорість

Звіти розрізнятимуть політику, внутрішнє тестування, незалежне відтворення та оцінку третьою стороною.

5. Заохочувати незалежне відтворення

Дослідники можуть використовувати ті самі методи й формати, щоб порівнювати різні мережі, пристрої та регіони.

6. Вдосконалювати інструменти публікації та роботи з даними

Автоматизація розширюватиметься в напрямах форматування, безпеки, документації та процесу тестування.

7. Поетапно оприлюднювати вихідний код VPN-продукту

Після перевірки безпеки, приватності, залежностей і ліцензування заплановані протокол, клієнт та інші ключові технології оприлюднюватимуться поступово.

8. Вести повніший реєстр розкриттів і виправлень

Суттєві проблеми безпеки, вразливі версії, виправлені версії та подальші оновлення матимуть чітку історію.

Репозиторій містить метадані для цитування. Дослідникам слід посилатися на позначені тегами Release, незмінні коміти та фактично використаний датований звіт чи набір даних, а не на недатовані рекламні матеріали.

Від публічних заяв до сталої перевірки

Відкритий код не повинен бути лише подією запуску.

Довгостроковий відкритий код потребує супроводу, участі ззовні, чіткого ліцензування, керування версіями, виправлень безпеки та технічних матеріалів, які інші можуть перевірити й відтворити.

Почавши з документації, методів досліджень, форматів даних, стандартів доказів, структур звітів та інструментів перевірки, програма закладає основу для ширшого оприлюднення коду.

По-перше, створити публічну точку входу

Технічні матеріали, матеріали з безпеки, приватності та продуктивності, раніше розпорошені, зібрано в одному репозиторії GitHub, що підтримується.

По-друге, встановити стандарти публікації

Програма визначає, що можна публікувати, які поля мають містити тести, як класифікуються докази та як фіксуються виправлення.

По-третє, закласти основу для подальшого відкриття коду

Процеси безпеки, приватності, ліцензування та керування версіями готуються для звітів, наборів даних, протоколів, клієнтів та інших модулів.

Тож перший етап не подає обмежений початковий випуск як увесь результат. Він відкриває процес, розрахований на розширення.

Поширені запитання (FAQ)

Чи офіційно SingLinkVPN запустив програму відкритого коду?

Так, SingLinkVPN офіційно запустив програму відкритого коду. Офіційний репозиторій відкритого коду та технічних досліджень працює, а документація, методи досліджень, формати даних та інструменти перевірки першого етапу є публічними.

Чи весь вихідний код VPN тепер публічний?

Ні, не весь вихідний код SingLinkVPN наразі публічний. Вихідний код протоколу, клієнта та інших частин продукту оприлюднюватиметься помодульно після перевірки безпеки, приватності, залежностей і ліцензування.

Чому б не опублікувати все одразу?

VPN-продукт може містити інформацію про робочі сервери, облікові дані, приватні API, чутливі захисні механізми, сторонні залежності та код під різними ліцензіями.

Поетапна перевірка зменшує ризик розкриття даних користувачів, деталей інфраструктури, робочих облікових даних чи стороннього коду, який не можна повторно поширювати.

Чи публікуватимуться реальні дані про продуктивність?

Так, SingLinkVPN публікуватиме реальні дані про продуктивність. Метод і машинозчитуваний формат — перший крок. Далі з’являться датовані, версіоновані дані та звіти із зазначенням середовища, розміру вибірки та обмежень.

Чи будуть звіти про безпеку та прозорість публічними?

Так, звіти SingLinkVPN про безпеку та прозорість будуть публічними. Репозиторій має окремий каталог звітів і правила публікації. Звіти додаватимуться, щойно будуть готові їхні докази, методи, версії та опис обмежень.

Чи означає публікація моделі безпеки, що аудит третьою стороною завершено?

Ні. Модель безпеки — це публічна основа для подальшого тестування та оцінювання.

Оцінка третьою стороною називатиме оцінювача й міститиме посилання на перевірюваний звіт. Її не подаватимуть як внутрішнє тестування.

Що можуть зробити розробники?

Розробники можуть долучатися до документації, перекладу, методів досліджень, якості даних, доступності, інструментів перевірки та відтворення тестів.

Про вразливості безпеки слід повідомляти приватно, а не публікувати їх у публічному Issue.

Чи міститимуть публічні дані дані користувачів?

Ні, публічні дані SingLinkVPN не міститимуть даних користувачів. Вони мають бути агрегованими або знеособленими й не можуть містити даних акаунтів, платіжних даних, приватних IP-адрес, токенів доступу, робочих журналів чи необробленого робочого трафіку.

Висновок: відкритий код — це початок довгострокової довіри

Програма відкритого коду SingLinkVPN уже розпочалася.

Перший етап закладає технічну документацію, методи досліджень, стандарти доказів, формати даних, правила розкриття, структуру звітів та інструменти перевірки.

Далі з’являться нові звіти про безпеку, продуктивність і прозорість. Більше публічних даних додаватиметься в єдиному форматі. Більше технічних матеріалів і вихідного коду продукту оприлюднюватиметься поетапно після перевірки безпеки, приватності та ліцензування.

Це не одноразове оголошення бренду і не останній крок. Це безперервна інженерна робота.

Наша мета — перетворити технічну інформацію SingLinkVPN, а також інформацію про безпеку, приватність і продуктивність, з матеріалів, які описує лише бренд, на публічні докази, які спільнота може перевіряти, цитувати, верифікувати, відтворювати й надалі ретельно вивчати.

Ми запрошуємо розробників, дослідників безпеки, технічні медіа та користувачів спільноти, які хочуть покращувати документацію, відтворювати дослідження, перевіряти дані й брати участь у технічних обговореннях.

Відкритий код — це початок довгострокової довіри.

І це лише перший крок.

Переглянути офіційний репозиторій відкритого коду SingLinkVPN