The OpenNET Project / Index page

[ новости /+++ | форум | wiki | теги | ]



"Google обосновал ограничение API webRequest, используемого б..."
Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Изначальное сообщение [ Отслеживать ]

"Google обосновал ограничение API webRequest, используемого б..."  +/
Сообщение от opennews (ok), 14-Июн-19, 00:05 
Разработчики браузера Chrome попытались (https://blog.chromium.org/2019/06/web-request-and-declarativ...) обосновать (https://security.googleblog.com/2019/06/improving-security-a...) прекращение  поддержки блокирующего режима работы API webRequest, позволяющего менять принимаемый контент на лету и активно применяемого в дополнениях для блокирования рекламы,
защиты от вредоносного ПО, фишинга, шпионящей за пользователями активности, родительского контроля и обеспечения приватности.


Мотивы Google:


-  Блокирующий режим работы API webRequest (https://developer.chrome.com/extensions/webRequest) приводит к большому потреблению ресурсов.
При использовании данного API браузер вначале отправляет дополнению все содержащиеся в сетевом запросе данные, дополнение анализирует их и возвращает для дальнейшей обработки в браузере изменённый вариант или выдаёт инструкции по блокировке. При этом основные задержки возникают не на стадии обработки трафика дополнением, а из-за накладных расходов на координацию выполнения дополнения. В частности, подобные манипуляции требуют запуска для дополнения отдельного процесса, а также применения  IPC  для взаимодействия с этим процессом и механизмов сериализации данных;


-  Дополнение полностью контролирует весь трафик на низком уровне, что открывает обширные возможности для злоупотреблений и нарушений приватности. По статистике Google в 42% всех выявленных вредоносных дополнений применялся API webRequest. Отмечается, что ежемесячно в каталоге Chrome Web Store блокируются попытки размещения в среднем 1800 вредоносных дополнений. К сожалению рецензирование не позволяет отлавливать все без исключения вредоносные дополнения, поэтому для усиления защиты было решено ограничить дополнения на уровне API. Основная идея в том, чтобы предоставлять дополнениям доступ не ко всему трафику, а только к тем данным, которые необходимы для реализации задуманной функциональности. В частности, для блокировки контента не обязательно предоставлять дополнению полный доступ ко всем конфиденциальным данным пользователя;


-  Предложенный на замену декларативный API declarativeNetRequest (https://developers.chrome.com/extensions/declarativeNetRequest) берёт на себя всю работу по высокопроизводительной фильтрации контента и лишь требует от дополнений загрузки правил фильтрации. Дополнение при этом не может вмешиваться в трафик и приватные данные пользователя остаются неприкосновенны;

-  Google учёт многие замечания в отношении недостаточной функциональности API declarativeNetRequest  и расширил лимит на число правил фильтрации с изначально предложенных 30 тысяч до 150 тысяч, а также добавлен возможности для динамического изменения и добавления правил, удаления и замены HTTP-заголовков (Referer, Cookie, Set-Cookie) и параметров запросов;

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

-  Целью Google является не ущемление и подавление дополнений для блокирования рекламы, а предоставление возможности создания более безопасных и производительных блокировщиков рекламы;

-  Нежелание оставить блокирующий режим работы  API webRequest наряду с новым declarativeNetRequest объясняется желанием ограничить доступ дополнений к конфиденциальным данным. Если оставить API webRequest  как есть, то большинство дополнений не будут использовать более безопасный declarativeNetRequest, так как обычно при выборе между безопасностью и функциональностью основная масса разработчиков выберет функциональность.

Возражения (https://docs.google.com/document/d/1sKZFojq_fUusrebKsyNHfRk_...) разработчиков (https://github.com/uBlockOrigin/uBlock-issues/issues/338#iss...) дополнений (https://docs.google.com/viewer?a=v&pid=forums&srcid=MTc1Mjc4...):


-  Проведённые разработчиками дополнений тесты (https://www.opennet.ru/opennews/art.shtml?num=50169) показывают ничтожное на общем фоне влияние применения блокирующего режима работы API webRequest;

-  Нецелесообразно полностью прекращать поддержку API, активно используемого в дополнениях. Вместо удаления можно добавить отдельное разрешение и жёстко контролировать адекватность его применения в дополнениях, что позволило бы избавить авторов  многих популярных дополнений от полной переработки из продуктов и избежать урезания функциональности;

-  Для снижения накладных расходов можно не удалять API, а переделать на основе механизма Promise, по аналогии с реализацией webRequest в Firefox;

-  Предложенная альтернатива declarativeNetRequest не покрывает всех потребностей разработчиков дополнений для блокирования рекламы и обеспечения безопасности/приватности, так как не позволяет полностью контролировать сетевые запросы, не позволяет использовать собственные алгоритмы фильтрации и не даёт возможность использовать сложные правила, перекрывающие друг друга в зависимости от условий;

-  Забота о приватности надумана, так как работающий в режиме только для чтения неблокирующий режим  API webRequest оставлен и по-прежнему позволяет вредоносным дополнениям контролировать весь трафик, но не даёт возможность на лету вмешиваться в него (изменить содержимое, поставить свою рекламу, запустить майнеры и анализировать содержимое форм ввода можно и после окончания загрузки).


URL: https://blog.chromium.org/2019/06/web-request-and-declarativ...
Новость: https://www.opennet.ru/opennews/art.shtml?num=50868

Ответить | Правка | Cообщить модератору

Оглавление

Сообщения [Сортировка по времени | RSS]


13. "Google обосновал ограничение API webRequest, используемого б..."  –18 +/
Сообщение от Аноним (13), 14-Июн-19, 00:32 
Компромиссное решение очень простое - объявить  webRequest устаревшим и не принимать в Chrome Web Store новые дополнения с ним, но разрешить использовать уже существующим дополнениям.

Но только Google не хочет так делать и намерен вырезать клещами webRequest и обречь разработчиков многочисленных дополнений на нудное и долгое переписывание кода под новый API, вместо того чтобы усовершенствовать правила блокировки. Таким шагом Google лишит uBlock Origin и иже с ним конкурентных преимуществ по сравнению со своим встроенным блокировщиком и обречёт на постепенное увядание.

Ответить | Правка | Наверх | Cообщить модератору

44. "Google обосновал ограничение API webRequest, используемого б..."  +10 +/
Сообщение от A.Stahl (ok), 14-Июн-19, 05:48 
>и не принимать в Chrome Web Store новые дополнения с ним, но разрешить использовать уже существующими

Т.е. запрет на создание новых эффективных блокировщиков для Хрома? Очень грубо и несправедливо.

Ответить | Правка | ^ к родителю #13 | Наверх | Cообщить модератору

45. "Google обосновал ограничение API webRequest, используемого б..."  +1 +/
Сообщение от svsd_valemail (ok), 14-Июн-19, 06:10 
Я думаю в этом случае разработчикам будет целесообразно сделать универсальный фильтрующий прокси либо встраиваемую либу... тем самым сделав его полностью независимым от браузера и блокировать его уже не будет никакой возможности. Правда тут нужно будет сертификат принять пользователю что бы прокси мог вмешиваться в трафик...
Ответить | Правка | ^ к родителю #13 | Наверх | Cообщить модератору

62. "Google обосновал ограничение API webRequest, используемого б..."  +/
Сообщение от Аноним (62), 14-Июн-19, 09:52 
> сделать универсальный фильтрующий прокси

Уже есть, privoxy называется.

Ответить | Правка | ^ к родителю #45 | Наверх | Cообщить модератору

71. "Google обосновал ограничение API webRequest, используемого б..."  +/
Сообщение от Аноним (71), 14-Июн-19, 10:18 
и давно он научился расшифровывать https?

>Since secure HTTP connections are encrypted SSL sessions between your browser and the secure site, and are meant to be reliably secure, there is little that Privoxy can do but hand the raw gibberish data though from one end to the other unprocessed.
>The only exception to this is blocking by host patterns, as the client needs to tell Privoxy the name of the remote server, so that Privoxy can establish the connection. If that name matches a host-only pattern, the connection will be blocked.

по моему в этом случае privoxy не нужен, будет достаточно hosts. Конечно есть вариант сделать гирлянду из прокси

Ответить | Правка | ^ к родителю #62 | Наверх | Cообщить модератору

88. "Google обосновал ограничение API webRequest, используемого б..."  +/
Сообщение от Аноним (62), 14-Июн-19, 12:06 
Та же проблема будет с любым другим прокси.
Ответить | Правка | ^ к родителю #71 | Наверх | Cообщить модератору

95. "Google обосновал ограничение API webRequest, используемого б..."  +/
Сообщение от Аноним (71), 14-Июн-19, 12:47 
squid умеет в ssl bump, но не имеет (не имел) возможностей privoxy
Ответить | Правка | ^ к родителю #88 | Наверх | Cообщить модератору

159. "Google обосновал ограничение API webRequest, используемого б..."  +/
Сообщение от Аноним (159), 17-Июн-19, 16:19 
ProxHTTPSProxyMII спасет отца русской демократии
Ответить | Правка | ^ к родителю #88 | Наверх | Cообщить модератору

94. "Google обосновал ограничение API webRequest, используемого б..."  +/
Сообщение от Аноним (94), 14-Июн-19, 12:36 
А hosts умеет блокировать по regexp или хотя бы целыми доменами?
Ответить | Правка | ^ к родителю #71 | Наверх | Cообщить модератору

101. "Google обосновал ограничение API webRequest, используемого б..."  +/
Сообщение от Аноним (71), 14-Июн-19, 12:59 
да, нельзя. Но допустим есть патченный dnsmasq и несколько других способов. В т.ч. есть готовые списки доменов для этих целей.

Насколько я помню, одной из фишек privoxy была возможность применения правил адблока и вырезания частей страницы и эта фишка поверх https не работает.

Ответить | Правка | ^ к родителю #94 | Наверх | Cообщить модератору

107. "Google обосновал ограничение API webRequest, используемого б..."  +/
Сообщение от Аноним (94), 14-Июн-19, 13:43 
Одна из причин, почему так много правил.
Ответить | Правка | ^ к родителю #101 | Наверх | Cообщить модератору

149. "Google обосновал ограничение API webRequest, используемого б..."  +/
Сообщение от dimqua (ok), 16-Июн-19, 01:14 
Без патчей так могут unbound и dnscrypt-proxy и, наверняка, не только они.

Но списков, которые бы их задествовали мало, либо они слишко агрессивные.

Ответить | Правка | ^ к родителю #101 | Наверх | Cообщить модератору

68. "Google обосновал ограничение API webRequest, используемого б..."  –1 +/
Сообщение от Лапчатый девляпс бубунтёнак (?), 14-Июн-19, 10:10 
Аж захотелось!

Представляю себе некую программу(консольную, но можно и на диалогах), под названием Browser launcher. Она должна быть в репах и идти из коробки. Работать и выглядеть должна как PlayonLinux, например.
Там должны быть опции для скачки, обновления и распаковки в хомяк:
- Chromium
- Ungoogled Chromium
- Chrome
- Firefox
- Waterfox
- Librefox
- Palemoon
- Basilisk
- Opera
- Brave
- Tor Browser
- то же самое, но с wine/proton-префиксами, чтобы юзерагента не палить.
- ещё 100500 форков форков форков...
----
- Списки uBlock Origin, hosts от "The one who cares"
- Списки сисколлов для последующей фильтрации

Эта программа должна менеджить десктоп-файлы в .local/share/applications для запуска награб... скаченного через LD_PRELAD=filters.so
Внутри этой разделяемой либы должен быть перехват сетевого трафика с SSL-bump и ограничение сисколов в том более простом, чем в chrome-sandbox виде, то есть, без SUID-бита.

Осталось только всё это запилить, решив ещё кучу проблем по ходу...

Ответить | Правка | ^ к родителю #45 | Наверх | Cообщить модератору

89. "Google обосновал ограничение API webRequest, используемого б..."  –1 +/
Сообщение от Аноним (62), 14-Июн-19, 12:08 
Про корованы забыл.
Ответить | Правка | ^ к родителю #68 | Наверх | Cообщить модератору

105. "Google обосновал ограничение API webRequest, используемого б..."  +5 +/
Сообщение от Лапчатый девляпс бубунтёнак (?), 14-Июн-19, 13:26 
Не забыл. Я об этом постоянно думаю.
Ответить | Правка | ^ к родителю #89 | Наверх | Cообщить модератору

72. "Google обосновал ограничение API webRequest, используемого б..."  +2 +/
Сообщение от 123 (??), 14-Июн-19, 10:29 
> Я думаю в этом случае разработчикам будет целесообразно не быть Пьер До Лей и использовать Firefox.

Пофиксил для тебя.

Ответить | Правка | ^ к родителю #45 | Наверх | Cообщить модератору

82. "Google обосновал ограничение API webRequest, используемого б..."  –5 +/
Сообщение от Аноним (82), 14-Июн-19, 11:24 
Скорей уж гуглофорк (оперу например), ну не дотягивает лиса. Раза три пытался на нее перейти, но в ней на каждое преимущество с десяток косяков, порой невероятно тупых. Лиса у меня периодически виснет на просмотре ТыТрубы, да и внешний вид у лисы, откровенно говоря, на любителя, много весьма сомнительных решений, даже userChrome.css тут беспомощен. В итоге, после трех месяцев лисы (максимальный срок на который меня хватило), позорно бежал на гуглофорк.
Ответить | Правка | ^ к родителю #72 | Наверх | Cообщить модератору

85. "Google обосновал ограничение API webRequest, используемого б..."  +7 +/
Сообщение от Дон Ягон (ok), 14-Июн-19, 11:46 
> Скорей уж гуглофорк (оперу например), ну не дотягивает лиса.
> Раза три пытался на нее перейти
> позорно бежал на гуглофорк

У меня обратная ситуация. Сколько себя помню, сижу на ff или клонах (palemoon). Пытался перейти на iridium - проблевался и не смог.
Не знаю, где он там быстрее, кроме гуглосайтов, которыми я не пользуюсь, как по мне - примерно такой же или медленее, а ресурсов жрёт больше.
Но это ладно, у меня их есть, пусть жрёт, был бы толк. А его нет. Всё примерно как в ff, только интерфейс м-ацкий.
Хочу попробовать ещё в kiosk mode и с vimium, есть шанс, что в этом случае тазик для рвоты не понадобится.

> даже userChrome.css тут беспомощен

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

Ответить | Правка | ^ к родителю #82 | Наверх | Cообщить модератору

114. "Google обосновал ограничение API webRequest, используемого б..."  +/
Сообщение от Аноним2 (?), 14-Июн-19, 16:25 
userChrome.css устаревшая технология и ее выпил не заставит себя долго ждать.
Ответить | Правка | ^ к родителю #85 | Наверх | Cообщить модератору

115. "Google обосновал ограничение API webRequest, используемого б..."  +/
Сообщение от Дон Ягон (ok), 14-Июн-19, 16:32 
> userChrome.css устаревшая технология и ее выпил не заставит себя долго ждать.

"Для возвращения обработки userChrome.css и userContent.css в about:config добавлена настройка "toolkit.legacyUserProfileCustomizations.stylesheets"."

(https://www.opennet.ru/opennews/art.shtml?num=50743)

Пока не окончательно выпиливают, можно будет включить обратно. Если выпилят совсем, будет грустновато, да.

Ответить | Правка | ^ к родителю #114 | Наверх | Cообщить модератору

167. "Google обосновал ограничение API webRequest, используемого б..."  +/
Сообщение от Вулх (?), 23-Июн-19, 14:08 
Вот когда лиса научится апаратное ускорение, тогда она будет конфеткой.
Ответить | Правка | ^ к родителю #85 | Наверх | Cообщить модератору

157. "Google обосновал ограничение API webRequest, используемого б..."  +/
Сообщение от Аноним (157), 17-Июн-19, 09:28 
Странно, но у меня совершенно противоположный опыт: работает быстрее, внешний вид кастомизируется на ура, не виснет даже при вот таком https://ibb.co/PQVBtFc, из них минимум с полсотни вкладок с видео.
Может быть мы разными браузерами пользуемся?
Ответить | Правка | ^ к родителю #82 | Наверх | Cообщить модератору

158. "Google обосновал ограничение API webRequest, используемого б..."  +/
Сообщение от Аноним (157), 17-Июн-19, 09:30 
Ссылка поломалась https://ibb.co/PQVBtFc
Ответить | Правка | ^ к родителю #157 | Наверх | Cообщить модератору

70. "Google обосновал ограничение API webRequest, используемого б..."  +/
Сообщение от Анонм (?), 14-Июн-19, 10:12 
Его нужно выпилить полностью. Мобильный хром без расширений и пользователям норм. Хром для домохозяек, а не для продвинутых пользователей.
Ответить | Правка | ^ к родителю #13 | Наверх | Cообщить модератору

80. "Google обосновал ограничение API webRequest, используемого б..."  +/
Сообщение от jbl (?), 14-Июн-19, 11:15 
Еще обновления для существующих плагинов не принимать надо.
А вообще 78% хромоюзеров должны страдать и создавать ощущение безнаказанности для рекламных сетей.
Ответить | Правка | ^ к родителю #13 | Наверх | Cообщить модератору

1. "Google обосновал ограничение API webRequest, используемого б..."  +12 +/
Сообщение от тоже Аноним (ok), 14-Июн-19, 00:05 
Возражения сводятся к тому, что Гуглю не решаются сказать "не п...ди" открыто, хотя все именно это и думают, уж простите таки мой французский.
А не решаются, вестимо, потому, что кто ж потянет форк?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

5. "Google обосновал ограничение API webRequest, используемого б..."  +26 +/
Сообщение от Аноним (5), 14-Июн-19, 00:16 
Зачем форк, если есть Firefox? Его тянуть надо.
Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

9. "Google обосновал ограничение API webRequest, используемого б..."  +11 +/
Сообщение от тоже Аноним (ok), 14-Июн-19, 00:27 
> Зачем форк, если есть Firefox? Его тянуть надо.

Надо. И тянут.
Однако Хром тем временем занял больше 70% рынка, и хомячкам до поры безразличны терки разработчиков. Более того - опыт последних лет уже наглядно показал, что хомячки готовы терпеть зонды довольно большого диаметра при условии, что их не заставляют думать.

Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

76. "Google обосновал ограничение API webRequest, используемого б..."  –6 +/
Сообщение от gachimuchi (?), 14-Июн-19, 11:00 
Я бы рад пересесть на лису, но у разрабов руки не из того места растут, потому что мобильной версией пользоваться невозможно ни на андроиде, ни на айос.
Зачем они чего-то там изобретаются, пусть скопируют интерфейс и навигацию с мобильного хрома - успех обеспечен.
Использовать на компе один браузер, на мобиле другой, синхронизируясь через какой-нибудь покет - нет, спасибо, это смена одного зонда на другой, причём менее удобный
Ответить | Правка | ^ к родителю #9 | Наверх | Cообщить модератору

77. "Google обосновал ограничение API webRequest, используемого б..."  –1 +/
Сообщение от gachimuchi (?), 14-Июн-19, 11:01 
Десктоп версия меня вполне устраивает
Ответить | Правка | ^ к родителю #76 | Наверх | Cообщить модератору

79. "Google обосновал ограничение API webRequest, используемого б..."  +3 +/
Сообщение от тоже Анонимemail (ok), 14-Июн-19, 11:12 
Сижу на Лисе уж не помню сколько лет. На айосе стоит Хром, просто потому что Сафари неудобен.
Синхронизировать мои данные через чьи-то сервисы? И вы еще рассуждаете о зондах?
Ответить | Правка | ^ к родителю #76 | Наверх | Cообщить модератору

81. "Google обосновал ограничение API webRequest, используемого б..."  –9 +/
Сообщение от gachimuchi (?), 14-Июн-19, 11:19 
Ты дурачок? Сиди без синхронизации тогда, очень удобно же. А будь фф нормальным браузером на всех платформах, тогда бы синхал через их аккаунт.
Ах да, у тебя не менее безобидный зонд в виде яблока, будешь тут ещё кукарекать
Ответить | Правка | ^ к родителю #79 | Наверх | Cообщить модератору

84. "Google обосновал ограничение API webRequest, используемого б..."  +/
Сообщение от тоже Анонимemail (ok), 14-Июн-19, 11:33 
> А будь фф нормальным браузером на всех платформах, тогда бы синхал через их аккаунт.

У меня одинаковый ФФ дома и на работе. Совершенно спокойно живу без "синканья" чего бы то ни было.

> Ах да, у тебя не менее безобидный зонд в виде яблока, будешь тут ещё кукарекать

Я на том яблоке запускаю Хром, читалку, Мапс.ми да несколько игрушек. Где зонд?

Ответить | Правка | ^ к родителю #81 | Наверх | Cообщить модератору

131. "Google обосновал ограничение API webRequest, используемого б..."  +1 +/
Сообщение от InuYasha (?), 15-Июн-19, 11:22 
> Где зонд?

В операционной системе.

Ответить | Правка | ^ к родителю #84 | Наверх | Cообщить модератору

142. "Google обосновал ограничение API webRequest, используемого б..."  +/
Сообщение от тоже Аноним (ok), 15-Июн-19, 14:25 
"А Скрипач вообще разговаривает на языках, окончания которых не знает!"
Ответить | Правка | ^ к родителю #131 | Наверх | Cообщить модератору

87. "Google обосновал ограничение API webRequest, используемого б..."  +2 +/
Сообщение от Дон Ягон (ok), 14-Июн-19, 11:58 
> Сиди без синхронизации тогда, очень удобно же.

Ну я вот, например, именно так и делаю. Очень удобно.
Если бы мобильный ff попробовал открыть все вкладки из десктопной версии, его бы разорвало, вместе с моим недосмартфоном. И это у меня вкладок не суть-то много ещё.
Да и просто - зачем? У меня разные требования и задачи на мобиле и на ноуте.
С мобилы можно только читать всякое новостное и около чтиво, с сайтов с простейшим дизайном. Писать что-то - уже не вариант, с тачскриновой клавиатуры это всё равно феерически неудобно делать, да и не за чем - однорукий инвалид с клавиатурой всё равно будет писать быстрее.

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

Ответить | Правка | ^ к родителю #81 | Наверх | Cообщить модератору

108. "Google обосновал ограничение API webRequest, используемого б..."  +1 +/
Сообщение от тщт (?), 14-Июн-19, 15:15 
>  приложения на каждый чих не просто так делают.

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

А в целом, да. Нафиг синхронизации, игрался по началу, но бессмысленно, зачем рабочее барахло дома.
А на прошлой работе 2 компа было и тоже никаких синхронизаци, на одном все что снизу - железо и мануалы, на другом все что сверху - служебки и почты - за 5 лет даже мысли не было что-то синхронизировать.

Ответить | Правка | ^ к родителю #87 | Наверх | Cообщить модератору

109. "Google обосновал ограничение API webRequest, используемого б..."  +/
Сообщение от Дон Ягон (ok), 14-Июн-19, 15:24 
>>  приложения на каждый чих не просто так делают.
> хз для чего их делают

Чтобы могли работать без интернета и/или чтобы не тормозили так адово.

> а не приложения делать под каждый чих.

При выборе между приложением и веб-приложением, я в подавляющем большинстве случаев выберу первый вариант. Исключений у меня тут мало. Разве что qbittorrent, но это совсем не про смартфоны, он просто на них не нужен.

Ответить | Правка | ^ к родителю #108 | Наверх | Cообщить модератору

118. "Google обосновал ограничение API webRequest, используемого б..."  +/
Сообщение от тщт (?), 14-Июн-19, 16:49 
Кхм, архитектурно, универсальное гуи правильнее, так как контролировать версию либПНГ в составе браузера проще, чем в составе отдельных приложений на бог знает какой древней версии того же браузера, универсальный протокол обмена, тоже правильнее, так как позволяет вмешиваться и вырезать рекламу (о чем и топик) как минимум, дополнять своей логикой как максимум.

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

На вкус и цвет, лучше корявеньку (ограниченную) полицию, чем статных и красивых полицаев.

Ответить | Правка | ^ к родителю #109 | Наверх | Cообщить модератору

120. "Google обосновал ограничение API webRequest, используемого б..."  +/
Сообщение от Дон Ягон (ok), 14-Июн-19, 17:45 
Очень с большим трудом смог извлечь какой-то смысл из написанного. Основной посыл в любом случае ускользнул от меня. Прокомментировал то, что понял.

> универсальное гуи правильнее, так как контролировать версию либПНГ в составе браузера проще, чем в составе отдельных приложений на бог знает какой древней версии того же браузера

Речь про android или про десктоп? Если первое, то ты, увы, ничего там не контролируешь в плане того, что с чем собрано. Если десктоп, то да, за этим в принципе можно следить, но если автор приложения бандлит либу (линкует статически) на этапе сборки - ты тоже ничего с этим не сделаешь.

> универсальный протокол обмена, тоже правильнее

Это в смысле "ура http, нафиг всё остальное"? Это отнюдь не всегда так.

> так как позволяет вмешиваться и вырезать рекламу

Для десктопа неактуально, кажется. По крайней мере, в свободном/опенсорсном приложении.
На мобиле мне было проще найти приложения без рекламы, под свои скромные задачи (читать fb2/pdf, смотреть сайты).

> Оптимизация дело техники [и далее по тексту]

Тут я уже совсем ничего не понял. Но точно могу сказать, что гэбэшникам абсолютно всё равно, слушать трафик между приложением и сервером или браузером и сервером.
В любом случае, всё упирается в то, можно ли за разумное время расшифровать этот трафик или нет.

Ответить | Правка | ^ к родителю #118 | Наверх | Cообщить модератору

144. "Google обосновал ограничение API webRequest, используемого б..."  +/
Сообщение от тщт (?), 15-Июн-19, 18:16 
> в смысле "ура http, нафиг всё остальное"?

Помнится что-то подобное было когда еще был жив ipx про tcp, хттп так себе, но для своей ниши сойдет, есть куча стандартных либ в стандартной коробке ОСей, неужели в 2019 году осознание, что корпоративные велостпеды зло не пришло?

> но если автор бандлит

Бритва Хэнлона, корпорация наняла 10 прогеров и 10 дизайнеров, забацали приложение, функции выполняет, уволили 9 прогеров и 5 дизайнеров, - сократили издержки - инвесторы довольны - акции растут, но 1 прогер не сможет перевести прогу на актуальные версии библиотек, новых денег на новое приложение инвесторы не дадут - они ж домохозяйки, а старое работает, вполне, пока когото не хакнут на крупную сумму чтобы инициировать полномасштабную ревизию, а если хакнут по мелочи, то приличная корпорация выплатит ущерб и внесет его в издержки увеличив стоимость услуг для всех.

> В любом случае, всё упирается в то, можно ли за разумное время расшифровать этот трафик или нет.

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

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

Ответить | Правка | ^ к родителю #120 | Наверх | Cообщить модератору

148. "Google обосновал ограничение API webRequest, используемого б..."  +/
Сообщение от Дон Ягон (ok), 15-Июн-19, 23:27 
>> в смысле "ура http, нафиг всё остальное"?
> Помнится что-то подобное было когда еще был жив ipx про tcp, хттп так себе, но для своей ниши сойдет, есть куча стандартных либ в стандартной коробке ОСей, неужели в 2019 году осознание, что корпоративные велостпеды зло не пришло?

А это точно ответ на то, что я написал? О каких вообще корпоративных велосипедах речь?

>> но если автор бандлит
> Бритва Хэнлона, корпорация наняла 10 прогеров и 10 дизайнеров, забацали приложение, функции выполняет, уволили 9 прогеров и 5 дизайнеров, - сократили издержки - инвесторы довольны - акции растут, но 1 прогер не сможет перевести прогу на актуальные версии библиотек, новых денег на новое приложение инвесторы не дадут - они ж домохозяйки, а старое работает, вполне, пока когото не хакнут на крупную сумму чтобы инициировать полномасштабную ревизию, а если хакнут по мелочи, то приличная корпорация выплатит ущерб и внесет его в издержки увеличив стоимость услуг для всех.

Какой-то поток сознания. О чём это вообще? О том, что если линковаться статически с нужными тебе библиотеками, то их сложно/невозможно обновить? Это чушь, в случае если не менятся api, пересобрать с новой версией сможет даже не программист. Единственное, нужно пересобрать, да, в отличие от динамической линковки с общесистемной либой. Правда, в случае, если api поменяется, будет упс - надо править код и пересобирать.
И ещё раз - мы про android или про десктоп? Для десктопа это ещё как-то актуально, некоторые программы таскают либы с собой, тем или иным способом, те же ff и chromium (может быть по-разному в зависимости от ОС/дистрибутива). Для андроида это неактуально - там приложения всегда "всё своё носят с собой" и зависят только от системы.

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

Ну, расскажите же, кто под кого прогибается, кто нет и почему.
На самом деле, все приложения используют примерно одни и те же библиотеки, самодеятельность весьма редка. И да, абсолютно пофигу, статическая или динамическая линковка используется.

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

И множество контр-примеров. Тот же nacl (libsodium). Это ни разу не стандарт (хотя шифры бернштейна из nacl потихоньку начинают попадать в них), но вполне используется и более чем хорош.
Думать просто надо, что используешь - это да.

Ответить | Правка | ^ к родителю #144 | Наверх | Cообщить модератору

151. "Google обосновал ограничение API webRequest, используемого б..."  –2 +/
Сообщение от тщт (?), 16-Июн-19, 08:49 
> О каких вообще корпоративных

О любых, интернет банки, заказывалки такси, еды, магазины, 95% содержимого маркета, гуглового или иного. Если вендор аффилирован с ИТ, как яндекс допустим, то какието стандарты безопасности где то есть, в иных случах тайна покрытая мраком.

> А это точно ответ на то, что я написал?

Это концепция открытых стандартов в чистом виде.

> О чём это вообще?

О том что любое приложение, под любую платформу зло, при наличии возможности обойтись без специализированной программы, так как +1 точка отказа.

> кто под кого прогибается, кто нет и почему.

Это в новостях рассказывают, тех где фсб попросило яндекса переписку за 2 года, а он за день до решения суда закатал на диск за 7 лет, ну не станут же они болванку новую портить.

> Какой-то поток сознания

Простая аналония между

Поиметь ребенка нельзя, никогда

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

Ответить | Правка | ^ к родителю #148 | Наверх | Cообщить модератору

152. "Google обосновал ограничение API webRequest, используемого б..."  +/
Сообщение от Дон Ягон (ok), 16-Июн-19, 16:23 
>> О каких вообще корпоративных
> О любых, интернет банки, заказывалки такси, еды, магазины, 95% содержимого маркета, гуглового или иного. Если вендор аффилирован с ИТ, как яндекс допустим, то какието стандарты безопасности где то есть, в иных случах тайна покрытая мраком.

И с чего вы взяли, что там везде свои велосипеды, вместо общеиспользуемых библиотек? Привести обоснованные примеры сможете? Они, конечно, есть, но это совсем не массовое явление и есть только в каких-то старых продуктах обычно, где находится иключительно по историческим причинам.

>> А это точно ответ на то, что я написал?
> Это концепция открытых стандартов в чистом виде.

Нет, это поток сознания.

>> О чём это вообще?
> О том что любое приложение, под любую платформу зло, при наличии возможности обойтись без специализированной программы, так как +1 точка отказа.

Единая точка отказа - это как раз браузер. Потому что плюс ещё одна прослойка между пользователем и приложением. И это почти всегда медленнее, чем нативное приложение.
К тому же, многим приложениям вообще не нужна сеть и, как следствие, браузер.

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

Слышал про эту историю, при чём она тут вообще? Очевидно, яндексу абсолютно без разницы, от чего отдавать логи - от приложения или от веб-приложения.

>> Какой-то поток сознания
> Простая аналония между
> Поиметь ребенка нельзя, никогда
> Поиметь домохозяйку нельзя в подворотне с ножом, а в любом маркете любым приложением можно.

А по-моему, всё же поток сознания. На то, что претендовало на конструктивность я ответил.

Ответить | Правка | ^ к родителю #151 | Наверх | Cообщить модератору

155. "Google обосновал ограничение API webRequest, используемого б..."  –2 +/
Сообщение от gsdh (?), 17-Июн-19, 01:14 
> Привести обоснованные примеры сможете?
> Они, конечно, есть

Ну и какбы

> но это совсем не массовое

Это пока, гайки закручиваются или разбалтываются со временем

> Единая точка отказа - это как раз браузер

Поэтому надо альтернативы

> ещё одна прослойка между пользователем и приложением

Да, еще один стандарт, соблюдение которого много чего гарантирует

> это почти всегда медленнее

C любым стандартом так, давайте еще свой протокол поверх эзернета для каждого месенжера.

> Очевидно, яндексу абсолютно без разницы

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

Кстате, именно у яндекса какойто "странный" хттп, когда работал в провайдере и там ставили кэш, работало все кроме яндекса, пришлось пихать их в исключения.

> Очевидно, стандарты/законы/правила существую пока их придерживается большенство

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

Ответить | Правка | ^ к родителю #152 | Наверх | Cообщить модератору

156. "Google обосновал ограничение API webRequest, используемого б..."  +/
Сообщение от Дон Ягон (ok), 17-Июн-19, 03:09 
>> Привести обоснованные примеры сможете?
>> Они, конечно, есть
> Ну и какбы

Это неумение читать или осознанное цитирование только того, что удобно?
Читаем по слогам: "где находится иключительно по историческим причинам"?
Какая именно буква не понятна?

>> но это совсем не массовое
> Это пока, гайки закручиваются или разбалтываются со временем

Нет, просто корпорастам выгоднее использовать уже написанный ранее код, а не велосипедить. Как и всем прочим. OpenSource реализаций SSL/TLS примерно вагон.
Пока нет примеров актуальных велосипедов - говорить особенно не о чем.
Мне на ум приходит лишь skype, и то, я не уверен, что оно не использует какую-то свободную реализцию криптографии. Не сильно интересовался.

>> Единая точка отказа - это как раз браузер
> Поэтому надо альтернативы

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

>> ещё одна прослойка между пользователем и приложением
> Да, еще один стандарт, соблюдение которого много чего гарантирует

Давайте вы не будете голословным, и расскажете, о чём именно речь?
И заодно почитаете про муки верстальщиков, пытающихся добиться одинаковой работоспособности сайтов в разных браузерах?

>> это почти всегда медленнее
> C любым стандартом так, давайте еще свой протокол поверх эзернета для каждого месенжера.

ЩИТО? Причём здесь протоколы вообще?
Тормоза веб-приложений связаны с JS и прослойкой в виде браузеров, а не в том, что в приложениях какие-то другие протоколы. Там может быть тот же http/https. И что?
Вы не понимаете того, о чём пытаетесь дискутировать.

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

Ещё раз. Я утверждал, что яндексу без разницы, какие логи сливать "майору". Т.е. всё равно, обычное это приложение, или запускаемое в браузере. Логи и от того и от другого у них есть.
Сливать будут и то и то по запросу органов.
В чём разница?
Зачем писать этот бессмысленный пафос вместо того, чтобы немножко наморщить ум?

>> Очевидно, стандарты/законы/правила существую пока их придерживается большенство
> Ваша позиция это концепция потребл*ста, мне удобно так я живу так, остальное бред и поток сознания, какого черта вы тогда делаете на этом ресурсе ? видовс же, сетуп.екзе, далее, далее готово, к чему это все ?

1) Процитировали сами себя и ответили мне - удобно.
2) Про потребл*ста и так далее.
Давайте вы примете разупорин и научитесь читать?
Причём даже не мои сообщения, я-то и значительно с более тугими общался, а например то, как работают браузеры, веб-приложения, приложения, которые запускаются не в браузере, но ходят куда-то по сети?
Может быть после этого можно будет о чём-то говорить, пока же, я вынужден тратить время на "глубокие мысли" человека, который, когда ему указывают на конкретные изъяны в логике и технической грамотности отвечает пустыми псевофилософскими софизмами.

> мне удобно так я живу так, остальное бред и поток сознания

Я описал положение вещей в отрасли по-факту, +/-. Ваш поток сознания - оторванный от реальности бред. Хотите жить в воображаемом мире - ваше право.

> видовс же, сетуп.екзе, далее, далее готово

Ой, а у меня в линуксе также. К чему всё это?

Ответить | Правка | ^ к родителю #155 | Наверх | Cообщить модератору

160. "Google обосновал ограничение API webRequest, используемого б..."  –2 +/
Сообщение от gsdh (?), 18-Июн-19, 03:45 
> Нет, просто корпорастам выгоднее использовать уже написанный ранее код, а не велосипедить. Как и всем прочим

Открываем википедию и читаем статью - война браузеров.

> Это неумение читать или осознанное цитирование только того, что удобно?

Не так давно микрософт похоронил эксплорер, стандартом дефакто является хром в котором начинается какаято не здоровая возня, разве не очивидно к чему дело идет?

> Альтернатива - обычные приложения.

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

> ЩИТО? Причём здесь протоколы вообще?

Я вот уже не знаю, как еще более доходчиво объяснить что ( (законы===протоколы) === стандарты ) === истина.

> Тормоза веб-приложений связаны с JS и прослойкой в виде браузеров, а не в том, что в приложениях какие-то другие протоколы

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

> Ещё раз. Я утверждал, что яндексу без разницы, какие логи сливать "майору"

Акцент делался на "чей" продукт, и это была отсылка к тому, что гугл - прямой конкурент яндекса (ха-ха), никогда не отдаст сессионые ключи майору, покрайней мере тому, что запросто может постучаться в дверь, а потом найти наркоты ровно на статью.

> Вы не понимаете того, о чём пытаетесь дискутировать.

Разве?

> Давайте вы не будете голословным, и расскажете, о чём именно речь?

Ну ок.

Итак, есть TCP/IP, легко и непринужденно режем на фаерволе, то что хотим зарезать.
Есть HTTP, не менее легко можем резать что хотим на проксе.
А в случае большенства кастомных протоколов, извините, хер.

> Я описал положение вещей в отрасли по-факту, +/-

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

> Ваш поток сознания - оторванный от реальности бред.

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

Ответить | Правка | ^ к родителю #156 | Наверх | Cообщить модератору

162. "Google обосновал ограничение API webRequest, используемого б..."  +/
Сообщение от Дон Ягон (ok), 18-Июн-19, 13:05 
>> Нет, просто корпорастам выгоднее использовать уже написанный ранее код, а не велосипедить. Как и всем прочим
> Открываем википедию и читаем статью - война браузеров.

Ой, ты ещё win 3.11 вспомни. Причём тут это?

>> Это неумение читать или осознанное цитирование только того, что удобно?
> Не так давно микрософт похоронил эксплорер, стандартом дефакто является хром в котором начинается какаято не здоровая возня, разве не очивидно к чему дело идет?

Причём тут это?

>> Альтернатива - обычные приложения.
> Это которые распространяются как бык поссал, и пишутся кем попало, и каждое второе так и норовит спи..ть данные или влепить майнер, - это речь о винде, централизованные репозитарии держаться, но фактов было уже много, это беспереспективное направление.

Не знаю о чём вы. Я использую опенсорсное ПО - ничего не тырит, майнеры не устанавливает.
Внимание, вопрос. Что помешает веб-приложению красть данные или запускать майнер? Последнее в вебне вообще так самое милое дело.

>> ЩИТО? Причём здесь протоколы вообще?
> Я вот уже не знаю, как еще более доходчиво объяснить что ( (законы===протоколы) === стандарты ) === истина.

НАРКОМАН ШТОЛЕ??
Ты можешь объяснить предельно доходчиво, что ты донести-то до меня пытаешься?

>> Тормоза веб-приложений связаны с JS и прослойкой в виде браузеров, а не в том, что в приложениях какие-то другие протоколы
> Господи, ладно бы оно на асме было написанно, да куда там, вм на вм и вм погоняет, разница какая ? Нет, серьезно, какая принципиальная разница между js в браузере и той бурдой, что в приложении, jit волшебный ?

Расскажи, пожалуйста, в какой vm исполняются приложения, написанные на c/c++/rust/go/etc?

>> Ещё раз. Я утверждал, что яндексу без разницы, какие логи сливать "майору"
> Акцент делался на "чей" продукт, и это была отсылка к тому, что гугл - прямой конкурент яндекса (ха-ха), никогда не отдаст сессионые ключи майору, покрайней мере тому, что запросто может постучаться в дверь, а потом найти наркоты ровно на статью.

1) Причём тут тогда протоколы, браузеры и нативные приложения?
2) Отдаст. Но вы можете верить, мне не жалко.
3) В контексте слива данных стоит больше бояться не майора, который закрывает журналистов-наркоманов, а конторы, которые смогут извлечь из этих данных какую-то пользу. А чтобы подкинуть что-то, твои персональные данные не очень нужны.

>> Вы не понимаете того, о чём пытаетесь дискутировать.
> Разве?

100%. Но вы можете меня разубедить - стоит только начать писать по-существу. А не пафосными абстракциями.

>> Давайте вы не будете голословным, и расскажете, о чём именно речь?
> Ну ок.
> Итак, есть TCP/IP, легко и непринужденно режем на фаерволе, то что хотим зарезать.
> Есть HTTP, не менее легко можем резать что хотим на проксе.
> А в случае большенства кастомных протоколов, извините, хер.

А в случае HTTPS - не можем, упс? В случае кастомного протокола. 1) если он plain-text, ну или ещё какой-то, но главное - не шифрованный, научиться резать его тривиально. 2) если он использует шифрование, смотри про https.
(ну и да, полностью заблокировать https - да не вопрос, только так никто делать не будет без крайней на то нужды)

>> Я описал положение вещей в отрасли по-факту, +/-
> По факту чего? Книжки - сети для чайников? Никогда и нигде не будет абсолютного порядка, и в абсолютный хаос ничто не превратится, по факту положение дел всегда где-то посередине, вопрос в том что мозг нам дан, чтобы мы могли им думать и принимать решения в сторону чего двигаться.

Речь шла про веб-приложения vs нативные приложения. Вот именно про это я и написал.
А в твоём ответе всё кроме "По факту чего?" - бессмысленная "вода".

Ответить | Правка | ^ к родителю #160 | Наверх | Cообщить модератору

163. "Google обосновал ограничение API webRequest, используемого б..."  +/
Сообщение от ампт (?), 19-Июн-19, 15:16 
> Ой, ты ещё win 3.11 вспомни. Причём тут это?
> Причём тут это?

И он говорит что я отвечаю на то что мне удобно, да конечно не причем.

> написанные на c/c++/rust/go/etc?

На телефонах-то, ага , восновном.

> А в случае HTTPS - не можем, упс?

Очень даже можем, ничего не мешает свой корневой серт затулить в браузер.

> Речь шла про веб-приложения vs нативные приложения. Вот именно про это я и написал.

Ага, и я сказал, что архитекрурно неверно.
Можно пальцем жопу вытерать, но это негигиенично === архитектурно неверно

Все кароч, надоел

Ответить | Правка | ^ к родителю #162 | Наверх | Cообщить модератору

165. "Google обосновал ограничение API webRequest, используемого б..."  +/
Сообщение от Дон Ягон (ok), 19-Июн-19, 16:29 
>> Ой, ты ещё win 3.11 вспомни. Причём тут это?
>> Причём тут это?
> И он говорит что я отвечаю на то что мне удобно, да конечно не причем.

Ну так не стесняйся, объясни, при чём это тут?
Война браузеров это аргумент ПРОТИВ веб приложений, а не за.

>> написанные на c/c++/rust/go/etc?
> На телефонах-то, ага , восновном.

Оппонент не потрудился удосужиться уточнить, о телефонах или о десктопе речь.
Ну и на iOS, ЕМНИП, в основном objective C (хотя я не настоящий сварщик).

>> А в случае HTTPS - не можем, упс?
> Очень даже можем, ничего не мешает свой корневой серт затулить в браузер.

А про воздействие на устройство пользователя речь не шла. И этот момент можно проконтролировать.
Какую мысль вы хотите до меня донести? Веб приложения - хорошо? Веб - приложения плохо? Https - хорошо/плохо? Что?

>> Речь шла про веб-приложения vs нативные приложения. Вот именно про это я и написал.
> Ага, и я сказал, что архитекрурно неверно.
> Можно пальцем жопу вытерать, но это негигиенично === архитектурно неверно

Что архитектурно неверно-то?)) Тебе наверное очевидно, о чём идёт речь, но я твоих мыслей не знаю и мне не очевидно.
Моя позиция тривиальна: веб приложения - за редчайшим исключением абсолютно неоправданный тормозной маразм, лишающий тебя контроля над ПО, которым ты пользуешься.

> Все кароч, надоел

Слив засчитан.

Ответить | Правка | ^ к родителю #163 | Наверх | Cообщить модератору

164. "Google обосновал ограничение API webRequest, используемого б..."  +/
Сообщение от ампт (?), 19-Июн-19, 15:29 
Если у тя мозгов не хватает понять элементарные вещи, да еще и разжеванные. То это диагноз.

Развитие стандартов, эволюция животных/галактик/технологий все по одним законам происходит, но ты продолжай считать так как ты считаешь, наличие таких как ты повышает мое чсв, а еще зп.

Ответить | Правка | ^ к родителю #162 | Наверх | Cообщить модератору

166. "Google обосновал ограничение API webRequest, используемого б..."  +/
Сообщение от Дон Ягон (ok), 19-Июн-19, 16:31 
> Если у тя мозгов не хватает понять элементарные вещи, да еще и разжеванные. То это диагноз.

А я не знаю, хватает у меня или нет. Ты нормально объяснить свою позицию не можешь, только бросаешься незаконченными пафосными мыслями. Теперь ещё оскорблениями.

> Развитие стандартов, эволюция животных/галактик/технологий все по одним законам происходит,

Сильное заявление.

> но ты продолжай считать так как ты считаешь

Именно так я и сделаю - никаких предпосылок считать иначе у меня не появилось.

> ты повышает мое чсв, а еще зп.

С ЧСВ у тебя и так всё в порядке. А так - мне не жалко.

Ответить | Правка | ^ к родителю #164 | Наверх | Cообщить модератору

169. "Google обосновал ограничение API webRequest, используемого б..."  +/
Сообщение от InuYasha (?), 26-Июн-19, 11:48 
До него не дойдёт.
Он из тех быдлоюзеров, которым на каждый URL в интернете проще установить своё приложение.
Не может такой человек набрать в браузере gloogle.com - надо апп. Не может online.spermbank.ru, не может vkorovnik.com, rusracker.org, и т.п.
Мне только одно не понятно - как он на opennet заходит, если ещё нет приложения OpenNet? :)
Ответить | Правка | ^ к родителю #151 | Наверх | Cообщить модератору

170. "Google обосновал ограничение API webRequest, используемого б..."  +/
Сообщение от Дон Ягон (ok), 26-Июн-19, 13:55 
> До него не дойдёт.

Конечно. Как до меня может дойти, если оппонент путается в собственных мыслях и бредит?

> Он из тех быдлоюзеров, которым на каждый URL в интернете проще установить своё приложение.

Не на каждый. Приложения должны быть приложениями (гуглопочта; офис, если он нужен; проигрыватели аудио и видео и т.п), сайты - сайтами. ЖЖ там, или тот же опеннет - сайты, и приложения для них слегка абсурдны (для них есть RSS ридеры + браузер).

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

Ответить | Правка | ^ к родителю #169 | Наверх | Cообщить модератору

136. "Google обосновал ограничение API webRequest, используемого б..."  +/
Сообщение от Michael Shigorinemail (ok), 15-Июн-19, 14:05 
> да и не за чем

Из уважения: "незачем". :)
По существу же -- угу.

Ответить | Правка | ^ к родителю #87 | Наверх | Cообщить модератору

146. "Google обосновал ограничение API webRequest, используемого б..."  +/
Сообщение от Дон Ягон (ok), 15-Июн-19, 22:40 
>> да и не за чем
> Из уважения: "незачем". :)
> По существу же -- угу.

Спасибо.

Ответить | Правка | ^ к родителю #136 | Наверх | Cообщить модератору

83. "Google обосновал ограничение API webRequest, используемого б..."  –2 +/
Сообщение от gachimuchi (?), 14-Июн-19, 11:27 
Я ему, он мне другое. Чел без синхронизации развёл полемику о зондах, присунув себе тоже, только с яблочным вкусом.
Удобно без синхронизации истории, паролей и истории сидится?
Ответить | Правка | ^ к родителю #79 | Наверх | Cообщить модератору

119. "Google обосновал ограничение API webRequest, используемого б..."  +1 +/
Сообщение от тщт (?), 14-Июн-19, 17:14 
Прикинь. В историю лазил раза 2 лет за 10 последних. Пароли сохранять...ну, а память потренировать, а для малозначительных ресурсор сразу жмем форгот)).

А теперь фаталити

У меня даже букмарксов нет, чтото интересное я не закрываю, и оно мазолит глаза вкладкой пока не прочту, а если нет, значит не такое уж и интересное,что синхронизировать то?

А еще регулярно грохаем профиль браузера нафиг, и начинаем сетевую жизнь с чистого листа.

Ответить | Правка | ^ к родителю #83 | Наверх | Cообщить модератору

128. "Google обосновал ограничение API webRequest, используемого б..."  +1 +/
Сообщение от анним (?), 15-Июн-19, 01:19 
Бруталити
Ответить | Правка | ^ к родителю #119 | Наверх | Cообщить модератору

86. "Google обосновал ограничение API webRequest, используемого б..."  +2 +/
Сообщение от Дон Ягон (ok), 14-Июн-19, 11:49 
> мобильной версией пользоваться невозможно ни на андроиде, ни на айос
> пусть скопируют интерфейс и навигацию с мобильного хрома - успех обеспечен

Почти никогда не пользовался мобильным хромом. Использую на андроиде ff. Всем устраивает.
Имхо, вопрос привычки.

Ответить | Правка | ^ к родителю #76 | Наверх | Cообщить модератору

140. "Google обосновал ограничение API webRequest, используемого б..."  +1 +/
Сообщение от Аноним (140), 15-Июн-19, 14:21 
У меня на оочень слабом устройстве люто, бешено лагает и греется на сотку. Телефон убог, конечно (sony xperia go, пятое ведро), но вот например с Ninza проблем особо не возникает, в отличии от мозилы (даже лайт версии). Удручает такая тяжесть на пустом месте, даже а-бланк долго заводится
Ответить | Правка | ^ к родителю #86 | Наверх | Cообщить модератору

147. "Google обосновал ограничение API webRequest, используемого б..."  +/
Сообщение от Дон Ягон (ok), 15-Июн-19, 22:53 
> У меня на оочень слабом устройстве люто, бешено лагает и греется на сотку. Телефон убог, конечно (sony xperia go, пятое ведро), но вот например с Ninza проблем особо не возникает, в отличии от мозилы (даже лайт версии). Удручает такая тяжесть на пустом месте, даже а-бланк долго заводится

У меня Lenovo a7000. Не сказать, что очень быстрое и/или современно устройство. Мобильный ff работает нормально. Так что мне ок, за всех говорить не могу.
Я, правда, с мобилы, в основном, ничего тяжёлого не открываю, только читаю ЖЖ и всякий опеннет, пока еду куда-то. Тормозить там нечему. В любом браузере.

Ответить | Правка | ^ к родителю #140 | Наверх | Cообщить модератору

97. "Google обосновал ограничение API webRequest, используемого б..."  +1 +/
Сообщение от Аноним (97), 14-Июн-19, 12:50 
> мобильной версией пользоваться невозможно ни на андроиде, ни на айос

перешёл на мобильный Firefox после того как гугл стал показывать неотключаемую рекламу на новой странице в хроме, никаких проблем не испытываю.

Ответить | Правка | ^ к родителю #76 | Наверх | Cообщить модератору

124. "Google обосновал ограничение API webRequest, используемого б..."  +1 +/
Сообщение от Аноним (124), 14-Июн-19, 20:58 
Не надо интерфейс и навигацию копировать с хрома на ведре. Нормальная сетка влкадок вместо бесполезных карточек - это прекрасно. Вот лучше бы кучу столетних багов пофиксили и бесконечные фризы
Ответить | Правка | ^ к родителю #76 | Наверх | Cообщить модератору

15. "Google обосновал ограничение API webRequest, используемого б..."  +1 +/
Сообщение от Аноним84701 (ok), 14-Июн-19, 00:33 
> Зачем форк, если есть Firefox? Его тянуть надо.

Его и тянут. Те кому надо:
https://blog.mozilla.org/blog/2017/11/14/firefox-features-go.../
https://www.zdnet.com/article/can-firefox-survive/
> In fact, more than 89 percent of Mozilla Corporation's $562 Million in income in 2017 came from search engine royalties, and almost all that appears to have come from Google.

Оп-па-па! Какая неожиданность!

Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

30. "Google обосновал ограничение API webRequest, используемого б..."  +1 +/
Сообщение от Аноним (-), 14-Июн-19, 01:35 
А я то думаю, чего они автоматически ставят поисковиком яндекс для пользователей из России. А это они так от гуглозависимости пытаются уйти.
Ответить | Правка | ^ к родителю #15 | Наверх | Cообщить модератору

35. "Google обосновал ограничение API webRequest, используемого б..."  +1 +/
Сообщение от Аноним84701 (ok), 14-Июн-19, 02:13 
> А я то думаю, чего они автоматически ставят поисковиком яндекс для пользователей
> из России. А это они так от гуглозависимости пытаются уйти.

Вместо догадок можно было просто пройти по ссылке и почитать
> (Yandex is the default Firefox search engine in Russia and Baidu is the default in China. Google is the default in the United States and other developed markets.)
> That fact is, tellingly, listed under the "Concentration of risk" heading in the Mozilla 2017 financial statement (PDF).

Ответить | Правка | ^ к родителю #30 | Наверх | Cообщить модератору

42. "Google обосновал ограничение API webRequest, используемого б..."  –13 +/
Сообщение от Аноним (42), 14-Июн-19, 03:53 
>Firefox

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

Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

98. "Google обосновал ограничение API webRequest, используемого б..."  +/
Сообщение от Аноним (97), 14-Июн-19, 12:52 
что за чушь
Ответить | Правка | ^ к родителю #42 | Наверх | Cообщить модератору

132. "Google обосновал ограничение API webRequest, используемого б..."  +2 +/
Сообщение от Аноним (-), 15-Июн-19, 12:26 
Пора бы уже признать что Mozilla это просто обычная шестёрка Гугла...
Как им Гугл скажет так они и сделают.
И примеров куча, как с цензурированием дополнений, так и с полезными фишками в самом браузере
Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

153. "Google обосновал ограничение API webRequest, используемого б..."  +/
Сообщение от Аноним (124), 16-Июн-19, 16:54 
Побольше бы конкретики, в обоих случаях
Ответить | Правка | ^ к родителю #132 | Наверх | Cообщить модератору

2. "Google обосновал ограничение API webRequest, используемого б..."  +1 +/
Сообщение от kiwinix (?), 14-Июн-19, 00:07 
Гугл монополист. Что хочет - то и делает)
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

10. "Google обосновал ограничение API webRequest, используемого б..."  +1 +/
Сообщение от VINRARUS (ok), 14-Июн-19, 00:29 
Потому шо пустили козла в город.
Напомнить кто стоял у истоков хромоглухонемого?
Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

27. "Google обосновал ограничение API webRequest, используемого б..."  +11 +/
Сообщение от имя (?), 14-Июн-19, 01:31 
кдешники с их кхтмл! определить их во враги народа!
Ответить | Правка | ^ к родителю #10 | Наверх | Cообщить модератору

29. "Google обосновал ограничение API webRequest, используемого б..."  +5 +/
Сообщение от имя (?), 14-Июн-19, 01:33 
или с++ и лично страуструп? тоже силен дядя
Ответить | Правка | ^ к родителю #27 | Наверх | Cообщить модератору

137. "Google обосновал ограничение API webRequest, используемого б..."  +/
Сообщение от Michael Shigorinemail (ok), 15-Июн-19, 14:08 
> Потому шо пустили козла в город.

Угу.

> Напомнить кто стоял у истоков хромоглухонемого?

Дополню: яббл? :]

Ответить | Правка | ^ к родителю #10 | Наверх | Cообщить модератору

3. "Google обосновал ограничение API webRequest, используемого б..."  –5 +/
Сообщение от Аноним (5), 14-Июн-19, 00:10 
>В частности, подобные манипуляции требуют запуска для дополнения отдельного процесса, а также применения IPC для взаимодействия с этим процессом и механизмов сериализации данных

Кто же вас просил всюду распихивать эту многопроцессность вместо многопоточности? Закопайте обратно.

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

11. "Google обосновал ограничение API webRequest, используемого б..."  –3 +/
Сообщение от VINRARUS (ok), 14-Июн-19, 00:30 
Во всём виноват С++
Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

127. "Google обосновал ограничение API webRequest, используемого б..."  +/
Сообщение от Аноним (127), 14-Июн-19, 22:47 
Да что там С++, сам Бьерне Страуструп лично виноват! Расстрелять его!
Ответить | Правка | ^ к родителю #11 | Наверх | Cообщить модератору

32. "Google обосновал ограничение API webRequest, используемого б..."  +2 +/
Сообщение от Анонм (?), 14-Июн-19, 01:47 
Кто просил? Наверное, те, кто насаждал тонны недоверенного кода на  JS в веб. В этом случае многопроцессность надежнее и безопаснее. Да и защита от утечек лучше. Видимо, кстати, именно поэтому только в последнее время случаев эпичных утечекв огеалисе стало в разы меньше
Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

55. "Google обосновал ограничение API webRequest, используемого б..."  –3 +/
Сообщение от Аноним (5), 14-Июн-19, 08:48 
>Кто просил? Наверное, те, кто насаждал тонны недоверенного кода на  JS в веб. В этом случае многопроцессность надежнее и безопаснее.

Нет, не безопаснее. О какой безопасности может идти речь, если всякое недоверенное .... в ядре обрабатывают?

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

Нет, не лучше. Была 1 утечка, а теперь стало n , + оверхед на многопроцессность.

Ответить | Правка | ^ к родителю #32 | Наверх | Cообщить модератору

61. "Google обосновал ограничение API webRequest, используемого б..."  +2 +/
Сообщение от Аноним (62), 14-Июн-19, 09:48 
> В этом случае многопроцессность надежнее и безопаснее.

Она в любом случае надёжнее и безопаснее.

Ответить | Правка | ^ к родителю #32 | Наверх | Cообщить модератору

67. "Google обосновал ограничение API webRequest, используемого б..."  +1 +/
Сообщение от Аноним (67), 14-Июн-19, 10:06 
Сперва Spectre закопай, умник. Firefox из-за него стал вынужден пилить Fission (отдельные процессы на домены и фреймы, как в хроме с Site Isolation), вместо ограниченного числа общих контент-процессов. Изоляция процессов теперь необходима, закопай свои потоки.
Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

133. "Google обосновал ограничение API webRequest, используемого б..."  –1 +/
Сообщение от Аноним (-), 15-Июн-19, 12:38 
А если я скажу тебе что впиливать многопроцессорность начали задолго до обнаружения порции бэкдоров в процессорах?
Ответить | Правка | ^ к родителю #67 | Наверх | Cообщить модератору

154. "Google обосновал ограничение API webRequest, используемого б..."  +/
Сообщение от Аноним (5), 16-Июн-19, 19:01 
Многопроцессность не решает проблемы spectre. Если запускать недоверенный JavaScript, то никакая защита от Spectre не поможет - ломанут через use-after-free и/или через side-channel уровня браузера и/или ОС и/или видеокарты и/или nfc и/или bluetooth. Enjoy your Web by monkeys.
Ответить | Правка | ^ к родителю #67 | Наверх | Cообщить модератору

4. "Google обосновал ограничение API webRequest, используемого б..."  +6 +/
Сообщение от Аноним (5), 14-Июн-19, 00:13 
> Дополнение полностью контролирует весь трафик на низком уровне, что открывает обширные возможности для злоупотреблений и нарушений приватности.

... заявила компания, зарабатывающая на нарушении приватности пользователей, чей браузер имеет ещё более низкий уровень доступа. ИМХО - если доверяешь гуглу, то доверяй и васяну.

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

78. "Google обосновал ограничение API webRequest, используемого б..."  +4 +/
Сообщение от АнонимГоним (?), 14-Июн-19, 11:07 
Нужно читать так: Это наша корова и мы ее доим.
Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

6. "Google обосновал ограничение API webRequest, используемого б..."  –17 +/
Сообщение от Аноним (-), 14-Июн-19, 00:17 
Зато сколько криков было, что гугл хочет избавиться от блокировшиков, что 30000 слишком мало, надо 75000. Вот, пожалуйста, в два раза раза больше. Шах и мат.

Как теперь разработчит uMatrix'а будет обосновывать свое нежелание перерабатывать дополнение?

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

7. "Google обосновал ограничение API webRequest, используемого б..."  +7 +/
Сообщение от Аноним (13), 14-Июн-19, 00:20 
150 тысяч недостаточно. В списке блокировки Blockade 250 тысяч правил, а в некоторых БД блокировки фишинга до миллиона.
Ответить | Правка | ^ к родителю #6 | Наверх | Cообщить модератору

12. "Google обосновал ограничение API webRequest, используемого б..."  –7 +/
Сообщение от Ordu (ok), 14-Июн-19, 00:32 
> Как теперь разработчит uMatrix'а будет обосновывать свое нежелание перерабатывать дополнение?

Я полагаю, что никак. Утрётся и будет послушно перерабатывать.

Ответить | Правка | ^ к родителю #6 | Наверх | Cообщить модератору

56. "Google обосновал ограничение API webRequest, используемого б..."  +3 +/
Сообщение от Аноним (5), 14-Июн-19, 08:50 
А зачем перерабатывать? Гугл хочет убить блокировщики на хромом  - так надо дать им то, что они хотят. Авось народ на FF переедет.
Ответить | Правка | ^ к родителю #12 | Наверх | Cообщить модератору

126. "Google обосновал ограничение API webRequest, используемого б..."  +/
Сообщение от Аноним (126), 14-Июн-19, 22:40 
> Авось народ на FF переедет.

Ага-щаз.
> Более того - опыт последних лет уже наглядно показал, что хомячки готовы терпеть зонды довольно большого диаметра при условии, что их не заставляют думать.
> https://www.opennet.ru/openforum/vsluhforumID3/117622.html#9

Ответить | Правка | ^ к родителю #56 | Наверх | Cообщить модератору

14. "Google обосновал ограничение API webRequest, используемого б..."  –1 +/
Сообщение от VINRARUS (ok), 14-Июн-19, 00:33 
Думаеш Гуль не сможет затролить ограниченый список правил? Инфраструктура позволяет, и видимо 150 000 это комфортное число для Гуля и прочих M$.
Ответить | Правка | ^ к родителю #6 | Наверх | Cообщить модератору

52. "Google обосновал ограничение API webRequest, используемого б..."  +3 +/
Сообщение от Аноним (124), 14-Июн-19, 07:51 
umatrix переработать не выйдет вообще. Взгляни на его функционал и чуть поразмышляй, может в новом апи, вдруг, чего-то не хватает
Ответить | Правка | ^ к родителю #6 | Наверх | Cообщить модератору

69. "Google обосновал ограничение API webRequest, используемого б..."  +3 +/
Сообщение от Аноним (67), 14-Июн-19, 10:10 
В статье некорректный перевод.
> Additionally, we are currently planning to change the rule limit from maximum of 30k rules per extension to a global maximum of 150k rules.

Было 30к на каждое расширение, будут общие 150к на все.

> Как теперь разработчит uMatrix'а будет обосновывать свое нежелание перерабатывать дополнение?

Невозможностью использовать сложные правила, перекрывающие друг друга в зависимости от условий. Ты читал вообще текст? Ты знаешь в чём суть uMatrix?

Ответить | Правка | ^ к родителю #6 | Наверх | Cообщить модератору

8. "Google обосновал ограничение API webRequest, используемого б..."  +20 +/
Сообщение от Аноним (8), 14-Июн-19, 00:21 
> По статистике Google в 42% всех выявленных вредоносных дополнений применялся API webRequest.

По статистике 100% разработчиков вредоносных дополнений дышат воздухом...

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

16. "Google обосновал ограничение API webRequest, используемого б..."  –1 +/
Сообщение от Аноним (-), 14-Июн-19, 00:34 
Разве нет свободных форков Хрома? Огнелиса?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

17. "Google обосновал ограничение API webRequest, используемого б..."  +2 +/
Сообщение от VINRARUS (ok), 14-Июн-19, 00:35 
Есть, совершенно свободная дичь.
Ответить | Правка | ^ к родителю #16 | Наверх | Cообщить модератору

33. "Google обосновал ограничение API webRequest, используемого б..."  +1 +/
Сообщение от Анонм (?), 14-Июн-19, 01:50 
Единственное похожее на свободный форк это Palemoon, но рнр не очень живо т.к. там все еще не "владеют кодом" своего "форка"   gecko
Ответить | Правка | ^ к родителю #16 | Наверх | Cообщить модератору

99. "Google обосновал ограничение API webRequest, используемого б..."  +/
Сообщение от Всем Анонимам Аноним (?), 14-Июн-19, 12:54 
Шшшш, перестаньте говорить очевидное, дайте людям поумничать. Идет рабочий процесс, но людям же нужно в коментариях рассказать какими умными они себя считают и как они хотят сражаться с ветряными мельницами.
Ответить | Правка | ^ к родителю #16 | Наверх | Cообщить модератору

106. "Google обосновал ограничение API webRequest, используемого б..."  +1 +/
Сообщение от Аноним84701 (ok), 14-Июн-19, 13:38 
> Шшшш, перестаньте говорить очевидное, дайте людям поумничать.

Раз очевидно, то  кинуть список живых, развиваемых и не зависящих от движков гуглы и мозиллы форков вам не составит проблем?
А то в нашей вселенной даже palemoon на таковой не тянет - потому что 24 версия была форком FF 24 ESR, palemoon 27 - форком FF 38 ESR, теперешний UXP/28 это форк FF ESR 52.

Ответить | Правка | ^ к родителю #99 | Наверх | Cообщить модератору

138. "Google обосновал ограничение API webRequest, используемого б..."  +/
Сообщение от Michael Shigorinemail (ok), 15-Июн-19, 14:13 
> Раз очевидно, то  кинуть список живых, развиваемых и не
> зависящих от движков гуглы и мозиллы форков вам не составит
> проблем?

Нуу с натяжкой напомню про netsurf -- для вторичных задач мне подходит (на работе висит на втором экране пятого десктопа рядом с firefox, отображая статистику загрузки сборочных узлов, порой ещё по мелочи).  Натяжка -- потому что собирается с mozjs.

Ответить | Правка | ^ к родителю #106 | Наверх | Cообщить модератору

19. "Google обосновал ограничение API webRequest, используемого б..."  +1 +/
Сообщение от Ананимус (?), 14-Июн-19, 00:40 
Ничо, скоро хуавей и до браузеров доберется.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

59. "Google обосновал ограничение API webRequest, используемого б..."  –1 +/
Сообщение от guest (??), 14-Июн-19, 09:23 
а вот сдесь не совсем смешно..
Ответить | Правка | ^ к родителю #19 | Наверх | Cообщить модератору

90. "Google обосновал ограничение API webRequest, используемого б..."  +4 +/
Сообщение от Аноним (62), 14-Июн-19, 12:13 
> сдесь

Совсем не смешно.

Ответить | Правка | ^ к родителю #59 | Наверх | Cообщить модератору

21. "Google обосновал ограничение API webRequest, используемого б..."  –3 +/
Сообщение от user90 (?), 14-Июн-19, 00:55 
Кто Хром-то использует? Сознательно и по своей воле? Если да, то выстрели себе в голову 2 раза))
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

38. "Google обосновал ограничение API webRequest, используемого б..."  +4 +/
Сообщение от Аноним (38), 14-Июн-19, 02:31 
очень многие люди, возможно даже 95%, думаю что гугл == интернет
Ответить | Правка | ^ к родителю #21 | Наверх | Cообщить модератору

110. "Google обосновал ограничение API webRequest, используемого б..."  +1 +/
Сообщение от НяшМяш (ok), 14-Июн-19, 15:33 
Это у вас какая-то очень оптимистичная статистика. Западная статистика говорит, что 95% пользователей считает фейсбук интернетом, а наша - что интернет это втентаклик или одногрязники. Пользование гуглом для таких пользователей выглядит как программирование шаттла.
Ответить | Правка | ^ к родителю #38 | Наверх | Cообщить модератору

22. "Google обосновал ограничение API webRequest, используемого б..."  +7 +/
Сообщение от Аноним (62), 14-Июн-19, 01:18 
> По статистике Google в 42% всех выявленных вредоносных дополнений применялся API webRequest.

Надо подкинуть Линусу идею выпилить из ядра вызов execve. Он же едва ли не в каждом эксплоите используется!

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

50. "Google обосновал ограничение API webRequest, используемого б..."  +1 +/
Сообщение от Аноним (50), 14-Июн-19, 07:30 
Торвальдс не гугл. Он сразу скажет, куда тебе с такими предложениями идти.
Ответить | Правка | ^ к родителю #22 | Наверх | Cообщить модератору

53. "Google обосновал ограничение API webRequest, используемого б..."  +2 +/
Сообщение от Совершенно другой аноним (?), 14-Июн-19, 08:20 
Возможно, что уже и не скажет - он там уже CoC для ядра завёл. А если написать от имени чернокожей лесбиянки-транссексуалки, то шансы, имхо, очень даже сильно повысятся.
Ответить | Правка | ^ к родителю #50 | Наверх | Cообщить модератору

100. "Google обосновал ограничение API webRequest, используемого б..."  +2 +/
Сообщение от Аноним (97), 14-Июн-19, 12:56 
> в 42% всех выявленных вредоносных дополнений применялся API webRequest

А в 100% всех выявленных вредоносных дополнений применялся API Chrome.

Ответить | Правка | ^ к родителю #22 | Наверх | Cообщить модератору

24. "Google обосновал ограничение API webRequest, используемого б..."  +7 +/
Сообщение от Аноним (24), 14-Июн-19, 01:20 
> Для предприятий оставлена возможность использования блокирующего режима работы API webRequest, так как политику применения дополнений определяет администратор, который понимает особенности инфраструктуры и осознаёт риски

Я что-то не понял, почему "дядя" может осознавать риски, а я (ставя расширения и используя "опасный" апи), не могу?

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

25. "Google обосновал ограничение API webRequest, используемого б..."  +5 +/
Сообщение от Аноним84701 (ok), 14-Июн-19, 01:24 
>> Для предприятий оставлена возможность использования блокирующего режима работы API webRequest, так как политику применения дополнений определяет администратор, который понимает особенности инфраструктуры и осознаёт риски
> Я что-то не понял, почему "дядя" может осознавать риски, а я (ставя
> расширения и используя "опасный" апи), не могу?

Абсолютно согласен!
Я, как администратор сети 127.0.0.1/8 протестую против такого произвола!

ЗЫ:
Кстати, тырьпрайз версия хрома есть только для винды и макоси.

Ответить | Правка | ^ к родителю #24 | Наверх | Cообщить модератору

47. "Google обосновал ограничение API webRequest, используемого б..."  +2 +/
Сообщение от bergentroll (ok), 14-Июн-19, 06:49 
16 мильонов адресов! Да вы серьёзный спец, хайлоад, все дела!
Ответить | Правка | ^ к родителю #25 | Наверх | Cообщить модератору

60. "Google обосновал ограничение API webRequest, используемого б..."  +/
Сообщение от Аноним (62), 14-Июн-19, 09:39 
> сети 127.0.0.1/8

127.0.0.0/8

Ответить | Правка | ^ к родителю #25 | Наверх | Cообщить модератору

139. "Google обосновал ограничение API webRequest, используемого б..."  +/
Сообщение от Michael Shigorinemail (ok), 15-Июн-19, 14:15 
>> сети 127.0.0.1/8
> 127.0.0.0/8

Да хоть 127.127.127.127/8, это один и тот же адрес сети.
Ну, насколько я помню IPv4. :)

Ответить | Правка | ^ к родителю #60 | Наверх | Cообщить модератору

111. "Google обосновал ограничение API webRequest, используемого б..."  +/
Сообщение от НяшМяш (ok), 14-Июн-19, 15:34 
> Кстати, тырьпрайз версия хрома есть только для винды и макоси.

Видать не верят в тырьпрайз на линуксе.

Ответить | Правка | ^ к родителю #25 | Наверх | Cообщить модератору

26. "Google обосновал ограничение API webRequest, используемого б..."  +/
Сообщение от Аноним (-), 14-Июн-19, 01:28 
Ты может и можешь, по крайней мере считаешь что можешь. Но 95% ставят расширения не глядя и вообще не осознавая никаких рисков. Гугл интересуют толпы, а не ты. У тебя мания величия, если ты и впрям считаешь, если гугл что-то делает индивидуально ради тебя.
Ответить | Правка | ^ к родителю #24 | Наверх | Cообщить модератору

91. "Google обосновал ограничение API webRequest, используемого б..."  +/
Сообщение от Аноним (62), 14-Июн-19, 12:15 
> 95% ставят расширения не глядя

Уточнение: 95% из тех 5%, кто знает о существовании расширений.

Ответить | Правка | ^ к родителю #26 | Наверх | Cообщить модератору

28. "Google обосновал ограничение API webRequest, используемого б..."  +1 +/
Сообщение от Дядя (?), 14-Июн-19, 01:32 
Потому что дядя тебя купит, а ты дядю - нет.
Ответить | Правка | ^ к родителю #24 | Наверх | Cообщить модератору

31. "Google обосновал ограничение API webRequest, используемого б..."  +4 +/
Сообщение от Аноним (31), 14-Июн-19, 01:40 
Всё самое гадкое делается во имя безопасности.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

36. "Google обосновал ограничение API webRequest, используемого б..."  +11 +/
Сообщение от Аноним (38), 14-Июн-19, 02:28 
столько ошибок в слове "денег"
Ответить | Правка | ^ к родителю #31 | Наверх | Cообщить модератору

51. "Google обосновал ограничение API webRequest, используемого б..."  +1 +/
Сообщение от ОнАнон (?), 14-Июн-19, 07:37 
Всё самое гадкое делается во имя "безопасности" и денег.
Ответить | Правка | ^ к родителю #36 | Наверх | Cообщить модератору

64. "Google обосновал ограничение API webRequest, используемого б..."  +2 +/
Сообщение от Аноним (64), 14-Июн-19, 10:01 
Безопасности денег.
Ответить | Правка | ^ к родителю #51 | Наверх | Cообщить модератору

63. "Google обосновал ограничение API webRequest, используемого б..."  +1 +/
Сообщение от Аноним (63), 14-Июн-19, 09:57 
Нет. Все самое гадкое оправдывается безопастностью, а делается ради денег и власти.
Ответить | Правка | ^ к родителю #31 | Наверх | Cообщить модератору

34. "Google обосновал ограничение API webRequest, используемого б..."  +3 +/
Сообщение от Гуг Хайльemail (?), 14-Июн-19, 01:56 
ЗБС замес устроил Гугл. Посмотрим насколько активно разработческая и пользовательская шелупонь нанесет ответный удар в виде исхода на Firefox.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

37. "Google обосновал ограничение API webRequest, используемого б..."  +6 +/
Сообщение от Autumn Blaze (?), 14-Июн-19, 02:28 
Не нанесет. Мозилла делает что угодно кроме браузера и живёт на подачки гугля. Она уже давно убита и лишь изображает альтернативу.

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

Ответить | Правка | ^ к родителю #34 | Наверх | Cообщить модератору

43. "Google обосновал ограничение API webRequest, используемого б..."  +4 +/
Сообщение от Ordu (ok), 14-Июн-19, 04:11 
> А начинать надо было со свободного поисковика, почты и аналога ютуба, а не с браузера.

Да, точно. Надо было стать альтернативной корпорацией добра. Альтернативная точно не скатилась бы в то же самое. Я думаю, что гугл совершил ровно одну ошибку: "don't be evil", в качестве основного правила глупость, ибо носит негативную коннотацию, в смысле говорит каким не надо быть, но не говорит каким надо быть. Если бы мозилла запилила бы альтернативу, со позитивным слоганом "be a nice furry foxy little thing", то всё пошло бы совершенно иначе. И мы имели бы приятную пушистую тотальную машину тотальной слежки, вместо гнусной гугловской. Да, им ещё надо было развернуть свою сеть впаривания рекламы, вместо гугловской. Чтобы нам приятно впаривали бы рекламу, а не злостным образом, как это делает гугл. И приятную рекаптчу, вместо гнусной гугловской. Надо проявлять заботу о потребители и смазывать анальный зонд вазелином перед введением. Или не, вазелин не модно давно, он только в древних детских анекдотах остался, сегодня лучше завлекать пользователей специально предназначенным лубрикантом.

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

Ответить | Правка | ^ к родителю #37 | Наверх | Cообщить модератору

54. "Google обосновал ограничение API webRequest, используемого б..."  +1 +/
Сообщение от Аноним (-), 14-Июн-19, 08:43 
> шелупонь

Подходящая характеристика для тех, кто действительно ведется на весь этот FUD с "убийством блокировщиков".

Ответить | Правка | ^ к родителю #34 | Наверх | Cообщить модератору

74. "Google обосновал ограничение API webRequest, используемого б..."  +2 +/
Сообщение от Гуг Хайльemail (?), 14-Июн-19, 10:54 
Шелупонь они по факту хромоюзания.
Ответить | Правка | ^ к родителю #54 | Наверх | Cообщить модератору

39. "Google обосновал ограничение API webRequest, используемого б..."  +4 +/
Сообщение от Аноним (39), 14-Июн-19, 02:37 
а вот то что этот API может фильтровать фильты, и неразрешать блокировать google ads, чет промолчали.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

40. "Google обосновал ограничение API webRequest, используемого б..."  +4 +/
Сообщение от Аноним (40), 14-Июн-19, 03:13 
> Дополнение при этом не может вмешиваться в трафик и приватные данные пользователя остаются неприкосновенны;

И в этом самом неприкосновенном виде отправляются на google analytics и другие трекеры, которые теперь будет невозможно превентивно блокировать, например, правилом запрета запросов на третьесторонние домены.

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

41. "Google обосновал ограничение API webRequest, используемого б..."  +3 +/
Сообщение от Аноним (41), 14-Июн-19, 03:50 
Кто бы сомневался что гугль сможет что-там обосновать...
Зачем эта демагогия на главной?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

46. "Google обосновал ограничение API webRequest, используемого б..."  +1 +/
Сообщение от Аноним (46), 14-Июн-19, 06:21 
208 288 сетевых фильтров + 158 821 косметических фильтров
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

48. "Google обосновал ограничение API webRequest, используемого б..."  +3 +/
Сообщение от Аноним (48), 14-Июн-19, 06:56 
Хорошая попытка, гугл, но - нет
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

49. "Google обосновал ограничение API webRequest, используемого б..."  +6 +/
Сообщение от Аноним (49), 14-Июн-19, 07:24 
> Google обосновал ограничение API webRequest, используемого блокировщиками рекламы

Денег очень хочется. Извините.

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

57. "Google обосновал ограничение API webRequest, используемого б..."  +/
Сообщение от Аноним (57), 14-Июн-19, 09:09 
Вот кстати единственное что у меня в ubuntu на  firefox не работает нормально, это news.google.ru. загрузка 13-15 секунд.
Даже youtube без проблем работает.
Вот кто знает, как его на firefox нормально заставить работать.
На chromium идеально за 1с загружаеться.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

66. "Google обосновал ограничение API webRequest, используемого б..."  +/
Сообщение от Аноним (66), 14-Июн-19, 10:03 
1с в браузере тормозит, я бы не назвал её "идеальной"
Ответить | Правка | ^ к родителю #57 | Наверх | Cообщить модератору

73. "Google обосновал ограничение API webRequest, используемого б..."  +/
Сообщение от Аноним (73), 14-Июн-19, 10:48 
Внеси домены гугла в список блокировки - и проблема решится сама собой.
Ответить | Правка | ^ к родителю #57 | Наверх | Cообщить модератору

104. "Google обосновал ограничение API webRequest, используемого б..."  +/
Сообщение от Аноним (31), 14-Июн-19, 13:18 
Есть решение: http://txt.newsru.com/
Ничего важного не пропустишь.
Ответить | Правка | ^ к родителю #57 | Наверх | Cообщить модератору

134. "Google обосновал ограничение API webRequest, используемого б..."  +/
Сообщение от paulus (ok), 15-Июн-19, 13:00 
>http://txt.newsru.com

Не заточен под мобилы :(

Ответить | Правка | ^ к родителю #104 | Наверх | Cообщить модератору

141. "Google обосновал ограничение API webRequest, используемого б..."  +/
Сообщение от Michael Shigorinemail (ok), 15-Июн-19, 14:24 
> newsru.co.il
> Ничего важного

Вы уже пропустили -- "с точки зрения ребе"...

> не пропустишь.

Ответить | Правка | ^ к родителю #104 | Наверх | Cообщить модератору

150. "Google обосновал ограничение API webRequest, используемого б..."  +/
Сообщение от Offtop (?), 16-Июн-19, 01:31 
Бытовой антисемитизм -- отличительная черта как совочка, так и ватничка
Ответить | Правка | ^ к родителю #141 | Наверх | Cообщить модератору

65. "Google обосновал ограничение API webRequest, используемого б..."  +1 +/
Сообщение от Аноним (66), 14-Июн-19, 10:01 
> Целью Google является не ущемление и подавление дополнений для блокирования рекламы, а предоставление возможности создания более безопасных и производительных блокировщиков рекламы;

безопасных для гугля

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

75. "Google обосновал ограничение API webRequest, используемого б..."  +/
Сообщение от Аноним (75), 14-Июн-19, 10:57 
Все дело в том что Гугл продает дополнения - предположить что пользователь будет утсанавливать только открытый код в свой бразуер, явно не устраивает гиганта. Вообщем, хорошо жить можно, но тогда все будет бесплатно.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

92. "Google обосновал ограничение API webRequest, используемого б..."  +2 +/
Сообщение от Аноним (92), 14-Июн-19, 12:18 
> Разработчики браузера Chrome попытались обосновать

Садитесь, два.

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

93. "Google обосновал ограничение API webRequest, используемого б..."  +/
Сообщение от Аноним (93), 14-Июн-19, 12:26 
Ничо, схаваете.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

96. "Google обосновал ограничение API webRequest, используемого б..."  +3 +/
Сообщение от Аноним (96), 14-Июн-19, 12:50 
Рынок браузерных движков уже монополизирован процентов на 96%. Единой, точнее единственной платформой для веб-приложений, определили-назначили - Chromium/Electron. До того как Microsoft запустил Electron и объявил о переводе Edge на Chromium, ещё пыжились с кроссплатформенностью веб-приложений под тот же Firefox, а сейчас всё... сразу предупреждают, что для веб-приложения требуется браузер на основе Chromium или электрон. Уже всё случилось, для веб-приложений, окромя Хромиума, движков нет. Доля FF сейчас 4,08% https://netmarketshare.com/browser-market-share.aspx?options...
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

102. "Google обосновал ограничение API webRequest, используемого б..."  +3 +/
Сообщение от Меркурий (?), 14-Июн-19, 12:59 
>Рынок браузерных движков уже монополизирован процентов на 96%
>Единой, точнее единственной платформой для веб-приложений, назначили Chromium/Electron.
>До того как Microsoft запустил Electron и объявил о переводе Edge на Chromium,
>ещё пыжились с кроссплатформенностью веб-приложений под тот же Firefox, а сейчас всё
>сразу предупреждают, что для веб-приложения требуется браузер на основе Chromium или электрон

Америку открыли! Нет, ну понятно, что ежели оба крупнейших платформодержателя высказываются за одну и ту же разработку, то всем там и быть? Хромог да электрон это будущее для вебмакак и всем им там быть.

Ответить | Правка | ^ к родителю #96 | Наверх | Cообщить модератору

116. "Google обосновал ограничение API webRequest, используемого б..."  +4 +/
Сообщение от Аноним (96), 14-Июн-19, 16:33 
Да я пытаюсь донести, что монополизация уже произошла. Платформа для веб-приложений уже монополизирована, "Хромог" Гугла с Электроном Майкрософт, уже выжгли поляну. Макаки открыто пишут, что веб-приложения только под движок хромиума.
Ответить | Правка | ^ к родителю #102 | Наверх | Cообщить модератору

103. "Google обосновал ограничение API webRequest, используемого б..."  +3 +/
Сообщение от Меркурий (?), 14-Июн-19, 13:02 
>Доля FF сейчас 4,08% https://netmarketshare.com/browser-market-share.aspx?options...

Тем более. Конкурентов то нормальных уже нет. От Лисы на новом логотипе один хвост остался :)

Ответить | Правка | ^ к родителю #96 | Наверх | Cообщить модератору

112. "Google обосновал ограничение API webRequest, используемого б..."  +/
Сообщение от НяшМяш (ok), 14-Июн-19, 15:39 
А я знаю, откуда у гугла появилась эта идея - посмотрели на пример огрызка: https://developer.apple.com/documentation/safariservices/cre... Те же ограничения (50 тысяч записей), та же примерная реализация.

Только вот гугл тут немного промахнулся - что прокатывает у эппла, не прокатит больше ни у кого. Хотя, у 95% пользователей и выбора не будет.

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

123. "Google обосновал ограничение API webRequest, используемого б..."  +/
Сообщение от Ага (?), 14-Июн-19, 18:28 
Так-то этот api не отменяет аналогичный webrequest api, если говорить за десктопный safari где этот api был и никуда не делся.
Ответить | Правка | ^ к родителю #112 | Наверх | Cообщить модератору

113. "Google обосновал ограничение API webRequest, используемого б..."  +1 +/
Сообщение от о_О (?), 14-Июн-19, 15:41 
https://www.bromite.org/ - хром с адблокером под ведроид.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

143. "Google обосновал ограничение API webRequest, используемого б..."  +/
Сообщение от совсемнеаноним (?), 15-Июн-19, 14:27 
Но зачем?
Ответить | Правка | ^ к родителю #113 | Наверх | Cообщить модератору

117. "Google обосновал ограничение API webRequest, используемого б..."  +/
Сообщение от Викент (?), 14-Июн-19, 16:39 
Да понятно было, что выкинув сторонние бинарные плагины, возьмутся за расширения. Тем более в мобильной версии нет ни того, ни другого.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

121. "Google обосновал ограничение API webRequest, используемого б..."  +/
Сообщение от Wilem (?), 14-Июн-19, 17:51 
Ну блокирующие запросы это и правда отстой, другое дело что не имеет никакого отношения к самому функционалу. Вообще.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

122. "Google обосновал ограничение API webRequest, используемого б..."  +2 +/
Сообщение от Аноним (-), 14-Июн-19, 18:04 
Таки да. Только монополизировали, сразу преференции. Сторонние рекламные сети блокируем, себя и партнёров (майкрософт, амазон) насаждаем.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

125. "Google обосновал ограничение API webRequest, используемого б..."  +1 +/
Сообщение от Аноним (125), 14-Июн-19, 21:26 
Слабохарактерные уроды, вот из кого состоит гугл. Даже признаться в истинных мотивах своих действий не могут.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

129. "Google обосновал ограничение API webRequest, используемого б..."  +/
Сообщение от Аноним (129), 15-Июн-19, 02:10 
Единственный раз теряют жизнь и доверие.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

130. "Google обосновал ограничение API webRequest, используемого б..."  +/
Сообщение от Аноним (130), 15-Июн-19, 09:42 
https://www.opennet.ru/openforum/vsluhforumID3/117631.html#33

Резать зловредов нужно на прокси!

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

135. "Google обосновал ограничение API webRequest, используемого б..."  +/
Сообщение от paulus (ok), 15-Июн-19, 13:08 
Прохи все не порежет и косметические фильтры не применит.

Например, на мобиле исп. Dnsfilter+via

Ответить | Правка | ^ к родителю #130 | Наверх | Cообщить модератору

145. "Google обосновал ограничение API webRequest, используемого б..."  +/
Сообщение от Аноним (-), 15-Июн-19, 18:35 
Если DNS через HTTPS, то не будет работать.
Ответить | Правка | ^ к родителю #130 | Наверх | Cообщить модератору

161. "Google обосновал ограничение API webRequest, используемого б..."  +/
Сообщение от В.В.Путин (?), 18-Июн-19, 04:07 
Китайцы используют его для шпионажа:)
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

168. "Google обосновал ограничение API webRequest, используемого б..."  +/
Сообщение от Аноним (168), 25-Июн-19, 00:46 
Chromium же в исходниках. Никто не мешает использовать Chromium, в котором можно будет оставить старый расширенный вариант WebRequest. Кому надо, тот поставит Chromium. Я, например, его и использую.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру