Например, могут не открываться многие вполне легитимные веб-сайты (во вполне легитимных браузерах — воспроизведение см. выше), которые хостятся в т.ч. в РФ дата-центрах.
Вот и столкнулся с вышеобозначенным вариантом, "in the wild".
При этом, интересный нюанс: если вы таки добились заморозки на 120 секунд (что, конечно, не очень сложно), и попытаетесь сменить фингерпринт "браузера" (в т.ч. на "неподозрительный"), то вы дополнительно поймаете блокировку на 600 секунд.
Не наблюдаю. Ловлю блокировку в Chrome. Через несколько секунд проверяю в FF - в нём всё загружается без проблем. После этого Chrome размораживается через обычные ~ 2 мин.
Адрес сайта отправил в личку, во избежание рекламы.
Спасибо за показательное тестирование. При проверке я использовал схожий подход. Разобрался, почему у меня блокировка отсутствовала. Оказалось, что когда то отключал ECH через политики хрома (которые применяются ко всем профилям). Со всеми вытекающими последствиями в виде измененного fingerprint. После отключение политики результат стал ожидаемым - блокировка.
Возможно, у вас был HTTP/1.1 в режиме keep-alive (т.е. одно TCP соединение) или же HTTP/2 (т.е. тоже одно TCP соединение).
Да, каждое из соединений использовало HTTP/2, но было установлено 5 параллельных, независимых соединений. Про разные профили указал не случайно - они обеспечивают изоляцию на уровне сетевых соединений. Дамп трафика это подтверждает.
Как при этом обстояли дела с проверкой https сертификата в браузере?
Она была отключена флагом ignore-certificate-errors. А это имеет значение? Как понял, для срабатывания блокировки установка соединений не требуется, фиксируются только попытки TLS соединений на этапе ClientHello.
Есть и другие сложности с тестированием из песочницы.
Есть какие-то замечания по подходу к проверке?
Не только.
Но на реальном Chrome протестировать не пробовали? Было бы интересно, совпадут ли результаты с моими, это важно для корректной оценки.
Попробовал установить несколько параллельных TLS соединений к хосту российского провайдера, для которого dpi-ch у меня детектирует Syberian. Проверку проводил в реальном Chrome. В разных профилях браузера (чтобы обеспечить установку новых соединений) один и тот же URL был открыт 5 раз за 100-200мс период. В URL использовал случайный несуществующий домен, для которого в локальном резолвере был задан IP хоста. Результат - отсутствие блокировки.
Верно ли я понимаю, что проверка на реальном браузере не проводилась, а выводы в разделе "Субъективная оценка" базируются только на основе результатов тестирования посредством uTLS?
Тоже задаюсь в последнее время этим вопросом. Причём положительный рейтинг набирают даже существенно более "выдающиеся" образчики, например https://habr.com/ru/articles/1013122/ Что уж говорить про эту статью, которая не более чем заурядный представитель "жанра".
Новые. Были добавлены в созданную мной папку, к уже находящимся в ней другим (моим) закладкам. Более ожидаемым бы было добавление в новую (отдельную) папку.
Вообще ситуация с невозможностью отказа от перехода до сегодняшнего дня носила массовый характер, вне зависимости от страны. Этому посвящена целая ветка на reddit.
Сегодня многим (мне в том числе) на аккаунт супер администратора пришло e-mail сообщение о необходимости принять меры до 27 июня. Также вверху на главной странице админки появилось соответствующее уведомление. И главное - переход наконец заработал. Правда замечу, что диалоговое окно перехода загрузилось не с первой попытки, несколько раз получал печально известное "Something went wrong".
Кому отказали в поддержке - возможно настоящая причина не в политике, а в неосведомленности тех сотрудников о реальной проблеме.
Вот и столкнулся с вышеобозначенным вариантом, "in the wild".
Не наблюдаю. Ловлю блокировку в Chrome. Через несколько секунд проверяю в FF - в нём всё загружается без проблем. После этого Chrome размораживается через обычные ~ 2 мин.
Адрес сайта отправил в личку, во избежание рекламы.
Спасибо за показательное тестирование. При проверке я использовал схожий подход. Разобрался, почему у меня блокировка отсутствовала. Оказалось, что когда то отключал ECH через политики хрома (которые применяются ко всем профилям). Со всеми вытекающими последствиями в виде измененного fingerprint. После отключение политики результат стал ожидаемым - блокировка.
Да, каждое из соединений использовало HTTP/2, но было установлено 5 параллельных, независимых соединений. Про разные профили указал не случайно - они обеспечивают изоляцию на уровне сетевых соединений. Дамп трафика это подтверждает.
Она была отключена флагом ignore-certificate-errors. А это имеет значение? Как понял, для срабатывания блокировки установка соединений не требуется, фиксируются только попытки TLS соединений на этапе ClientHello.
Есть какие-то замечания по подходу к проверке?
Но на реальном Chrome протестировать не пробовали? Было бы интересно, совпадут ли результаты с моими, это важно для корректной оценки.
Попробовал установить несколько параллельных TLS соединений к хосту российского провайдера, для которого dpi-ch у меня детектирует Syberian. Проверку проводил в реальном Chrome. В разных профилях браузера (чтобы обеспечить установку новых соединений) один и тот же URL был открыт 5 раз за 100-200мс период. В URL использовал случайный несуществующий домен, для которого в локальном резолвере был задан IP хоста. Результат - отсутствие блокировки.
Верно ли я понимаю, что проверка на реальном браузере не проводилась, а выводы в разделе "Субъективная оценка" базируются только на основе результатов тестирования посредством uTLS?
Тоже задаюсь в последнее время этим вопросом. Причём положительный рейтинг набирают даже существенно более "выдающиеся" образчики, например https://habr.com/ru/articles/1013122/ Что уж говорить про эту статью, которая не более чем заурядный представитель "жанра".
Ясно. Ранее "Туризм" скорее всего я удалил. Ссылки были добавлены в первую в списке папку закладок, которую я сам создал.
Новые. Были добавлены в созданную мной папку, к уже находящимся в ней другим (моим) закладкам. Более ожидаемым бы было добавление в новую (отдельную) папку.
После обновления до 7.7 в одну из папок с закладками добавились партнерские рекламные ссылки. Это ожидаемое поведение?
Модификации не слетают после каждого обновления.
Про CSS модификации не слышали? Включаются через vivaldi://experiments/
Вообще ситуация с невозможностью отказа от перехода до сегодняшнего дня носила массовый характер, вне зависимости от страны. Этому посвящена целая ветка на reddit.
Сегодня многим (мне в том числе) на аккаунт супер администратора пришло e-mail сообщение о необходимости принять меры до 27 июня. Также вверху на главной странице админки появилось соответствующее уведомление. И главное - переход наконец заработал. Правда замечу, что диалоговое окно перехода загрузилось не с первой попытки, несколько раз получал печально известное "Something went wrong".
Кому отказали в поддержке - возможно настоящая причина не в политике, а в неосведомленности тех сотрудников о реальной проблеме.
После подтверждения, что аккаунт используется в личных целях, на главной странице в админке появляется вот такой баннер:
По всей видимости - это единственный индикатор успешного отказа от перехода на бизнес версию. Название подписки при этом не изменяется.