WSGlebKavash, это как раз не самая проблема, в DVB давно и успешно умеют кодировать каналы. Там другая проблема: придётся брать обязательства на обеспечение сервиса. Мобильным операторам это совершенно не нужно.
Какая реальная задача стоит? Сейчас вопрос выглядит как полная несуразица. S3 это не прокси, а сервис хранения файлов, а Cloudfront это не прокси, а CDN. Соответственно, S3 не будет вообще ни в какой "back domain" обращаться, а Cloudfront будет кэшировать данные и далеко не каждый запрос прокинет, он для того и предназначен, чтобы быстро отдавать контент, не заставляя пользователя ожидать скачивания с оригинального сайта где-то далеко.
Весь этот геморрой не просто так, а в целях борьбы со спамом. И это лишь отчасти предлог (на A2P SMS операторы неплохо так зарабатывают), потому что на практике это реально помогает от засилья SMS-спама. Когда за спам надо выплатить приличную сумму денег, пройти проверку на вшивость (доказательства владения товарным знаком итд) и оправдываться за жалобы от получателей перед оператором, то он становится намного менее выгоден.
Есть более цивилизованные каналы маркетинга. Сайты, группы в соцсетях, каналы в телеграммах, PUSH-сообщения в фирменном мобильном приложении итд итп... Где пользователь более явно выражает своё согласие на получение информации и не менее легко и быстро может его отозвать.
Denis93, эта штуковина - тупая обёртка над библиотекой tdjson. Там кода почти нет. Я заглянул внутрь и очевидно же что там надо создать экземпляр класса и звать от него send/receive/execute. В send или execute передаётся array который внутри сериализуется в json и передаётся в tdjson. Дальше надо смотреть, что делает tdjson и что в него надо передавать. Вроде бы вот это официальный пример: https://github.com/tdlib/td/blob/master/example/py...
PrilForReal, под словом "база данных" иногда подразумевают саму базу с данными, а иногда софт, на которым она крутится (та самая "СУБД"). Да, иногда это может вызывать неопределённость, но крайне редко.
PrilForReal, это крайне стрёмный способ бэкапа, так как для использования бэкапа потребуется база данных такой же версии с таким же конфигом и ещё не факт что нормально взлетит.
Так себе это работает. Особенно с учётом того, что многие из видов "пробива" это даже не серая зона, а самое настоящее уголовное преступление, и на него пойдут только ради сотрудников, которые будут иметь разве что очень высокий уровень доступа к критичным знаниям и данным. А отказывать по причине каких-либо проблем у родственников вообще, скорее всего, нарушает трудовое законодательство (кроме специфических случаев типа гостайны).
Легальные пути тоже есть. Например, могут потребовать предоставить справку о несудимости, которую выдают структуры МВД. Мне довелось работать в бюджетной организации, которую присоединили к другой с наличием в уставе декларации о несудимости сотрудников, пришлось ходить получать. Но это не "пробив", а легальный документ, который человек получает самостоятельно. Точно так же могут потребовать и медицинские справки.
lexstile, там прикол в том что комментарии реализованы так: каждому посту в канале соответствует публикация в группе, а комментарии - это цитирования этой публикации. Есть даже лайфхак как убрать у поста комментарии: надо просто удалить эту публикацию в группе, и комментарии исчезнут.
Естественно, по всем старым постам в канале копии сами по себе не появляются.
Maxwell012, ну у меня браузер на базе хромиума такое съедает (иногда нужно лезть через прокси кой-куда). Единственное что если / на конце поставить то он тихо игнорирует прокси и не ругается, что было для меня неожиданностью.
Никак, это невозможно контролировать. Ссылку на телеграф легко пересылать и невозможно ограничить. Если надо прям защитить-защитить, то это придётся писать свою веб-систему показа скрытого контента с авторизацией через телеграм, чтобы она могла проверять подписки. Очень неудобно для пользователей и никакого особого смысла.
Это нормально, что "рекламные кампании" нацелены не на 100% получение пользователя, а на то, что их будет больше нуля. Тем более в данном предполагаемом сценарии для получения контента достаточно подписаться, скопировать и сразу же отписаться. "Защищать" же единичный контент от распространения и копирования вообще довольно бесперспективно, лучше работать над тем, чтобы в канале постоянно был контент под нужную аудиторию, которая не будет уходить, даже если контент не будет скрываться от окружающих.
KaiSem, openvz (virtuozzo), это похоже на lxc но более специфично (патченное ядро вместо нативных namespace). Всё это ненастоящие виртуализации, использующие одно ядро с хостом.
Нельзя, BGP это протокол маршрутизации, он в любом случае оперирует не портами и IP, а автономными системами. Но фильтровать что угодно на промежуточных узлах другого провайдера потенциально можно. При условии, что через этого провайдера идёт весь трафик до этих хостов. Только зачем?
