Как отключить запись логов в файл вк

Обновлено: 05.07.2024

1. Зайдите в раздел «Настройки» через левое меню приложения, выберите пункт «О программе» и в открывшемся боксе несколько раз нажмите на изображение собаки (ничего не должно произойти).

Учтите что отключение рекламы оттягивает введение новых функций в социальной сети

мне кажется реклама в вк самая что ни на есть ненавязчивая в плане контента

все равно что знакомый постит фигню типа я теперь зэк второго уровня в приложении помотай срок

ну это я так, для примера

все таки чистая лента это гигиена

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

Комментарий удален по просьбе пользователя

Если английский язык интерфейса выбрать, то рекламы не будет вроде. Я по крайне мере не заметил.

На IOS бы такой режим включить.

Уже давным-давно это известно.

А что за режим "невидимка"? Оффлайн в официальном приложении?

Да ты ж мой спаситель.

Теперь другой вопрос: КАК ВЛЮЧИТЬ РЕКЛАМУ ОБРАТНО?

Там галочка ведь.

Скачайте в гуглплее запускалку секретных меню, найдите в списке vk и откройте. Ну или другой способ - поставить стороннюю звонилку.

О, круто.
Видел способ такой же, но без тыкания на собаку и на 4.4.4 работал способ, потом на 5.1.1 не было пункта отключить рекламу в отладке.
А тут собаку потыцал и отключил снова.
Реклама сборника каких-то еврейских книг жутко бесила.

Хочется однако заметить что отключая рекламу в ВК, вы лишаете соц. сеть дополнительного заработка, и соответственно оттягиваете нововведения

Ну то есть это положительная сторона, да?:)

Может мне ещё по их рекламным ссылкам ходить и чего-то там приобретать?

Там были какие то нововведения после отжатия вк у Дурова? С тех пор только монетизация всего подряд.

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

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

эти секретные коды прописываются у приложений в манифесте и легко просматриваются при желании, поэтому никакой удивительной тайны нет

Давно Гриша слил и пошло-поехало.

Пусть сделают функцию отключения рекламы, кому не нравится. Ибо как ВК должен зарабатывать?! А что?

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

Автор: Владислав Велюга (vlad805)

Disclaimer

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

И да, для любителей найти рекламу там, где её нет: этот пост/статья -- не является рекламой. Упомянутые ниже приложения приводятся в качестве примеров, не более.

Update 6

А еще давайте сразу, вот что ответил (где-то) Андрей Рогозов про данную информацию.

Предисловие

Года два назад я тоже снифил трафик с помощью Shark for Root, отправляемый ВКонтакте с телефона. Ничего странного я тогда не видел. Сейчас же, когда нас окружают "умные" (именно в кавычках, ибо они идиотские) ленты, машинное обучение и прочее, техника стала, мягко говоря, следить. С одной стороны, это хорошо (мы даем пищу для машин, чтобы они обучались), с другой - плохо (данные о нас сохраняются на серверах).

Результаты

Проснифив только авторизацию, аудиозаписи и вообще первые минуты после авторизации в приложении, уже можно поймать все эти странные запросы. Итак:

Самое странное, что мне показалось - это то, что приложение сливает абсолютно весь список пользовательских приложений, установленных на устройстве. Зачем?! (в центре скрина влепил decoded-строку параметра apps)

Вот опять. wallGetWrapNew - по названию понятно, что это запрос на получение чьей-то стены (пользователя или сообщества). Зачем тут передавать информацию о устройстве? Максимум, что приходит на ум - для статистики. Хорошо, а зачем данные о типе сети? Еще, что не относится к сливу информации: довольно раздражает то, что везде пытаются всунуть рекламу - лишь посмотреть на параметр fields.

Приложение отправляет все действия пользователя: перешел через меню в раздел "аудио", "geo_data" - вероятно, отправлял бы примерное (или даже точное) местоположение устройства. Спрашивается, зачем, если пользователь не просит находить что-то по близости? Нет, облегчать пользователю жизнь, подсказывая релевантные данные в поиске, например - в этом ничего плохого нет, но зачем отправлять геоданные просто так, при открытии поста? Не понятно.

Приложение делает бенчмарки и зачем-то передает время запроса к API и время загрузки изображений. Видимо, усредненные данные.

С видеозаписями обстоят дела еще хуже. Здесь передается информация о таких событиях как "volume_on", "volume_off" (видимо, включение/выключение звука, но это неточно), "fullscreen_on", "fullscreen_off" (переход и выход в/из полноэкранного режима), событие "video_play", которое просто отсылает текущую позицию просмотра видео, где-то с периодичностью 10-20 секунд. upd: хотя вот Андрей подсказал идею, для чего это сделано: для того, чтобы запоминалось место, на котором пользователь остановился при просмотре видео, чтобы он мог переключиться с мобильного на ПК и на ПК продолжить смотреть с места, где был в последний раз на мобильном.

При закрытии страницы (активити) с видео, приложение запрашивает метод video.viewSegments, в параметрах которого передаются рейнжы (отрезки) таймкода, которые были просмотрены пользователем.

Все это - официальное приложение. На момент написания этой статьи (29 июля 2017 года) была версия 4.12.1.

В Kate Mobile таких сливов замечено не было. Единственное, после ввода в эксплуатацию нового алгоритма выдачи аудиозаписей, и Kate, и официальному приложению нужно обращаться к Google Accounts для получения некого receipt-токена. И всё.

О том, как работают приложения на iOS, Windows Phone мне только можно догадываться. Их пакеты не перехватывал, и устройств не имею.

Повторюсь, такие данные, как ближайшие точки доступа Wi-Fi, текущее местоположение пользователя, а также все его действия не отправляются сторонними приложениями, такими как Kate Mobile, VK Coffee (модификация официального, с вырезанными метриками и пр.), моим сайтом-клиентом APIdog и пр.

Update 2

Друг-разработчик Андрей добавил ещё скринов того, что сливается официальным приложением под Android.

Название точки доступа, к которой подключено устройство, а также другие, которые находятся в зоне досигаемости, их сигнал в dB, MAC-адреса.

Плюсом от него же, вот что отправляет официальное приложение для Windows

Только версию системы, версию приложения, метод ввода.

Update 3

Эдуард Безменов, разработчик модификации официального приложения VK Coffee, прокомментировал этот пост так:

Update 4

Григорий Клюшников, бывший разработчик этого самого приложения, как оказывается, был сам против включения сервисов Vigo в приложение:

А вот, что на самом деле представляет Vigo по описанию Григория:

Отправка местоположения, как оказалось, производится только при просмотре отдельного поста. На аудиозаписи это не влияет, как некоторые стали считать, что в зависимости от региона некоторые треки "скрывается".

Update 5: Ответы от ВКонтакте

Мобильная техподдерка

Оказывается, Ваше местоположение, данные для таргетинговой рекламы, список установленных приложений и сети Wi-Fi жизненно необходимы для приложения и сайта в целом.

В ответ на последний вопрос, поддержка решила отойти от темы.

О том, как это было получено

Подручные средства

У нас в распоряжении комп под Linux (Ubuntu 16.04 LTS), два телефона на Android 5.1 (Sony Xperia L) и 6.0.1 (Samsung *какой-то там*). У Sony выпилены Google Play Services. На обоих телефонах последняя версия приложения и стороннее приложение - Kate Mobile (версии 37 и 41 соответственно). Ну, и, естественно, единая локальная сеть, к которой подключен и комп, и два устройства.

Подготовка: создание сертификата SSL

openssl req -x509 -newkey rsa:4096 -keyout key.pem -out cert.pem -days 365

Этой командой создаем сертификат, где key.pem - файл ключа, cert.pem - сертификат.

В phrase key вводим что-то типа пароля. Он нам еще понадобится. Затем его еще раз повторить. Остальные поля можно оставить пустыми/не вводить. По окончанию в текущей директории будет создано два файла.

Подготовка: установка нашего сертификата на устройство

Передаем файл cert.pem на устройство и устанавливаем его в систему. Обращу внимание, что для установки сертификата необходимо, чтобы на телефоне был какая-нибудь защита на экране блокировки (графический ключ, пароль или PIN).

Пошаговая установка сертификата на Android 5.1

Подготовка: переброс портов

Возвращаемся на Linux, вбиваем в терминал:

sudo sysctl -w net.ipv4.ip_forward=1
sudo iptables -t nat -F
sudo iptables -t nat -A PREROUTING -p tcp --dport 80 -j REDIRECT --to-ports 8080
sudo iptables -t nat -A PREROUTING -p tcp --dport 443 -j REDIRECT --to-ports 8443
sudo iptables -t nat -A PREROUTING -p tcp --dport 587 -j REDIRECT --to-ports 8443
sudo iptables -t nat -A PREROUTING -p tcp --dport 465 -j REDIRECT --to-ports 8443
sudo iptables -t nat -A PREROUTING -p tcp --dport 993 -j REDIRECT --to-ports 8443
sudo iptables -t nat -A PREROUTING -p tcp --dport 5222 -j REDIRECT --to-ports 8080

Подготовка: Ettercap

После установки его запускаем.

Снифинг данных

Клацаем "Sniff" -> "Unifed sniffing. ". В окне выбора интерфейса обычно выбирается уже нужный (может быть wlan0, wlp1s0, enp5s0), если не тот - выбрать свой. "ОК".

Далее: "Hosts" -> "Scan for hosts". Ожидаем сканирование хостов.

Далее "Hosts" -> "Hosts list". В списке выбираем IP нашего роутера (у меня 192.168.1.1) и жмем "Add to target 1", затем выбираем IP устройства (у меня 192.168.1.222), затем "Add to target 2".

192.168.1.1 - роутер - target 1; 192.168.1.222 - телефон - target 2

Далее "Mitm" (Man in the Middle) -> "ARP Poisoning" -> ставим флаг "Sniff remote connections" -> "OK".

Далее "Start" -> "Start sniffing".

Конец подготовки: SSLSplit

Далее в терминале ставим sslsplit:

Когда установка завершена, создаем директории:

И в текущей директории (где лежат файлы cert.pem и key.pem)

Выходим из аккаунта в приложении на телефоне.

В текущей директории выполняем:

Вводим phrase key, который указывали при создании сертификата.

В logfile.log будут записываться неполные логи (именно домен, адрес, порт), в директорию logs будут записываться подробные запросы, заголовки и ответы.

Далее авторизуемся в приложении и видим, как в терминале, в logfile.log и в директории logs появляются данные. Для остановки снифинга жмем в терминале Ctrl+C.

Логи в директории logs будут записываться под владельцем и группой root без доступа к чтению и записи от текущего пользователя. Поэтому нужно изменить владельца. В директории с сертификатами вводим

Где вместо "vlad805" - имя Вашего пользователя.

Далее можно просматривать файлы с помощью обычного текстового редактора.

Update

Как позже подсказал Антон, снифинг можно выполнить двумя кликами с помощью приложений для Android, и тогда вот эта длиннющая инструкция не понадобится. Но. кому как удобнее.

Благодарности

Также выражается благодарность Константину за наводку и подробную инструкцию по снифингу.

В начале года мы решили научиться хранить и читать отладочные логи ВКонтакте более эффективно, чем раньше. Отладочные логи — это, к примеру, логи конвертации видео (в основном вывод команды ffmpeg и список шагов по предварительной обработке файлов), которые иногда бывают нам нужны лишь спустя 2-3 месяца после обработки проблемного файла.

На тот момент у нас было 2 способа хранения и обработки логов — наш собственный logs engine и rsyslog, которые мы использовали параллельно. Стали рассматривать другие варианты и поняли, что нам вполне подходит ClickHouse от Яндекса — решили его внедрять.

В этой статье я расскажу о том, как мы начали использовать ClickHouse ВКонтакте, на какие грабли при этом наступили, и что такое KittenHouse и LightHouse. Оба продукта выложены в open-source, ссылки в конце статьи.

Задача сбора логов

Требования к системе:

Хранение сотен терабайт логов.
Хранение месяцами или (редко) годами.
Высокая скорость записи.
Высокая скорость чтения (чтение происходит редко).
Поддержка индексов.
Поддержка длинных строк (>4 Кб).
Простота эксплуатации.
Компактное хранение.
Возможность вставки с десятков тысяч серверов (UDP будет плюсом).

Возможные решения

Давайте вкратце перечислим варианты, которые мы рассматривали, и их минусы:

Logs Engine

– Умеет отдавать только последние N строк, которые помещаются в RAM.
– Не очень компактное хранение (нет прозрачного сжатия).

Hadoop

– Не во всех форматах есть индексы.
– Скорость чтения могла быть и выше (зависит от формата).
– Сложность настройки.
– Нет возможности вставки с десятков тысяч серверов (нужна Kafka или аналоги).

Rsyslog + файлы

– Нет индексов.
– Низкая скорость чтения (обычный grep/zgrep).
– Архитектурно не поддерживаются строки >4 Кб, по UDP ещё меньше (1,5 Кб).
± Компактное хранение достигается путем logrotate по крону

Мы использовали rsyslog как запасной вариант для долговременного хранения, но длинные строки обрезались, поэтому его сложно назвать идеальным.

LSD + файлы

– Нет индексов.
– Низкая скорость чтения (обычный grep/zgrep).
– Не особо расчитан на вставку с десятков тысяч серверов.
± Компактное хранение достигается путем logrotate по крону.

Отличия от rsyslog в нашем случае в том, что LSD поддерживает длинные строки, но для вставки с десятков тысяч серверов требуются существенные доработки внутреннего протокола, хотя это и можно сделать.

ElasticSearch

– Проблемы с эксплуатацией.
– Нестабильная запись.
– Нет UDP.
– Плохое сжатие.

ELK стек является уже почти промышленным стандартом для хранения логов. По нашему опыту — всё хорошо со скоростью чтения, а вот с записью бывают проблемы, например, во время слияния индексов.

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

ClickHouse

По большому счёту, единственное, что нас не устраивало в ClickHouse — отсутствие общения по UDP. По факту, из перечисленных вариантов оно было только у rsyslog, но при этом rsyslog не поддерживал длинные строки.

По остальным критериям ClickHouse нам подошел, и мы решили использовать его, а проблемы с транспортом решить в процессе.

Зачем нужен KittenHouse

Как Вы, наверное, знаете, ВКонтакте работает на PHP/KPHP, с «движками» (микросервисами) на C/C++ и немножко на Go. У PHP нет концепции «состояния» между запросами, кроме, возможно, общей памяти и открытых соединений.

Поскольку у нас десятки тысяч серверов, с которых мы хотим иметь возможность отправлять логи в ClickHouse, держать открытым соединения из каждого PHP-worker'а было бы накладно (на каждый сервер может приходиться по 100+ воркеров). Поэтому нам нужен какой-то прокси между ClickHouse и PHP. Мы назвали этот прокси KittenHouse.

KittenHouse, v1

Сначала решили попробовать как можно более простую схему, чтобы понять, будет наш подход работать или нет. Если Вам на ум при решении этой задачи приходит Kafka, то Вы не одиноки. Мы, однако, не хотели использовать дополнительные промежуточные сервера — в этом случае можно было легко упереться в производительность этих серверов, а не самого ClickHouse. К тому же, мы собирали логи и нам нужна была предсказуемая и небольшая задержка вставки данных. Схема выглядит следующим образом:

Возможности KittenHouse, v1

Первая версия KittenHouse умела довольно мало, однако для тестов этого было достаточно:

Общение через наш RPC (TL Scheme).
Поддержание 1 TCP/IP соединения на сервер.
Буферизация в памяти по умолчанию, с ограниченным размером буфера (остальное выбрасывается).
Возможность записи на диск, в этом случае есть гарантия доставки (не менее одного раза).
Интервал вставки — раз в 2 секунды.

Первые проблемы

С первой проблемой мы столкнулись, когда «погасили» ClickHouse сервер на несколько часов и потом включили обратно. Ниже можно видеть load average на сервере после того, как он «поднялся»:

Объясняется это довольно просто: у ClickHouse модель работы по сети — thread per connection, поэтому при попытке сделать INSERT с тысячи узлов одновременно, началась очень сильная конкуренция за ресурсы CPU и сервер еле отвечал. Тем не менее, все данные в конечном счёте вставились и ничего не упало.

Для решения этой проблемы мы поставили nginx перед ClickHouse и, в целом, это помогло.

Дальнейшее развитие

В процессе эксплуатации столкнулись ещё с некоторым количеством проблем, в основном связанных не с ClickHouse, а с нашим способом его эксплуатации. Вот ещё грабли, на которые мы наступили:

Большое количество «кусков» у Buffer таблиц приводит к частым сбросам буфера в MergeTree

В нашем случае было 16 кусков буфера и интервал сброса раз в 2 секунды, а таблиц 20 штук, что давало до 160 вставок в секунду. Это периодически очень плохо сказывалось на производительности вставки — появлялось много фоновых слияний и утилизация дисков достигала 80% и выше.

Решение: увеличили интервал сброса буфера по умолчанию, уменьшили число кусков до 2.

Nginx отдает 502, когда заканчиваются соединения с upstream

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

Начала заканчиваться память при интенсивной вставке

Мы читаем только из 50 случайных соединений одновременно, поэтому, благодаря TCP/IP, остальные клиенты «ждут» и мы не расходуем память на буферы, пока до соответствующих клиентов не дошла очередь. Это сократило потребление памяти минимум в 20 раз, и больше подобных проблем у нас не было.

ALTER таблиц может идти долго, если есть долгие запросы

У ClickHouse неблокирующий ALTER — в том смысле, что он не мешает выполняться как SELECT-запросам, так и INSERT-запросам. Но ALTER не может начаться, пока не закончили исполняться запросы в эту таблицу, отправленные до ALTER.

Если у вас на сервере есть фон «долгих» запросов в какие-нибудь таблицы, то вы можете столкнуться с ситуацией, что ALTER на эту таблицу не будет успевать выполняться за дефолтный таймаут в 60 секунд. Но это не значит, что ALTER не пройдет: он выполнится, как только закончат выполняться те самые SELECT-запросы.

Это означает, что вы не знаете, в какой на самом деле момент времени произошел ALTER, и у вас нет возможности автоматически пересоздать Buffer-таблицы, чтобы их схема всегда была одинаковой. Это может приводить к проблемам при вставке.

Решение: Планируем в итоге полностью отказаться от использования буферных таблиц. В целом, у буферных таблиц есть сфера применения, мы пока используем их и не испытываем огромных проблем. Но сейчас мы наконец дошли до момента, когда проще реализовать функциональность буферных таблиц на стороне reverse proxy, чем продолжать мириться с их недостатками. Примерная схема будет выглядеть вот так (пунктирной линией показана асинхронность ACK на INSERT).

Чтение данных

Допустим, мы разобрались со вставкой. Как читать эти логи из ClickHouse? К нашему сожалению, удобных и простых в эксплуатации инструментов для чтения сырых данных (без построения графиков и прочего) из ClickHouse мы не нашли, поэтому написали своё решение — LightHouse. Его возможности довольно скромные:

Быстрый просмотр содержимого таблиц.
Фильтрация, сортировка.
Редактирование SQL-запроса.
Просмотр структуры таблицы.
Показ примерного количества строк и занимаемого на диске места.

Просмотр структуры таблицы

Фильтрация содержимого

Результаты

ClickHouse — практически единственная open-source база данных, которая «прижилась» ВКонтакте. Мы довольны скоростью её работы и готовы мириться с недостатками, о которых ниже.

Сложности в работе

В целом, ClickHouse — очень стабильная база данных и очень быстрая. Однако, как и с любым продуктом, особенно таким молодым, есть особенности в работе, которые нужно учитывать:

Open-source

KittenHouse и LightHouse теперь доступны в open-source в нашем github-репозитории:

Юрий Насретдинов, разработчик в отделе backend-инфраструктуры ВКонтакте

Вы еще не слышали о секретном меню, которое имеется в стандартном клиенте приложения? Тогда читайте внимательно: наша информация вас порадует, а инструкция поможет «исчезнуть» в нужный момент. Самое приятное — это то, что для включения режима невидимки не нужны даже ROOT-права на устройство (всё уже есть в меню официального приложения — в «режиме отладки»).

Пошаговая инструкция включения режима «невидимки»:

Открываем официальный клиент VK;
Заходим в «Настройки» —> далее «О программе» (должно появиться изображение «собаки» на фоне разноцветных квадратов;

Примечание: Если после набора кода (п.7) ничего не произошло, то необходимо воспользоваться программой Secret Codes .

Дополнительная возможность: Также, помимо включения режима «Невидимки», в том же секретном меню можно отключить рекламу — найти пункт «Отключить рекламу» и отметить его галочкой.

Совет: Остальные пункты желательно не трогать, чтобы не сбить функционирование самого клиента.

Читайте также: