С одной стороны, тоже ненавижу спам. С другой стороны, причём тут спам? Спам почтовые клиенты как фильтровали, так и продолжат фильтровать. И отправлять динамические письма кому попало тоже не получится. В общем, хочется верить, спама именно из-за этой технологии ни больше ни меньше не станет, зато полезные письма станут ещё удобнее.
И в чём именно проблема с выполнением скриптов в теле письма? Это же не какие-то рандомные скрипты, которые могут что-то писать в кэш, изменять в оболочке самого клиента и т.д. Это вполне конкретные веб-компоненты с понятным и прозрачным функционалом.
Но если есть конкретные опасения или, того хуже, примеры явных уязвимостей, то дайте, пожалуйста, знать.
Из личного опыта можно вспомнить, как после перевода одного новостного сайта на работу с Service Worker, было решено отказаться от Андроид приложения, сделанного по функционалу сайта. И не столько потому, что его поддержка занимала человеческие ресурсы, а потому, что PWA версия, как ни удивительно, была быстрее, красивее и удобнее в работе, чем java приложение.
А с этого места можно поподробнее? Можно и в личку :) Мы бы про такой кейс с огромным удовольствием всем рассказали. Developers_Relations FYI
https://m.airberlin.com/en/pwa — надо было, конечно, ребятам в исходной статье сразу ссылку давать :) Но спасибо за комментарии — мы сами сначала испугались )))
И, да, https://m.airberlin.com/en/pwa у меня грузится за 1,94 секунды и даёт сейчас 65/100 в тестере PSI
1. Работаем над этим. Сама фича новая, диапазон обнаруживаемого вредоноса и нежелательного ПО расширяется, так что разработчикам инструмента приходится играть в догонялки. Сообщения в нём пока далеки от идеала, но про необходимость расширять набор примеров знают.
2. Пожалуйста, пример, если можно. Отсутствие уведомления – это не нормально.
3. Это действительно странно :/ Попробуем выяснить, и если нужно, поправить.
4. Отличное замечание! По идее, как раз уведомления и примеры должны избавить Вас от необходимости носиться со счётчиком и что-то прозванивать, но это явно не происходит пока. Передам и это разработчикам.
5. Спасибо, что заботитесь о пользователях! Без них мы все никуда :) В отношении примеров и раскрытия информации, учитывайте только, что при всём огромном желании помогать владельцам и разработчикам ресурсов, нам всё время приходится взвешивать, насколько публикация тех или иных данных облегчает жизнь «плохим парням». Так что, не сердитесь слишком, если информации кажется порой слишком мало – мы будем продолжать искать такой баланс, чтобы добросовестным веб-мастерам было комфортно и удобно работать и решать проблемы, но при этом и особо больших дырок в системе не возникало.
Спасибо за подробные примеры!
По поводу наших доменов ничего делать не нужно. Те страницы, что были определены как устанавливающие зловреды, будут заблокированы – и всё.
Проверка происходит в массе своей автоматически. В исключительных случаях также и вручную. Чуть подробнее здесь: www.google.com/transparencyreport/safebrowsing/?hl=ru
Вопрос о беспристрастности при автоматической проверке отпадает. При редких ручных проверках действуют механизмы контроля и обеспечения качества. От ошибок не застрахован никто, но мы делаем всё возможное, чтобы находить, выявлять и предотвращать их.
Непонятно, в какой список надо вносить «по звонку», но если речь о потенциально опасном ресурсе, то сообщить можно тут: www.google.com/safebrowsing/report_badware
В «белый» список внести нельзя, потому что его просто нет. Ни один сайт гарантировано не защищён от взломов и заражений.
Если, как в вашем примере, «вирус» или другая опасность присутствует лишь на «одной страничке из тысяч», доступ ко всему ресурсу целиком заблокирован, скорее всего, не будет.
Конечно.
1. support.google.com/webmasters/topic/6001971?hl=ru
2. Последствия зависят от конкретного поведения. В случае злонамеренной скрытой переадресации обычно страница или сайт целиком удаляются из индекса.
Ни о какой цензуре речи быть не может. Что же касается наличия или отсутствия вирусов или другого зловредного или нежелательного ПО на сайте, Google не принимает решение разместить оповещение на основании чьих-то уведомлений. Они появляются всегда только на основании доскональной проверки. Если бы Вы пример затронутого URL, можно было бы попробовать проанализировать, что действительно имело место.
«Голословно» — очень странно звучит в этом контексте. Все эти решения принимаются на основе имеющихся данных и для защиты пользователей браузера. ЭЦП от Вас никто не требует и упаковщиками Вы можете пользоваться сколько угодно. Делать такие заявления не стоит, сначала не ознакомившись со справкой, например, в отношении нежелательного ПО. Что же касается Вашего примера, подключение к Search Console здесь совершенно ни при чём, и хотя Вам не удалось найти для него применение, я бы не торопился называть этот набор инструментов бесполезным. Если Вы внимательно вчитаетесь в собственный скриншот, то увидите, что предупреждение связано лишь с тем, что о файле не имеется достаточно информации, чтобы считать его безопасным. Пользователь может принять это предупреждение к сведению и продолжить загрузку файла. После того как о файле и его поведении будет получено больше данных, при условии, что это поведение не будет вредоносным, это предупреждение при загрузке исчезнет.
У ребят с кат.ср было достаточно времени, чтобы решить обнаруженные проблемы. Всё-таки в вопросах обеспечения безопасности массового пользователя мы не идём на компромиссы и рассчитываем на понимание и солидарность как со стороны продвинутых пользователей, так и со стороны владельцев ресурсов.
И в чём именно проблема с выполнением скриптов в теле письма? Это же не какие-то рандомные скрипты, которые могут что-то писать в кэш, изменять в оболочке самого клиента и т.д. Это вполне конкретные веб-компоненты с понятным и прозрачным функционалом.
Но если есть конкретные опасения или, того хуже, примеры явных уязвимостей, то дайте, пожалуйста, знать.
Если долго и самостоятельно, то: developers.google.com/web/fundamentals/instant-and-offline/offline-cookbook
Если ещё чуть дольше, но с чужой помощью и примерами, то: stackoverflow.com/search?q=service+worker+update
UPD: от автора этой самой статьи чуть более ранний материал по теме: habr.com/post/358060
А с этого места можно поподробнее? Можно и в личку :) Мы бы про такой кейс с огромным удовольствием всем рассказали.
Developers_Relations FYI
Хороший вопрос. Вот немного статистики, которую удалось нагуглить: https://www.branded3.com/blog/google-voice-search-stats-growth-trends/
https://www.seonews.ru/analytics/golosovoy-poisk-i-ego-vliyanie-na-reklamnyy-rynok/
За верность этих данных отвечать не могу, но некоторые мне кажутся очень интересными. И, похоже, что машина — действительно не единственное место.
И, да, https://m.airberlin.com/en/pwa у меня грузится за 1,94 секунды и даёт сейчас 65/100 в тестере PSI
1. Работаем над этим. Сама фича новая, диапазон обнаруживаемого вредоноса и нежелательного ПО расширяется, так что разработчикам инструмента приходится играть в догонялки. Сообщения в нём пока далеки от идеала, но про необходимость расширять набор примеров знают.
2. Пожалуйста, пример, если можно. Отсутствие уведомления – это не нормально.
3. Это действительно странно :/ Попробуем выяснить, и если нужно, поправить.
4. Отличное замечание! По идее, как раз уведомления и примеры должны избавить Вас от необходимости носиться со счётчиком и что-то прозванивать, но это явно не происходит пока. Передам и это разработчикам.
5. Спасибо, что заботитесь о пользователях! Без них мы все никуда :) В отношении примеров и раскрытия информации, учитывайте только, что при всём огромном желании помогать владельцам и разработчикам ресурсов, нам всё время приходится взвешивать, насколько публикация тех или иных данных облегчает жизнь «плохим парням». Так что, не сердитесь слишком, если информации кажется порой слишком мало – мы будем продолжать искать такой баланс, чтобы добросовестным веб-мастерам было комфортно и удобно работать и решать проблемы, но при этом и особо больших дырок в системе не возникало.
По поводу наших доменов ничего делать не нужно. Те страницы, что были определены как устанавливающие зловреды, будут заблокированы – и всё.
Вопрос о беспристрастности при автоматической проверке отпадает. При редких ручных проверках действуют механизмы контроля и обеспечения качества. От ошибок не застрахован никто, но мы делаем всё возможное, чтобы находить, выявлять и предотвращать их.
Непонятно, в какой список надо вносить «по звонку», но если речь о потенциально опасном ресурсе, то сообщить можно тут: www.google.com/safebrowsing/report_badware
В «белый» список внести нельзя, потому что его просто нет. Ни один сайт гарантировано не защищён от взломов и заражений.
Если, как в вашем примере, «вирус» или другая опасность присутствует лишь на «одной страничке из тысяч», доступ ко всему ресурсу целиком заблокирован, скорее всего, не будет.
1. support.google.com/webmasters/topic/6001971?hl=ru
2. Последствия зависят от конкретного поведения. В случае злонамеренной скрытой переадресации обычно страница или сайт целиком удаляются из индекса.