Безопасный броузер

Безопасный броузер

На этом сайте нет раздела с фантастикой, даже из разряда научной фантастики.

– Папа, а существует ли какой-нибудь броузер для интернет-серфинга, позволяющий: подменять "идентификатор броузера" позволяя вручную подставить стандартно-распространенные броузеры (Mozilla, Opera, Explorer и т.д.) с разными версиями и разными ОС и другой "информации о пользователе"...?
– Нет, сынок, это фантастика.

Отдельные моменты, навроде юзер-агента, даже ослик позволяет через танцы с бубном поправить, а лисичка, не говоря о доступном конфигураторе, имеет разные расширения. С оперой сложней, но хекс редактор в руки и слово "опера" из агента таки убираемо.

Впрочем, менять UA надо тоже с умом, есть много других заголовков вроде напрямую и не про идентификацию, но которых хватит чтобы опознать изначальную подмену, даже без скриптовых засад. Эту тему жевали много раз тут, однако.

Но безопасность в контексте браузера это фантастика, на сегодняшний день.

подменять "идентификатор броузера" позволяя вручную подставить стандартно-распространенные броузеры (Mozilla, Opera, Explorer и т.д.) с разными версиями и разными ОС и другой "информации о пользователе"

Если не устраивает torbutton, есть плагины к firefox под эти цели [емнип].

"запоминать пользователя"(на сайте)

Мыслите в рамках человеческого языка, а не технологии (хочу такой нож, чтобы нельзя было порезаться, и людей нельзя было убить, а вот мясо чтоб прекрасно резал). "Запомнить пользователя" делается через кучу разных механизов в зависимости от сайта, и указывать что и как делать браузеру, надо в рамках механизмов, а не абстрактной "policy" ("волшебная кнопка в браузере, сделай мне хорошо! Хочу чтобы всё было зашибись!").

Бери сырцы lynx, и там банер меняй.

Мыслите в рамках человеческого языка, а не технологии

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

указывать что и как делать браузеру, надо в рамках механизмов, а не абстрактной "policy"

Это недоработка (или политика?) разработчиков браузеров. Чем больше внимания к механизмам, тем меньше понимания смысла. Людей вынуждают барахтаться в "как"-ах, не оставляя времени задуматься над вопросом "зачем". Зачем?

Чем больше внимания к механизмам, тем меньше понимания смысла.

Смотрите животрепещущий пример, к которому привёл подход волшебного "хочу" без понимания что и как устроено: /comment22082. Наверняка местная публика могла бы привести over 9000 подобных примеров из индустрии :-)

Для подмены заголовков и фильтрации url удобно использовать privoxy. Можно написать скрипт, который меняет случайным образом user-agent и поставить его в cron.

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

Известно что куки можно ещё заложить в заголовки для кеширования, но в privoxy это нейтрализуется подменой заголовков if-modified-since и if-none-match. В меньшей степени, все заголовки Accept* тоже дают косвенную информацию для слежения, но можно задать для них краткие обобщённые значения, а некторые вообще удалить из запросов. Например, конкретный запрос
GET / HTTP/1.1
Host: www.google.com
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.2; Win64; x64; SV1)
Accept: */*
Accept-Language: en-us
Cache-Control: max-age=259200
If-Modified-Since: Fri, 02 Apr 2010 18:04:23 GMT
Connenction: keep-alive

Заголовки Accept-Contents и Accept-Encoding можно не посылать. Заголовки Accept и Accept-Language в принципе можно тоже не посылать, но тогда запрос будет заметно выделяться из стандартного потока, и значит давать информацию для слежения.

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

Но безопасность в контексте браузера это фантастика, на сегодняшний день.

SELinux по идее должен защищать пользовательское пространство от уязвимостей в приложениях. Правда я пока не освоил эту технику. Может кто из знающих людей покажет пример? Предположим, нужно изолировать браузер Firefox. Т.е. процесс запущенный как /usr/bin/firefox должен ограничиваться в памяти (чтобы не украл например парольную фразу из gpg-агента) и на диске в пользовательском каталоге $HOME/.mozilla. В системные каталоги может иметь доступ, т.к. имеет uid:gid обычного пользователя и поэтому не имеет прав на запись туда. Можно ещё добавить ограничение на количество процессов и загрузку процессора, чтобы с помощью js не дать злоумышленникам доступа к системным ресурсам (например для подбора паролей). Как написать политику для браузера? Если будет реальный рабочий пример, то для всех остальных приложений можно написать самостоятельно по аналогии.

Обсуждение SELinux, AppArmor, Qubes-os и др. перенесено в отдельную ветку