nirvimel

По любой хоть немного релевантной картинке можно провести Search by Image. Это дает, во-первых, неплохой (иногда) ключевик для дальнейших поисков по нему. Во-вторых - море форумов, где эта картинка постилась (скорее всего в окружении релевантных же).

Похоже, у вас утечка DNS, а провайдер блокирует kinozal по домену, а rutracker только по ip.
Это решается правильной настройкой браузера:
В Firefox нужно задать network.proxy.socks_remote_dns=true и network.dns.disablePrefetch=false в about:config.
В Chrome нужно отключить "Predict network actions to improve page load performance".
И обратите внимание, что тип прокси указан именно SOCKS5. Через SOCKS4 браузер будет спокойно подключаться к SOCKS5 серверу, но DNS может потечь в обход (в зависимости от поддержки SOCKS4a).

И учитывайте, что прямой SOCKS к удаленному серверу - это полностью открытый и прозрачный канал, то есть провайдер видит (даже если не блокирует) весь ваш HTTP трафик на 100%, а из HTTPS знает, по крайней мере, имена доменов (и скоро начнет хранить у себя все это). Поэтому я рекомендую пользоваться именно SSH, который предоставляет защищенный туннель.

select_(wikipedia), poll - это функции API в Unix системах (входят в стандарт POSIX), которые позволяют организовать в одном потоке ожидание завершения множества операций ввода/вывода, то есть выполнять асинхронный ввод/вывод.
epoll_(wikipedia) - это более современный вариант pool в Linux.

Фризы из-за сетевых задержек - это абсолютно реально. По-другому клиент-серверную игру просто невозможно реализовать, она не может отдельно от сервера продолжать играть сама по себе.
А вот падение FPS - это признак плохой архитектуры. При хорошей архитектуре отрисовкой кадров занимается отдельный поток, который ни в какой момент не совершает синхронных вызовов сетевого ввода/вывода и продолжат рисовать кадры так быстро, как это возможно (но не быстрее vsync по уму) даже в моменты, когда геймплей замер в ожидании взаимодействия с сервером.

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

Теперь о том, что они реально могут сделать:
Во-первых, аннулировать ваш аккаунт вместе со всеми средствами, которые там зависли. И вы не сможете с них ничего взыскать, если даже найдутся живые свидетели, которые лично видели как вы выполняли работу, за которую они обещали (по соглашению (нарушенному)) выплачивать деньги.
Во-вторых, они могут отказать вам в регистрации нового аккаунта на свои уже реальные данные, если они каким-то образом смогут вычислить, что вы - тот самый нарушитель соглашения.
В-третьих, (чисто гипотетически) они могут попробовать взыскать с вас материальный ущерб, причерченный их компании вашими действиями. Но по таким искам бремя доказательства лежит полностью на стороне истца (а мы-то знаем, что доказывать там реально нечего), поэтому в жизни этим никто никогда не занимается.
В-четверных, они могут передать органам или выбросить в паблик любую информацию, полученную от вас за все время вашего с ними сотрудничества, начиная от тех самых ваших ложных персональных данных и заканчивая всеми IP, с которых вы к ним заходили. Конфиденциальность всех этих данных держится на том самом пользовательском соглашении, которое вы нарушили. Но, с другой стороны, тут они могут нарваться на иск с вашей стороны о возмещении морального и/или материального ущерба, если вам удастся как-то доказать связь этого ущерба с их действиями. (Но я уже ушел в гипотетические рассуждения).

Короче... 98% они просто зажмут бабки и на этом история закончится.

scrapy, dryscrape, selenium, phantomjs.

Вы смешали в одну кучу совершенно разные технологии. Из приведенных инструментов только scrapy является непосредственно парсером, остальные же - так называемые headless браузеры, а это совсем другой уровень тяжеловесности.

Каким способом можно обновлять только javascript генерируемые значения не перезагружая весь вебсайт?

Настоящие парсеры (на голом lxml или на мощном комбайне scrapy) никогда не (пере)загружают весь вебсайт, они вообще не работают с целым сайтом, а только с отдельными HTTP-запросами. Чтобы совершить десять или двадцать запросов одновременно, не требуется совершенно ничего перезагружать.
Что касается динамического контента на странице, то скрипты генерируют его не сами, а точно так же запрашивают с сервера. Парсеру ничего не мешает запросить тот же самый контент, ничего не зная ни о каких скриптах.

Как получать данные с сайта(генерируемые javascript) с частотой до 1/10 секунды?

Частота это понятие из физики (радиотехники и акустики). А в компьютерных сетях существует задержка и ширина канала. Задержка между разными полушариями Земли не может быть меньше 1/10 секунды (около того). Но по пропускной способности парсер может обрабатывать десятки (средних) и сотни (мелких) запросов/ответов в секунду.
Для парсера норма - скрапить целевой сайт в несколько десятков потоков (в Python предпочтительнее green threads).
Для эмулятора браузера - каждый запущенный процесс может выжирать десятки (а то и сотни) мегабайт. И его перезапуск - операция очень медленная.

P.S.: И откуда в последнее время пошла эта мода смешивать headless браузеры с парсерами? Во всех документациях к Selenium и др. четко говориться, что это - инструмент для автоматизированного тестирования, а ни какой не парсер.

1. Чрезвычайно сложно найти VPS, разрешающий поднятие выходной ноды Tor (а вы не думали почему во всем мире этих нод не так уж много?).
   
2. Еще сложнее оплатить его анонимно. Нужна будет чужая кредитка... (тут долго объяснять), но по цепочке денежных транзакций выйти на вас будет ГОРАЗДО проще, чем по цепочке VPN.
   
3. Поднятие выходной ноды сразу привлечет к этому IP внимание спецслужб всего мира. Контролировать трафик выходящий из Tor - их работа. Все соединение начнут логгироваться (множеством заинтересованных сторон). До этого вы были никому ненужным рядовым анонимом. Теперь вы - владелец выходной ноды, это как выступать на сцене перед огромным залом.
   
4. Итак, вы проходили регистрацию при покупке сервера, ставили туда софт, настраивали, тестировали... Значит к этому моменту профиль сетевой активности с вашего реального IP уже довольно сильно коррелирует с профилем активности на этом сервере. Во всем мире становится тесно остается все меньше адресов с таким высоким уровнем корреляции. А значит, люди, владеющие статистикой трафика, уже довольно точно представляют откуда управляется эта выходная нода.
   
5. Ну и самое главное (с чего следовало бы начать): Tor не защищает от timing-атак на коммуникации в реальном времени. А SIP по определению есть коммуникация в реальном времени, следовательно подвержен timing-атакам сквозь Tor (и любые low latency сети/тоннели).
   

Что касается собственно CPU, то тут (далее по ссылкам) подробнее.

Как считаете, такая схема достаточно надежна или есть более защищенные/удобные способы?

На этом погорели многие. Люди настолько привыкли окружать себя удобными вещами, что не понимают, что это их удобство иногда может оказаться просто несовместимо с безопасностью.
Разговор в реальном времени (не важно с каким шифрованием и через сколько туннелей) позволяет сопоставить двух абонентов друг с другом на основании только того, что они начинают и заканчивают разговор одновременно! Этой мелочи часто бывает достаточно, чтобы по логам (за много лет до того) выявить связь между двумя субъектами, которые находились в разных странах у разных операторов и пользовались разными технологиями связи (GSM/Skype/SIP). И это не решается применением никакого чудо-софта или никакими технологиями шифрования. Это фундаментальный неустранимый недостаток коммуникаций в реальном времени. Единственное решение - полностью отказаться от общения в реальном времени и вернуться к использованию старой доброй почты (электронной, конечно), с ней тоже связаны многие проблемы в плане безопасности, но они, по крайней мере, имеют техническое решение.

В том виде, в котором вы описали, конечно же, не сработает.
Вопрос о туннелировании UDP через SSH сводится к вопросу о туннелировании UDP поверх TCP.
Для этого существуют специальные инструменты типа udptunnel.

Update: Только что нашел простой способ туннелирования UDP (отдельного порта) через SSH на практически голом шелле (nc + ssh) без внешних зависимостей.

1. При очень высоком трафике (не бойтесь, это не ваш случай) шифрование в SSL все-таки дает некоторую дополнительную нагрузку на сервер.
   
2. Все промежуточные прокси могут кешировать статический контент, если значение заголовка Cache-Control позволяет им это, такое кеширование в какой-то мере разгружает сервер, с которого раздается статика. Но для этого они должны иметь возможность "заглядывать" в, проходящие сквозь них, HTTP-пакеты. А HTTPS существует как раз для того, чтобы препятствовать этому.
   

Правильнее будет спросить: Насколько безопасен OpenSSH по сравнению с closed-source альтернативами?
Ответ: Для частного использования (не берем в расчет корпорации с многомиллионными бюджетами на информационную безопасность) на сегодняшний день OpenSSH - наиболее безопасный инструмент в своей сфере применения.
Слухи о том, что некоторый инструмент, являющийся стандартом в своей сфере, якобы не безопасен, могут распространять те, кому очень неприятна ситуация с массовым использованием технологии, против которой у них нет простых средств противодействия (вы поняли, о ком речь). Цель распространения подобных слухов в том, чтобы массовый пользователь, плохо разбирающийся в вопросе, отказался от использования стандартного инструмента и начал искать малоизвестные решения (security through obscurity - где-то на интуитивном уровне прошита в человеческий мозг и является одним из когнитивных искажений, внезапно всплывшим в информационную эпоху). Производители малоизвестных решений (типично closed-source) или уже давно сотрудничают с теми, кто заинтересован, чтобы эти решения защищали ото всех, кроме Них. Либо просто дилетанты (их даже не надо склонять к сотрудничеству) с агрессивным маркетингом, убеждающим рядового пользователя, что решение, полученное за ТАКУЮ сумму, просто не может не работать.

DroidWall
AFWall+
или любой другой firewall.
(Разумеется нужен root в любом случае).

Провайдер по запросу правоохранительных органов выдает сведения о пользователях.

В РФ ничего подобного нет: ни запросов, ни головной боли у провайдеров по поводу их исполнения. Тут все происходит гораздо проще и элегантнее: чтобы получить лицензию на соответствующий вид деятельности, провайдер покупает за свои деньги оборудование СОРМ, устанавливает его у себя в качестве шлюза (весь трафик идет через него), ему опечатывают это оборудование так, чтобы он сам не мог там копаться. Дальше полная автоматика, никаких официальных запросов, никаких бумаг, никакой бюрократии. Внутри самой СОРМ любая информация доступна сотрудникам по одному клику, без срока давности (хранение полного лога трафика, конечно, ограничено техническими возможностями, но метаданные хранятся практически вечно). Список лиц (а существует ли он вообще), за которыми ведется наблюдение является секретной информации и не предоставляется гражданским лицам без соответствующего уровня допуска (то есть всем, кроме самих сотрудников и их руководства), именно так обычно и значится во всех официальных ответах на любые попытки гражданских запросить свой статус (под наблюдением или нет).

Незаконно добытые сведения не могут быть доказательством в суде, верно же?

Смеялись всем отделением. Поверьте, никто не станет напрягаться, чтобы собирать какие-то доказательства, все доказательства человек предоставит сам, как только окажется в отделении (вы сомневаетесь? а сами вы там бывали?). Есть только одна проблема - найти того самого человека. Для решения этой проблемы и существует СОРМ.

Эх, Юлмарт.Дисконт, сколько воспоминаний... Однажды в 2014 я писал для одной конторы бота, который должен был перехватывать "горячие" позиции выставляемые по неадекватно низким ценам. Бот проводит оперативную оценку по Яндекс.Маркету ("горячие" варианты случаются, только по тем позициям, которые уже отсутствуют в их собственном ассортименте на момент уценки, по тем позициям, которые еще торгуются, они никогда не ошибаются с ценами) и перемножает на коэффициент, вычисляемый от заявленного состояния товара.
Так вот за первые двое суток его боевого применения случилось больше десяти срабатываний (и это только в одной товарной категории! правда, это был конец декабря). Подобных "горячих" позиций я никогда не видел при ручном серфинге, подозревал, что это сказки. Я выключил бота когда мелких заказов оформилось где-то на 35к руб. на разные аккаунты. Забирать все это поехал один коллега, вернулся ни с чем - из всех заказов не доставлено ни одного! (все заказы в ЛК в актуальном состоянии, дата получения - это число). Единственное, что смог сказать ему менеджер, что так бывает очень редко, когда две заявки приходят одновременно, то обе могут забронироваться до того, как произойдет списание с остатков (похоже, эти индусы не слышали про атомарные транзакции), а логистика исполняет ту, у которой отметка времени чуть раньше.
Я задумался: мой бот проверяет обновления раз в минуту и сразу оформляет заказ, как только находит подходящий вариант, но из более десяти заказов ему не достался ни один, у него увели из под носа все, это значит, что кто-то парсит и бронирует быстрее его, намного быстрее! Кто бы это мог быть? Только другой чей-то бот! Похоже, на тот момент у кого-то уже был построен на этом свой бизнес. Мы опоздали.
С тех под я не занимался Юлмарт.Дисконт-ом, не имею понятия, как там сейчас обстоят дела.