Какая для банка разница между таким клиентом и "обычным клиентом" (т.е. налоговым резидентом)?
Например, любой банк является налоговым агентом по брокерскому обслуживанию и обязан сам начислять налог от инвестиционного дохода. Насколько я знаю, ставка этого налога зависит от резидентства.
Это я уже сливаю данные сервису Yandex или просто стучу куда взбредёт в сугубо личных целях?
Да, вы используете сервис яндекса.
Имея миллиарды устройств, которые регулярно шлют пустые запросы на мой сервер из самых разнообразных узлов, у меня есть доступ к данным IP пакетов и различным временным показателям (типа открытия соединения), а, соответственно, возможность изучать динамику ведроида в разных странах и городах, возможность изучать минимальную топологию сетей, в т.ч. за NAT-ами, узнавать о делегировании новых диапазонов, оценивать скорость сетей и собирать массу другой статистики.
Это всё не данные? Это не пользователи сервиса гугла их гуглу предоставляют?
Какой адрес, кроме своих, должны были использовать инженеры гугла?
Вы точно читаете, что я пишу? В четвёртый раз повторяю свой тезис:
AOSP использует некоторые сервисы гугла
Это не значит, что гугл сделал это исходя из невероятно злобных намерений, это не значит, что на эти сервисы уходит чувствительная информация, это не значит, что всем нужно срочно дропать AOSP или менять эти параметры.
Это значит, что AOSP использует некоторые сервисы гугла.
Вы привели что в исходниках есть адрес сервера гугла.
Да, привёл, как пример того, что AOSP использует сервисы гугла. Это утверждение, которое подкреплено конкретным кодом. Как из моих слов можно вывести следствие:
инженеры гугла должны были запихнуть туда чужой адрес
Посмотрите метод sendHttpProbe по ссылке и ещё аналогичное есть в NetworkMonitor. Не стоит триггериться на "сливают", это не подразумевает однозначное злонамеренное использование ваших данных, геолокации или сетевых настроек, это просто говорит о том, что какие-то ваши данные попадают на сервера гугла. Может они там честно и моментально девналятся, а может логгируются и потом участвуют в big data анализах.
Но весьма вероятно что эти специально обученные люди возьмут за это баксов 200 (и не забудут взять еще 100 за шланги, которые автор купил за 80).
И это всё равно будет дешевле, чем 4 часа автора.
есть вероятность что если вдруг ему придется передвигать машинку (ну будет делать ремонт, например), то он сможет сам передвинуть машинку
К этому моменту, все эти аспекты прошлой установки благополучно забываются, потому что они были 2-3 года назад и, без периодических тренировок, проходятся как в первый раз.
Один пакет (фейковый, с рукопожатием) - для ТСПУ. Остальные - нефейковые.
И все эти пакеты, как фейковые, так и не фейковые проходят и через ТСПУ и через маршрутизатор провайдера. Зачем их сравнивать и зачем для этого логи dhcp провайдера - остаётся вопросом.
А для чего, по-вашему, ещё может быть нужен доступ к логам провайдера?
Чтобы привязать конкретный трафик на ТСПУ к конкретному договору с провайдером, а значит и к пользователю.
Чтобы по ней идентифицировать конкретного абонента, нужно знать
Чтобы по ней идентифицировать конкретного абонента для серых ip, нужно заставить провайдера дампить и выгружать NAT таблицу, помимо dhcp логов.
Ещё раз - каким образом это всё позволяет сделать так, чтобы на разных маршрутизаторах по пути представить разное содержимое одного и того же пакета?
Бред какой-то несёте. Упомянутый fake request mode в goodbyedpi не делает пакет магическим. Наличие ТСПУ в локальной сети провайдера, в подавляющем большинстве сетевых конфигураций, никак не поможет узнать серый ip абонентов. Какие-то ещё сопоставления айпишников до и после ТСПУ, поиск трафика на ТСПУ по логам dhcp сервера провайдера (фактически, именно это и пытается выбить ркн) - одна история прохладнее другой.
Оборудование пользователя модифицирует трафик таким образом, что в зависимости от хопа, через который проходит трафик, разному промежуточному оборудованию подсовываются разные варианты
Это вообще звучит фантастически. Отправитель IP пакета может сделать так, чтобы разные маршрутизаторы на пути пакета видели разное содержимое пакета? Может примеры какие-то есть?
Например, любой банк является налоговым агентом по брокерскому обслуживанию и обязан сам начислять налог от инвестиционного дохода. Насколько я знаю, ставка этого налога зависит от резидентства.
И не переставал, вроде. Вы хоть посмотрите на что отвечаете.
Да, вы сливаете данные сервису, я вроде вполне доступно даже объяснил, что это за данные.
Не очень понимаю, какое тут может быть различие в терминах, но, если необходимо, можем взять определение из этой статьи
https://en.wikipedia.org/wiki/Server_(computing)
Да, вы используете сервис яндекса.
Имея миллиарды устройств, которые регулярно шлют пустые запросы на мой сервер из самых разнообразных узлов, у меня есть доступ к данным IP пакетов и различным временным показателям (типа открытия соединения), а, соответственно, возможность изучать динамику ведроида в разных странах и городах, возможность изучать минимальную топологию сетей, в т.ч. за NAT-ами, узнавать о делегировании новых диапазонов, оценивать скорость сетей и собирать массу другой статистики.
Это всё не данные? Это не пользователи сервиса гугла их гуглу предоставляют?
Ну да. А что, это не использование чьих-либо сервисов?
Понял, спасибо
Как именно это противоречит моему тезису? Действительно, многие форки AOSP меняют эти сервера на свои.
Да, именно так. В чём противоречие?
Вы точно читаете, что я пишу? В четвёртый раз повторяю свой тезис:
Это не значит, что гугл сделал это исходя из невероятно злобных намерений, это не значит, что на эти сервисы уходит чувствительная информация, это не значит, что всем нужно срочно дропать AOSP или менять эти параметры.
Это значит, что AOSP использует некоторые сервисы гугла.
Да, привёл, как пример того, что AOSP использует сервисы гугла. Это утверждение, которое подкреплено конкретным кодом. Как из моих слов можно вывести следствие:
?
Аналогично, несите, пожалуйста, цитаты фигни.
Я где-то утверждал подобное? Процитируйте, пожалуйста
Посмотрите метод sendHttpProbe по ссылке и ещё аналогичное есть в NetworkMonitor. Не стоит триггериться на "сливают", это не подразумевает однозначное злонамеренное использование ваших данных, геолокации или сетевых настроек, это просто говорит о том, что какие-то ваши данные попадают на сервера гугла. Может они там честно и моментально девналятся, а может логгируются и потом участвуют в big data анализах.
И это всё равно будет дешевле, чем 4 часа автора.
К этому моменту, все эти аспекты прошлой установки благополучно забываются, потому что они были 2-3 года назад и, без периодических тренировок, проходятся как в первый раз.
Спасибо, я в курсе. Речь шла про то, что в AOSP используются сервисы гугла.
Справедливости ради, несколько небольших ушей гугла, сливающих данные, там всё-таки видно, типа:
https://cs.android.com/android/platform/superproject/main/+/main:packages/modules/NetworkStack/src/com/android/networkstack/util/NetworkStackUtils.java?q=https:%2F%2Fwww.google.com%2Fgenerate_204
И что? Как логи dhcp сервера помогут что-то проанализировать с этим пакетом?
Не вижу ничего подобного в комментарии по ссылке.
И все эти пакеты, как фейковые, так и не фейковые проходят и через ТСПУ и через маршрутизатор провайдера. Зачем их сравнивать и зачем для этого логи dhcp провайдера - остаётся вопросом.
Чтобы привязать конкретный трафик на ТСПУ к конкретному договору с провайдером, а значит и к пользователю.
Чтобы по ней идентифицировать конкретного абонента для серых ip, нужно заставить провайдера дампить и выгружать NAT таблицу, помимо dhcp логов.
Откатает на белых ip и попросит.
Ещё раз - каким образом это всё позволяет сделать так, чтобы на разных маршрутизаторах по пути представить разное содержимое одного и того же пакета?
Бред какой-то несёте. Упомянутый fake request mode в goodbyedpi не делает пакет магическим. Наличие ТСПУ в локальной сети провайдера, в подавляющем большинстве сетевых конфигураций, никак не поможет узнать серый ip абонентов. Какие-то ещё сопоставления айпишников до и после ТСПУ, поиск трафика на ТСПУ по логам dhcp сервера провайдера (фактически, именно это и пытается выбить ркн) - одна история прохладнее другой.
И как это помогает сделать так, чтобы на разных маршрутизаторах по пути представить разное содержимое одного и того же пакета?
Это вообще звучит фантастически. Отправитель IP пакета может сделать так, чтобы разные маршрутизаторы на пути пакета видели разное содержимое пакета? Может примеры какие-то есть?