Теневые истории ,разная информация полезная и не очень

[Pomidoriys]

ПОЧЕМУ ОДНИ ТЕНЕВЫЕ ПРОЕКТЫ ЖИВУТ ГОДАМИ, А ДРУГИЕ СХОДЯТ СО СЦЕНЫ ЗА НЕСКОЛЬКО МЕСЯЦЕВ

На старых площадках хорошо видно, что долгая жизнь проекта редко объясняется только хорошей технической частью или сильным стартом. Многие ресурсы запускаются громко, быстро собирают аудиторию, получают первые отзывы - а потом исчезают так же быстро, как появились. Устойчивость начинается не с запуска, а с того, как проект переживает первые серьёзные кризисы.

Самая большая разница обычно проявляется не в спокойный период, а после проблем. Взлом, конфликт внутри команды, спор с крупным участником, финансовая просадка, потеря части аудитории - именно такие моменты показывают, есть ли у проекта запас прочности. Одни после первого удара начинают рассыпаться, другие перестраивают процессы и продолжают работать дальше.

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

Но даже этого недостаточно. Со временем появляется другой фактор - инерция доверия. Старый проект переживает больше ошибок, потому что у него уже есть история. Новый проект такой роскоши не имеет: один серьёзный провал на старте может стать финальным, потому что пользователи ещё не успели накопить причин оставаться.

Есть и обратная сторона. Возраст сам по себе не делает площадку устойчивой. Некоторые проекты существуют годами только по инерции: аудитория постепенно уменьшается, активность падает, сервисы уходят, но привычка продолжает удерживать остатки сообщества. Формально площадка жива, фактически она уже давно перестала развиваться.

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

Именно поэтому самые старые проекты обычно ценны не тем, что «просто долго существуют». Их возраст - это результат множества пережитых моментов, в которых они могли закончиться, но не закончились.

 

[sedoj-enot]

Автор молодец, решил в одной теме раскрыть сразу огромную тему кибербезопасности и цифровой гигиены

 

[Pomidoriys]

Автор молодец, решил в одной теме раскрыть сразу огромную тему кибербезопасности и цифровой гигиены

Моё почтение броха

 

[Pomidoriys]

Российские сайты столкнулись с проблемой TLS-сертификатов — часть сервисов может перестать нормально открываться в зарубежных браузерах

Российская интернет-инфраструктура столкнулась с новой проблемой: международные центры сертификации начали отзывать TLS-сертификаты российских компаний из-за санкционных требований. В частности, GlobalSign в июне принудительно отозвал сертификаты для тысяч российских доменов. Такие сертификаты подтверждают подлинность сайта и обеспечивают защищённое HTTPS-соединение между пользователем и сервером.

Проблема уже затрагивает крупные организации, включая банки и государственные сервисы. Часть российских сайтов переходит на сертификаты Национального удостоверяющего центра, однако Chrome, Firefox и Safari по умолчанию им не доверяют. Поэтому пользователю может потребоваться установить российский корневой сертификат самостоятельно либо использовать браузер, в котором он уже встроен.

Если международные центры продолжат отзывать сертификаты, российским компаниям придётся быстрее перестраивать инфраструктуру и искать альтернативных поставщиков. Это может привести к ситуации, когда один и тот же сайт будет нормально открываться в российском ПО, но выдавать предупреждение о безопасности или вовсе работать некорректно на устройствах без соответствующего сертификата.

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

Сталкивались ли вы уже с российскими сайтами, которые внезапно начали выдавать предупреждение о небезопасном соединении?

 

[Pomidoriys]

ПОЧЕМУ СОВРЕМЕННЫЙ ДАРКНЕТ ДАВНО НЕЛЬЗЯ СВЕСТИ К TOR И .ONION

Формула «даркнет = Tor + onion-сайты» уже слишком узкая для того, как эта среда устроена сейчас. Tor остаётся важной частью инфраструктуры, но значительная часть процессов давно распределена между разными платформами. Форум может находиться в onion, оперативное общение - в мессенджере, публичные заявления - в обычном интернете, а отдельные сервисы вообще работать в другой среде. Единая экосистема больше не обязана существовать внутри одной сети.

Это меняет и саму логику взаимодействия. Раньше конкретная площадка могла концентрировать вокруг себя почти всё: аудиторию, обсуждения, репутацию, объявления и связанные сервисы. Сейчас гораздо чаще существует набор взаимосвязанных точек, каждая из которых выполняет свою функцию. Поэтому исчезновение одного ресурса далеко не всегда означает исчезновение стоящего за ним сообщества или проекта.

Особенно важна пограничная зона между clearnet и darknet. Часть инфраструктуры может быть совершенно публичной, но обслуживать процессы, связанные с закрытой средой. И наоборот: наличие onion-адреса само по себе ещё ничего не говорит о характере сообщества или проекта. Смотреть только на доменную зону уже недостаточно - гораздо важнее связи между участниками, сервисами и каналами коммуникации.

Современный даркнет всё меньше похож на отдельное место и всё больше - на распределённую систему. Один элемент исчезает, его функцию подхватывает другой. Меняется мессенджер, переезжает форум, закрывается сервис, появляются новые каналы, но сама сеть отношений продолжает существовать.

Поэтому сегодня даркнет корректнее определять не по тому, где именно находится ресурс, а по тому, частью какой экосистемы он является. Tor в этой модели остаётся важным слоем, но уже давно не исчерпывает всю среду.

 

[Pomidoriys]

Исследователи нашли серьёзные проблемы безопасности в Telegram Mini Apps

Группа исследователей изучила безопасность приложений, которые запускаются прямо внутри Telegram, и обнаружила у них большое количество проблем с хранением конфиденциальных данных. Из 37 протестированных Mini Apps 30 содержали уязвимости разной степени серьёзности. Некоторые приложения сохраняли токены авторизации и другие секретные данные прямо на устройстве пользователя в недостаточно защищённом виде.

Особое внимание исследователи обратили на приложения, связанные с криптовалютами. В отдельных случаях на устройстве можно было обнаружить данные, позволяющие восстановить доступ к аккаунту или повторно использовать действующий токен авторизации. Проблема оказалась актуальна даже для официального Wallet в Telegram: исследователи сообщили, что ранее его recovery-фраза могла сохраняться в открытом виде на устройстве.

После передачи информации разработчикам Telegram платформа добавила два новых API для безопасного хранения данных. Исследователи повторно проверили официальный Wallet и подтвердили, что после исправления мнемоническая фраза больше не хранится там в открытом виде. При этом работа показывает более широкую проблему: сторонние Mini Apps получают доступ к чувствительной информации, но уровень их защиты может сильно различаться.

Mini Apps выглядят как обычная часть Telegram, однако технически за ними могут стоять совершенно разные разработчики и подходы к безопасности.

Проверяете ли вы, кто разработал Mini App, прежде чем подключать к нему аккаунт или криптокошелёк?

 

[Pomidoriys]

ЧТО НА САМОМ ДЕЛЕ ПРОИСХОДИТ ПОСЛЕ ВВОДА .ONION-АДРЕСА В TOR BROWSER

У обычного сайта браузер в конечном счёте получает сетевой адрес сервера и строит соединение до него. У onion-сервиса логика другая: публичный IP конечного сервера клиенту вообще не нужен. Более того, вся схема специально устроена так, чтобы ни одна сторона не получала обычный прямой маршрут до другой.

Сам .onion-адрес - это не просто необычное доменное имя. В современной схеме v3 он связан с криптографической идентичностью сервиса, поэтому Tor проверяет не только «куда идти», но и с кем именно устанавливается соединение.

В упрощённом виде внутри сети участвуют несколько элементов:
onion-адрес, связанный с ключами сервиса
introduction points, через которые сервис объявляет своё присутствие внутри Tor
Tor-цепочка со стороны клиента
Tor-цепочка со стороны onion-сервиса
rendezvous point, где эти две цепочки сходятся

После ввода адреса клиент получает из распределённой инфраструктуры Tor сведения, необходимые для связи с сервисом. Затем он выбирает rendezvous point и строит к нему собственную цепочку. Через introduction point сервис получает запрос и независимо строит вторую цепочку к той же точке.

Получается важный момент: клиент не соединяется с onion-сервером напрямую. Фактически встречаются две цепочки внутри Tor. Именно поэтому здесь нет привычного exit relay, который нужен при выходе из Tor в обычный интернет: весь маршрут остаётся внутри сети.

Это также объясняет, почему фраза «Tor просто несколько раз перекидывает запрос, а потом он попадает на скрытый сервер» слишком грубо описывает процесс. В случае onion-сервиса сеть не просто скрывает маршрут - она участвует в обнаружении сервиса, проверке его идентичности и организации самой точки встречи.

В итоге onion-сервис - это не обычный сайт, которому просто выдали странный адрес. Это другая модель соединения, где клиент не должен знать реальное сетевое местоположение сервера, а промежуточные узлы получают только ограниченные фрагменты общей картины. Именно эта архитектура и отличает onion-сервисы от обычного веба.

 

[sedoj-enot]

ЧТО НА САМОМ ДЕЛЕ ПРОИСХОДИТ ПОСЛЕ ВВОДА .ONION-АДРЕСА В TOR BROWSER

У обычного сайта браузер в конечном счёте получает сетевой адрес сервера и строит соединение до него. У onion-сервиса логика другая: публичный IP конечного сервера клиенту вообще не нужен. Более того, вся схема специально устроена так, чтобы ни одна сторона не получала обычный прямой маршрут до другой.

Сам .onion-адрес - это не просто необычное доменное имя. В современной схеме v3 он связан с криптографической идентичностью сервиса, поэтому Tor проверяет не только «куда идти», но и с кем именно устанавливается соединение.

В упрощённом виде внутри сети участвуют несколько элементов:
onion-адрес, связанный с ключами сервиса
introduction points, через которые сервис объявляет своё присутствие внутри Tor
Tor-цепочка со стороны клиента
Tor-цепочка со стороны onion-сервиса
rendezvous point, где эти две цепочки сходятся

После ввода адреса клиент получает из распределённой инфраструктуры Tor сведения, необходимые для связи с сервисом. Затем он выбирает rendezvous point и строит к нему собственную цепочку. Через introduction point сервис получает запрос и независимо строит вторую цепочку к той же точке.

Получается важный момент: клиент не соединяется с onion-сервером напрямую. Фактически встречаются две цепочки внутри Tor. Именно поэтому здесь нет привычного exit relay, который нужен при выходе из Tor в обычный интернет: весь маршрут остаётся внутри сети.

Это также объясняет, почему фраза «Tor просто несколько раз перекидывает запрос, а потом он попадает на скрытый сервер» слишком грубо описывает процесс. В случае onion-сервиса сеть не просто скрывает маршрут - она участвует в обнаружении сервиса, проверке его идентичности и организации самой точки встречи.

В итоге onion-сервис - это не обычный сайт, которому просто выдали странный адрес. Это другая модель соединения, где клиент не должен знать реальное сетевое местоположение сервера, а промежуточные узлы получают только ограниченные фрагменты общей картины. Именно эта архитектура и отличает onion-сервисы от обычного веба.

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