Кого-то просто не было, кому-то мешал юный возраст, кому-то отсутствие допусков к военной сети США, поэтому "разрабов почтовика" на тот момент было человек 5, каждый со своим стандартом и нужен был стандарт который был бы обратно совместим со всеми. RFC 724 где фиксируется примерно такой формат заголовков для ARPA написан в 1977м году , более новые RFC писались (в основном) с обратной совместимостью с предшественниками, в т.ч. и первый стандарт для интернет RFC 822 в 1982м, потому что одномоментно переключить всех на новый стандарт невозможно.
Тогда письмо показывалось в текстовой форме и заголовки показывались "как есть", поэтому стандарт в основном определял как сгенерировать заголовки чтобы они были более-менее унифромными и читаемы для человека, а не как их машинно-распарсить + было несколько почтовых сетей со своими стандартами и нужен был стандарт который был бы обратно совместим со всеми.
оба формата валидны, в вашем примере John Doe это не отображаемое имя пользователя как в примере выше, а комментарий. В такой форме письма генерировал юниксовый mail (и до сих пор в некоторых системах так делает), комментарий генерируется по GECOS из /etc/passwd, в общем случае это был именно комментарий, он помимо имени может содержать много чего еще.
From: "John Doe" <john@example.com> (John Doe, system administrator, 712345678901 some street)
Они, небось, для обучения распарсили какой-нибудь stackoveflow. Осталось научить вопросы там же задавать если нужного кода не нашлось - и программа обгонит 90% программистов. 95% если на питоне.
Проблемы возникнут не в QUIC - он "из коробки" готов к конкуренции за записи в NAT-таблице, а в других UDP-протоколах. Скорей всего, в итоге многие UDP протоколы придется адаптировать под короткое (менее минуты) время жизни маппинга, т.е. фактически добавлять зачатки транспорта поверх UDP из-за того что QUIC это по сути транспорт поверх UDP и с ним надо конкурировать за ресурсы. Именно поэтому со стороны QUIC использование UDP вместо собственного транспортного ротокола это перекладывание проблемы с больной головы на здоровую.
Проблема в том, что QUIC не транспортный протокол, транспортный протокол UDP. NAT это зло, но пока оно неизбежно. Ограничения UDP и NAT возникают из свойств UDP, а не QUIC, в лучшем случае размер NAT таблицы ограничен количеством UDP портов. Операторы могут либо расширять внешние диапазоны NAT чтобы не допускать падения времени жизни маппингов, что требует и оборудования и новых IP адресов, которых брать негде, либо заворачивать трафик в QUIC прокси, что убьет преимущества в скорости либо забить на проблему, потому что большая часть пользвоателей ничего не заметит. Сильней (и скорей всего неожиданней для себя) с проблемой столкнутся администраторы небольших (например офисных) роутеров с одним внешним адресом на каком-нибудь специфичном софт поверх UDP. Даже в OpenVPN дефолтные кипэлайвы сейчас порядка минут и их скорей всего придется снижать.
На самом деле в quic по умолчанию должен идти пинг-пакет каждые 15 секунд, что существенно митигирует проблему для самого quic, но поскольку реализация quic фактически унесена на прикладной уровень, очень сложно сказать что там будет происходить на самом деле.
Кстати ниже жалобы что "в чате что-то написали, а появляется только после обновления", это может быть резутатом того что вебсокеты переключили на QUIC, чего делать ни в коем случае нельзя из-за маленьких таймаутов на UDP-маппинги.
С QUIC есть нерешенная проблема, которая имеет все шансы выстрелить по мере того, как он становится более популярным. В IPv4 подавляющее количество пользователей приходят на конечный сервер через NAT, или провайдера или свой собственный. Особых альтернатив кроме перехода на IPv6 нет, тк адреса кончились. А девайсов за натом все больше, потому что интернет вещей. Размер любой NAT таблицы ограничен, а для UDP, из-за отсутствия закрытия сессии, маппинг может пропасть только по таймауту, поддержки QUIC на уровне NAT пока не видно. Это значит что постепенно из-за ограниченных размеров таблиц время жизни маппингов будет падать и клиенты одного NAT будут конкурировать не только за канал, но и за места в таблице трансляций. При этом сам QUIC достаточно "живуч" и учтойчив к пропаданию маппингов, но вот другие протоколы, типа того же голоса, игр, да и DNS тоже, могут серьезно пострадать. Уже сейчас видно что у некоторых провайдеров время UDP маппингов упало до нескольких секунд и есть жалобы. Поэтому QUIC в какой-то степени переложил проблемы с больной головы на здоровую. Вангую, что первыми начнут резать QUICK сотовые операторы.
Сотрудник указал на проблему - что на нем лежит слишком много работы и попросил за это больше денег. Руководитель понял что проблема не в том, что человек мало получает, а в том что на человеке слишком много работы, решил вместо него поставить троих а ему предложил адекватный (меньший) объем работы за те же деньги. Если выкинуть сентименты и аллюзии с железным человеком, то решение руководителя абсолютно правильное, люди не должны выматываться и работать на износ. Сотрудник решил что это личное и его не ценят, хотя ничто на это не указывает, ему предложили адекватные нормальные условия.
Нельзя быть незаменимым, если в компании возникает незаменимый человек, это означает только плохую работу руководителя, даже если незаменимый человек это сам руководитель. Это узкое место которое надо устранять - любые бизнес-процессы должны быть масштабируемы. Фактически, Маску указали на его управленческую ошибку и он ее исправил самым очевидным (для руководителя) способом.
В покере больше шансов на выигрыш у того, кто обладает большей информацией, здесь у всех сторон есть полная информация, но в общем случае не известны цели других игроков и насколько адекватно игроки принимают решения. В общем случае правильная стратегия - не вступать в игру.
По факту, надо уходить на 1 долларе, и то при условии что все стороны ведут себя оптимально (с точки зрения теории игр), смотрите комментарий выше. Не надо оценивать ход, надо оценвать стратегию, стратегия которая привела вас к ставке в 17 долларов приведет к проигрышу.
А что бы вы сделали, если бы были вторым со ставкой 18 долларов, а ставка вашего соперника равнялась бы 19 долларам? Что лучше — потерять 19 долларов или сделать ставку 20 долларов и выйти в ноль?
С точки зрения теории игр, это вполне решаемая задача, должен быть (и оцениваться) не отдельный ход, а стратегия игры. Выиграть может только один игрок. Если рассматривать только финансовую оценку, то при условии что все стороны ведут себя оптимально - первый игрок выигрывает, оптимальная выигрышная стратегия первым ходом сделать ставку в 1 доллар. Второго игрока в таких условиях появиться не должно, т.к. для двух игроков выигрышной стратегии нет. Если считать, что другие игроки "глупы" (не имеют стратегии и стараются максимизировать выигрыш за 1 ход) то надо делать ставку 19, т.к. она делает любую одноходовую стратегию безвыигрышной. Если учитывать еще и фактор "вредности" (что при прочих равных другой игрок стремится минимизировать ваш выигрыш) или то, что другие игроки ведут себя просто неразумно, например руководствуются не финансовой целевой функцией, а хотят посорить деньгами, то выигрышной стратегии нет. Оптимальная стратегия в таком случае, приводящая к гарантированному результату - не начинать игру. Осмысленная стратегия к ситуации когда один игрок сделал ставку 18 а другой 19 привести не может.
Если то, что один сделал ставку 18 а второй 19 рассматривать как начальные усолвия игры, то самая правильная стратегия - выйти из игры как можно раньше (т.е. согласиться на потерю 18).
Не знаю серьезно вы или нет, но gopher может работать через HTTP(s) и SOCKS прокси, а вот специального application-specific типа прокси для него не предусмотрено, там host в протоколе не передается.
да, и, разумеется, то что SOCKS прокси не может править HTTP-заголовки это тоже не так, в 3proxy можно поменять или добавить заголовки для клиента подключающегося по SOCKS. SOCKS это просто интерфейс подключения клиента, дальше с траффиком можно делать все что угодно если он не шифрован или если можно его дешифровать, вопрос исключительно в реализации i2pd.
У вас на скриншоте Firefox получает css. CSS позволяет фингерпринтить браузер через media query без всякого JS. Чтобы минимизировать такие риски TorBrowser (вы же с tor сраниваете) например стартует с рандомным размером окна и рандомизирует несколько других параметров, чтобы фингерпринт получался разным при разных запусках.
Если у вас в браузере прописан только HTTP прокси, то переход в некоторые протоколы (например в HTTP/3 или использование WebRTC, если опять же используется браузер "общего назначения") приведет к раскрытию реального адреса, потому что запрос просто не уйдет в прокси (и, как следствие, в I2P). С SOCKS кстати такие риски несколько ниже + тот же tor browser правильно конфигурирует тор в качестве прокси и отключает поддержку WebRTC. Инициировать все это может тот сайт i2p от которого вы прячетесь, точно так же он может инициировать и запрос по протоколам отличным от http.
Поэтому гораздо важней НЕ использовать tor или i2p через обычный браузер, точно так же как НЕ использвоать их для обычного браузинга. Вырезание User-Agent в противном случае это просто смешно. Даже по невырезанным заголовкам Transfer-Encoding можно вычислить браузер, кстати.
В случае I2p надо не подменять User-Agent а написать свой браузер MYOB/6.66 в котором будет функциональности сильно меньше чем в IE6, никакая информация о клиенте не будете утекать by design и все запросы опять же by design будут идти в i2p и только по http.
В этой статье чудесно все, спасибо. Сделал для себя выводы:
Использовать User-Agent "MYOB/6.66 (AN/ON)" вместо юзерагента Google Chrome актуальной версии под Windows это конечно же лучший способ выглядеть незаметно, чтобы никто не мог идентифицировать. Штирлиц шел по улицам Берлина в белом маскировочном халате прикрытом еловыми ветками, стараясь выглядеть незаметно.
Замаскировать User-Agent для сайта который может получить информацию о клиенте (и еще кучу параметров, включая версии движка, разрешения экрана и тп) через JS это супер-важно. А главное подменить User-Agent в браузере совершенно нереально.
Читать версию сайта рассчитанную на ботов и пользователей Internet Explorer 6 гораздо интересней, чем ту версию сайта, которая рассчитана на актуальные браузеры (потому что на сервер-сайде для выбора какую версию отдавать как раз таки User-Agent и используется).
http сейчас это сверх-актуальный протокол потому что https (в котором прокси ничего не знает про передаваемые заголовки и не может их поменять) ушел в небытие.
Ходить на сайты без шифрования обязательно следует через tor или i2p. Без них наш трафик видит плохой провайдер и товарищ майор, которые все свое свободное время только сниффингом и занимаются, а с tor и i2p всего лишь хороший добрый человек поднявший exit node с очевидно альтруистическими намерениями, что он может сделать плохого? Он же явно не будет всякую бяку подсовывать в страничку
i2p с тором как раз и нужны же для того чтобы через них всегда ходить своим любимым фаерфоксом. И фейсбучики с твиттерами читать и параллельно анонимность соблюдать.
P.S. (sarcasm off) использовать http(s)-прокси вместо сокс действительно может быть эффективней, там где его хватает, но по совершенно другой причине - у http(s) прокси хендшейк короче, но в случае когда и прокси и клиент на одной машине это мало на что влияет.
Использую PAC-файл, никаких дополнительных расширений при этом не требуется. Работает в любом браузере. Прописывается как URL автоконфигурации в настройках прокси, для Window URL выглядит примерно так:
file:///c:/путь/proxy.pac
сам файл: function FindProxyForURL(url, host)
С poll() или WaitForMultipleObjects() не путаете? В epoll_event как раз есть epoll_data и можно обойтись без деревьев. Скорей не хватает возможности poll'ить семафоры.
Кого-то просто не было, кому-то мешал юный возраст, кому-то отсутствие допусков к военной сети США, поэтому "разрабов почтовика" на тот момент было человек 5, каждый со своим стандартом и нужен был стандарт который был бы обратно совместим со всеми. RFC 724 где фиксируется примерно такой формат заголовков для ARPA написан в 1977м году , более новые RFC писались (в основном) с обратной совместимостью с предшественниками, в т.ч. и первый стандарт для интернет RFC 822 в 1982м, потому что одномоментно переключить всех на новый стандарт невозможно.
Тогда письмо показывалось в текстовой форме и заголовки показывались "как есть", поэтому стандарт в основном определял как сгенерировать заголовки чтобы они были более-менее унифромными и читаемы для человека, а не как их машинно-распарсить + было несколько почтовых сетей со своими стандартами и нужен был стандарт который был бы обратно совместим со всеми.
оба формата валидны, в вашем примере John Doe это не отображаемое имя пользователя как в примере выше, а комментарий. В такой форме письма генерировал юниксовый mail (и до сих пор в некоторых системах так делает), комментарий генерируется по GECOS из /etc/passwd, в общем случае это был именно комментарий, он помимо имени может содержать много чего еще.
From: "John Doe" <john@example.com> (John Doe, system administrator, 712345678901 some street)В целом формат подразумевался примерно такой
Где конкретно в евросоюзе англоязычная аудитория?
Они, небось, для обучения распарсили какой-нибудь stackoveflow. Осталось научить вопросы там же задавать если нужного кода не нашлось - и программа обгонит 90% программистов. 95% если на питоне.
Гугл скорей всего непричем, разлоломали обновлением самого Noscript
Проблемы возникнут не в QUIC - он "из коробки" готов к конкуренции за записи в NAT-таблице, а в других UDP-протоколах. Скорей всего, в итоге многие UDP протоколы придется адаптировать под короткое (менее минуты) время жизни маппинга, т.е. фактически добавлять зачатки транспорта поверх UDP из-за того что QUIC это по сути транспорт поверх UDP и с ним надо конкурировать за ресурсы. Именно поэтому со стороны QUIC использование UDP вместо собственного транспортного ротокола это перекладывание проблемы с больной головы на здоровую.
Проблема в том, что QUIC не транспортный протокол, транспортный протокол UDP. NAT это зло, но пока оно неизбежно. Ограничения UDP и NAT возникают из свойств UDP, а не QUIC, в лучшем случае размер NAT таблицы ограничен количеством UDP портов. Операторы могут либо расширять внешние диапазоны NAT чтобы не допускать падения времени жизни маппингов, что требует и оборудования и новых IP адресов, которых брать негде, либо заворачивать трафик в QUIC прокси, что убьет преимущества в скорости либо забить на проблему, потому что большая часть пользвоателей ничего не заметит. Сильней (и скорей всего неожиданней для себя) с проблемой столкнутся администраторы небольших (например офисных) роутеров с одним внешним адресом на каком-нибудь специфичном софт поверх UDP. Даже в OpenVPN дефолтные кипэлайвы сейчас порядка минут и их скорей всего придется снижать.
На HTTP/2 переехали (RFC8441), по крайней мере Chrome использует его по умолчанию при наличии уже установленного соединения. По HTTP/3 пока похоже нет, но скоро будут https://datatracker.ietf.org/doc/draft-hamilton-httpbis-h3-websockets/
На самом деле в quic по умолчанию должен идти пинг-пакет каждые 15 секунд, что существенно митигирует проблему для самого quic, но поскольку реализация quic фактически унесена на прикладной уровень, очень сложно сказать что там будет происходить на самом деле.
Кстати ниже жалобы что "в чате что-то написали, а появляется только после обновления", это может быть резутатом того что вебсокеты переключили на QUIC, чего делать ни в коем случае нельзя из-за маленьких таймаутов на UDP-маппинги.
С QUIC есть нерешенная проблема, которая имеет все шансы выстрелить по мере того, как он становится более популярным. В IPv4 подавляющее количество пользователей приходят на конечный сервер через NAT, или провайдера или свой собственный. Особых альтернатив кроме перехода на IPv6 нет, тк адреса кончились. А девайсов за натом все больше, потому что интернет вещей. Размер любой NAT таблицы ограничен, а для UDP, из-за отсутствия закрытия сессии, маппинг может пропасть только по таймауту, поддержки QUIC на уровне NAT пока не видно. Это значит что постепенно из-за ограниченных размеров таблиц время жизни маппингов будет падать и клиенты одного NAT будут конкурировать не только за канал, но и за места в таблице трансляций. При этом сам QUIC достаточно "живуч" и учтойчив к пропаданию маппингов, но вот другие протоколы, типа того же голоса, игр, да и DNS тоже, могут серьезно пострадать. Уже сейчас видно что у некоторых провайдеров время UDP маппингов упало до нескольких секунд и есть жалобы. Поэтому QUIC в какой-то степени переложил проблемы с больной головы на здоровую. Вангую, что первыми начнут резать QUICK сотовые операторы.
Сотрудник указал на проблему - что на нем лежит слишком много работы и попросил за это больше денег. Руководитель понял что проблема не в том, что человек мало получает, а в том что на человеке слишком много работы, решил вместо него поставить троих а ему предложил адекватный (меньший) объем работы за те же деньги. Если выкинуть сентименты и аллюзии с железным человеком, то решение руководителя абсолютно правильное, люди не должны выматываться и работать на износ. Сотрудник решил что это личное и его не ценят, хотя ничто на это не указывает, ему предложили адекватные нормальные условия.
Нельзя быть незаменимым, если в компании возникает незаменимый человек, это означает только плохую работу руководителя, даже если незаменимый человек это сам руководитель. Это узкое место которое надо устранять - любые бизнес-процессы должны быть масштабируемы. Фактически, Маску указали на его управленческую ошибку и он ее исправил самым очевидным (для руководителя) способом.
В покере больше шансов на выигрыш у того, кто обладает большей информацией, здесь у всех сторон есть полная информация, но в общем случае не известны цели других игроков и насколько адекватно игроки принимают решения. В общем случае правильная стратегия - не вступать в игру.
По факту, надо уходить на 1 долларе, и то при условии что все стороны ведут себя оптимально (с точки зрения теории игр), смотрите комментарий выше. Не надо оценивать ход, надо оценвать стратегию, стратегия которая привела вас к ставке в 17 долларов приведет к проигрышу.
С точки зрения теории игр, это вполне решаемая задача, должен быть (и оцениваться) не отдельный ход, а стратегия игры. Выиграть может только один игрок. Если рассматривать только финансовую оценку, то при условии что все стороны ведут себя оптимально - первый игрок выигрывает, оптимальная выигрышная стратегия первым ходом сделать ставку в 1 доллар. Второго игрока в таких условиях появиться не должно, т.к. для двух игроков выигрышной стратегии нет. Если считать, что другие игроки "глупы" (не имеют стратегии и стараются максимизировать выигрыш за 1 ход) то надо делать ставку 19, т.к. она делает любую одноходовую стратегию безвыигрышной. Если учитывать еще и фактор "вредности" (что при прочих равных другой игрок стремится минимизировать ваш выигрыш) или то, что другие игроки ведут себя просто неразумно, например руководствуются не финансовой целевой функцией, а хотят посорить деньгами, то выигрышной стратегии нет. Оптимальная стратегия в таком случае, приводящая к гарантированному результату - не начинать игру. Осмысленная стратегия к ситуации когда один игрок сделал ставку 18 а другой 19 привести не может.
Если то, что один сделал ставку 18 а второй 19 рассматривать как начальные усолвия игры, то самая правильная стратегия - выйти из игры как можно раньше (т.е. согласиться на потерю 18).
Не знаю серьезно вы или нет, но gopher может работать через HTTP(s) и SOCKS прокси, а вот специального application-specific типа прокси для него не предусмотрено, там host в протоколе не передается.
да, и, разумеется, то что SOCKS прокси не может править HTTP-заголовки это тоже не так, в 3proxy можно поменять или добавить заголовки для клиента подключающегося по SOCKS. SOCKS это просто интерфейс подключения клиента, дальше с траффиком можно делать все что угодно если он не шифрован или если можно его дешифровать, вопрос исключительно в реализации i2pd.
Боюсь, что вы не поняли о чем сарказм.
У вас на скриншоте Firefox получает css. CSS позволяет фингерпринтить браузер через media query без всякого JS. Чтобы минимизировать такие риски TorBrowser (вы же с tor сраниваете) например стартует с рандомным размером окна и рандомизирует несколько других параметров, чтобы фингерпринт получался разным при разных запусках.
Если у вас в браузере прописан только HTTP прокси, то переход в некоторые протоколы (например в HTTP/3 или использование WebRTC, если опять же используется браузер "общего назначения") приведет к раскрытию реального адреса, потому что запрос просто не уйдет в прокси (и, как следствие, в I2P). С SOCKS кстати такие риски несколько ниже + тот же tor browser правильно конфигурирует тор в качестве прокси и отключает поддержку WebRTC. Инициировать все это может тот сайт i2p от которого вы прячетесь, точно так же он может инициировать и запрос по протоколам отличным от http.
Поэтому гораздо важней НЕ использовать tor или i2p через обычный браузер, точно так же как НЕ использвоать их для обычного браузинга. Вырезание User-Agent в противном случае это просто смешно. Даже по невырезанным заголовкам Transfer-Encoding можно вычислить браузер, кстати.
В случае I2p надо не подменять User-Agent а написать свой браузер MYOB/6.66 в котором будет функциональности сильно меньше чем в IE6, никакая информация о клиенте не будете утекать by design и все запросы опять же by design будут идти в i2p и только по http.
В этой статье чудесно все, спасибо. Сделал для себя выводы:
Использовать User-Agent "MYOB/6.66 (AN/ON)" вместо юзерагента Google Chrome актуальной версии под Windows это конечно же лучший способ выглядеть незаметно, чтобы никто не мог идентифицировать. Штирлиц шел по улицам Берлина в белом маскировочном халате прикрытом еловыми ветками, стараясь выглядеть незаметно.
Замаскировать User-Agent для сайта который может получить информацию о клиенте (и еще кучу параметров, включая версии движка, разрешения экрана и тп) через JS это супер-важно. А главное подменить User-Agent в браузере совершенно нереально.
Читать версию сайта рассчитанную на ботов и пользователей Internet Explorer 6 гораздо интересней, чем ту версию сайта, которая рассчитана на актуальные браузеры (потому что на сервер-сайде для выбора какую версию отдавать как раз таки User-Agent и используется).
http сейчас это сверх-актуальный протокол потому что https (в котором прокси ничего не знает про передаваемые заголовки и не может их поменять) ушел в небытие.
Ходить на сайты без шифрования обязательно следует через tor или i2p. Без них наш трафик видит плохой провайдер и товарищ майор, которые все свое свободное время только сниффингом и занимаются, а с tor и i2p всего лишь хороший добрый человек поднявший exit node с очевидно альтруистическими намерениями, что он может сделать плохого? Он же явно не будет всякую бяку подсовывать в страничку
i2p с тором как раз и нужны же для того чтобы через них всегда ходить своим любимым фаерфоксом. И фейсбучики с твиттерами читать и параллельно анонимность соблюдать.
P.S. (sarcasm off) использовать http(s)-прокси вместо сокс действительно может быть эффективней, там где его хватает, но по совершенно другой причине - у http(s) прокси хендшейк короче, но в случае когда и прокси и клиент на одной машине это мало на что влияет.
<img src="http://mybooklive/api/1.0/rest/language_configuration...">
вполне эксплуатируется за фаерволом и вполне может быть, что на тех же форумах или прямо тут на хабре
file:///c:/путь/proxy.pac
сам файл:
function FindProxyForURL(url, host)
{
var domains = [
"visualwebsiteoptimizer.com",
"amazonaws.com",
"tribl.io",
"olark.com",
"linkedin.com",
"archive.org",
"telegram.org",
"telegram.me",
"t.me",
"slideshare.net",
"lurkmore.to",
"upyachka.io",
"protonmail.com",
"anonfiles.com"
];
var len = domains.length, i;
if(isInNet(dnsResolve(host), "5.3.3.0", "255.255.255.0")) return "PROXY proxy.example.ru:3128"; /* обнаруживает блокировку DNS'ом в domru */
for(i=0; i<len; i++) if(dnsDomainIs(host,domains[i])) {
/*
if(isInNet(myIpAddress(), "192.168.0.0", "255.255.255.0")) return "PROXY 192.168.0.2:3128";
else
- можно выбирать в завимости от сети, к которой производилось подключение
*/
return "PROXY proxy.example.ru:3128";
}
return "DIRECT";
}