Комментарии 156
А у нас вот на прошлой неделе была менее приятная история. KAV внес в свой черный список один из десяти наших урлов запросов к бекенду, причем только один и именно тот, который работал в корзине на этапе финального оформления заказа.
Заметили случайно. Неделя ушла на ожидание когда уберут. 3 года все было ок, и на тебе. Пользователи, у которых стоял KAV не сообщали об этом, наш мониторинг детектировал эту ситуацию как отсутствие связи с сервером.
Поэтому, решил таки скачивать видосики постепенно. Пусть лежат на винте.
И на гугловый аккаунт ничего не завязываю, никаких авторизаций и т.п. Ведь банить они любят, и банят сразу всё, что связано с акком. И даже «аффилированные» аккаунты.
Отсюда вывод: монополисты — зло, им плевать на людей. Кто-то из менеджмента PayPal прямо говорил, что жалобы для них — это как скрип колёс едущей телеги.
Насколько я вижу, все успешные случаи спасения — только через прессу.
У налоговой РФ есть ровно один канал связи по вопросам работы интеренет сервисов: форма обратной связи на сайте. Соответственно, когда лежит, например, сервис регистрации кассовых аппаратов, ты можешь только писать обращения через форму, на которые робот отвечает, что оно будет рассмотрено в течении месяца. Всё чудесатей и чудесатей.
И в случае налогов будет аналогичная ситуация: во многих случаях накладные расходы, связанные со взиманием налогов, будут превышать сами налоги.
А не проще ли часть налогов объединить, часть — отменить.
Проще, конечно. Но государство обычно действует ровно наоборот.
накладные расходы выше ожидаемого дохода с налогов — вообще не взимать их? Зачем разводят бюрократию?
Замечательные примеры — письма из налоговой на три-десять копеек, да даже рублей, письма от приставов на такие же суммы. При стоимости самого письма, без учёта работы над ним сотрудника (точнее, наверняка не одного) — 16-60 рублей… :(
Проблема в том, что сотрудник (часто «запуганный») отступить от порядка не способен, даже не осмелится сообщить об этом «нонсенсе» руководству, да и руководство иногда боится отступить. Зато криво-косо потратить выделенные средства — влёгкую, потому что это остаётся «внутри», а подчинённые не сдадут (боятся же).
При этом только в одной организации, руководитель (видимо сказывалась «старая закалка» или он просто был вот такой — правильный), руководил именно ради эффективности, экономии и т.д. А иногда, даже заставлял отказываться от реально копеечной экономии средств, ради быстрейшего выполнения задачи, в итоге экономя может не средства, но время других сотрудников, ожидающих её решения. А я просто из-за отсутствия опыта, не мог охватить всю панораму :) Но это было давно, все «новые» руководители заняты реально какой-то хернёй. С одной стороны их можно было бы понять, над ними же висят «проверки», «надзоры» и чёрт в ступе. А с другой, они не принимают улучшений, которые по определению не могут возбудить проверку, не привлекут надзор.
А когда появляется человек говорящий прямо, например достало одного из сотрудников или пришёл новый, работает он не очень долго. Вместо рассмотрения его предложений — чуть не истерики, вида «да, как ты смеешь (сопляк)?!» или «царь я или не царь?!». Старые сотрудники, даже трижды специалисты, иногда одумываются, им надоедает биться лбом в стену, они просто уходят. Иногда правда громко хлопнув дверью, а в руководстве происходят перестановки или слёты :D
Я помню, что многие считали монополистом Microsoft, но она никогда так грязно не пользовалась своим положением, как Google или Oracle.
В те времена, когда MS царствовала — писалось ровно обратное.
Не удивлюсь, что это писали и вы в том числе.
Ну да, конечно… Классический пример — это docx формат.
Классический пример — это docx формат.
Не соглашусь.
Это их собственный формат, их собственное дело как там они его внутри крутят.
А вот их браузер — будет примером получше.
Но есть разница, что в гугл плэй вы сами программы несете.
Можете нести их в другое место.
А GSB это практически бан на весь Интернет
А GSB это практически бан на весь Интернет
Бан в Google Play — это практически бан на весь Android.
А ведь ещё и весь гугловый аккаунт обычно отправляется туда же.
В разное время была потребность создать в консоли Google Play 2 проекта тестовых.
Оба небыли даже никогда опубликованы, и даже страницы не заполнены для публикации. Но однажды (через несколько лет после их создания) пришел гугл-робот и оба их заблокировал, поставив аккаунт на грань блокировки… Без каких-либо объяснений или хотя бы ссылок на то что эти приложения нарушали. Хотя повторюсь — ничего нарушать они в принципе даже не могли. Ибо оба были не дооформленными проектами
Продолжайте писать в спортлото.
Прецедентов с успешными коллективными исками полно.
Почитайте историю возникновения общества охраны прав потребителей в США.
Многое для себя откроете. Там было очень непросто, но они победили-таки в судах над корпорациями.
Почему вы думаете, что ваш адвокат будет лучше гугловского и вы выиграете?
Ну теоретически адвокат действительно может оказаться лучше гугловского. Но на практике — любая крупная корпорация может достаточно долго затягивать процесс, пока у вас не кончатся деньги на адвоката, после чего вы отзовете свой иск.
1. Идем в крупную адвокатскую контору (или как они там называются).
2. Рассказываем там что злая корпорация со стопятидесятизначными доходами обидела целую кучу маленьких людей.
3. Контора говорит «ни слова больше» и начинает готовить Class Action suit, в т.ч. искать как можно больше потерпевших.
4. Большая злая копроция в случае положительного решения вопроса облагается штрафом в % от годовой прибыли (что бы корпорации больно было) с которого все пострадвшие и их адвокаты получают компенсации.
ЕМНИП адвокаты такие дела любят и вцелом относятся к ним как банки к инвестициям с рисками.
В Firefox вы Google Safe Browsing не найдете.И это совершенно логично, поскольку графический интерфейс настроек предназначен для массового пользователя, который не знает, да и не собирается узнавать, что такое GSB. Разумеется, там понятное и человеческое описание.
А если вы хотите настроек для профи, то и ищите safebrowsing в соответствующем месте — в about:config.
opennet, «Опубликованы результаты аудита системы обновления Firefox»
Анонимм: ну ессьно, не аудит же самого браузера проводить, особенно на предмет шпионажа за пользователями…
macfaq: Это теперь телеметрия называется.
(с) bash.im
Если внешний, то возможно файл вовремя не загрузился.
Лучше основную верстку встраивать как Inline CSS.
Inline CSS для основных стилей позволяет показывать страницу без ошибок красиво и минимально увеличивая ее вес.
Дело может быть не в объеме файлов, а в том что для загрузки CSS требуется отдельное сетевое соединение.
Поэтому для ускорения загрузки и надежности все важное записывают в код самой страницы.
И «все важное» для mobile friendly — это как раз и будет полный объем используемых стилей. Вы вообще о чем?
Я решил помочь тем, что указал на ошибку в рассуждениях, и то как делал бы я: тер бы фары, пинал колёса, молился бы богам разных религий, менял бы реакт на ангуляр, и существует вероятность, что это поможет.
Имхо, это стремительно становится чуть ли не единственной возможной стратегией фоллбэка в мире, где всё управляется нейросетками, и никто уже не сможет сказать — почему именно было принято то или иное решение, оно ведь не «почему», а «так получается».
Если же следовать вышеуказанным «рекомендациям», то можно дойти и до перестановки местами коммутативных тегов, изменения количества пробелов между словами, и подобных методов случайного тыка.
Поэтому и предложил попробовать.
Но Вы можете не обращать внимания на мой совет.
Возможно, у Вас другая проблема.
Сейчас я вижу, что многие (особенно нагруженные сайты) используют Embedded CSS.
А также Compass CSS для создания картинок-спрайтов. А также внедрения картинок прямо в HTML.
Все это популярно на высоких нагрузках сайтов. Если для чтения страницы нужно требуется создать 20-30 сетевых соединений ( HTML страница, картинки, скрипты, шрифты), то сервер может легко исчерпать лимит доступных соеднинений.
Вероятность того, что HTML-файлы будут стабильно грузиться быстро, а CSS — отваливаться по таймауту, сама по себе исчезающе мала
Я такое наблюдаю довольно часто, когда CSS и HTML лежат на разных серверах.
Вас должно беспокоить только то, что пишется в GSC (Google Searсh Console).
Если вы говорите про онлайн тест от гугла, она работает уже больше чем пол года через пень колоду, и его результаты ни на что не влияют. На них можно не обращать внимание.
А в один
Добро пожаловать на phishtank.
Регистрируем 8-10 аккаунтов (потребуется только емейл для подтверждения), выбираем понравившийся сайт, добавляем его с одного аккаунта в базу фиштанка (для усложнения жизни владельцу можно в форму при добавлении какое-нибудь письмо с рекламой гей-порно с карликами засунуть).
Оставшимися аккаунтами голосуем за фишинг, пока нам не напишут «This is phish site!».
Готово. Сидим и ждем. Хотя для закрепления успеха можно добавить и http:// и https:// и со слешем на конце и без слеша, или с двумя слешами. А если совсем времени много, то еще и ссылки можно на сайте подобавлять. Зачем? А вот зачем:
Через 6-12 часов подтягивается Аваст и берет оттуда данные. Через 24-48 часов данные расползаются по всевозможным «антивирусам» — comodo, bit defender, clean mx, CRDF, CyRadar… Откуда потом подсасывает данные долбаный virustotal.
Разумеется, НИКТО не проверяет достоверность данных, всем глубоко похрен.
И как результат, большинство «антивирусных» расширений для браузеров, бесплатных антивирусов и другого ПО начинает на указанный сайт ругаться всевозможными способами, от красных табличек, до полноценных страниц, вещающих о том, что сайт страшно опасен и перейти туда смерти подобно.
И чтобы разгрести эти авгиевы конюшни, приходится каждому из этих «антивирусов» писать в техподдержку. На КАЖДУЮ ссылку! Аваст реагирует довольно быстро, остальные тупо складывают известный орган.
Но даже если сойдутся звезды и получится вычистить сайт из баз антивирусов, то «мега-ресурс» virustotal совершенно это не заботит. Нет тебя в базе phishtank'а? Да пофиг, когда-то же был, будем показывать что есть. Нет тебя в bit defender? Не беда, все равно покажем, что был.
Соответственно, любое ПО или сервис, ориентирующийся на virustotal, будет до скончания веков показывать, что на сайте все плохо. Можно долго и планомерно долбить этот убогий ресурс и может быть повезет оттуда вылезть. Но может и не повезти.
Не знал про него.
Сталкивался с urlhaus.abuse.ch.
Достаточно только Twitter аакунт, чтобы начать броться с вирусами и в том числе можно совершенно анонимно и бездоказательно обвинить любой файл.
Эти друзья рассылают письма хостерам, которые принимают все за чистую монету и блокируют аккаунты.
Пришлось переезжать на другие домены, с перетягиванием ссылочной массы, т.к. посещения упали в разы.
Вот вам и «свободный интернет, регулируемый сообществом». На вирустотале кстати можно еще подгадить сотней-другой голосов и/или каментов в разделе комьюнити. Разумеется, с примитивнейшей регистрацией через почту. Вроде тоже влияет на рейтинг.
Оказалось, что быстрее всего Гугловый антивирус реагирует на страницы, продвигаемые в adsense. Регистрирует домен, делаем на нем страницу, где загружается (или есть ссылка) на «вредоносный» файл и добавляем в рекламую кампанию.
На некоторые вещи реакция идет в течение минуты (модерацию не успевает проходить). Видимо, если «вредоносная» сигнатура есть в самом коде. Остальное практически наверняка проверяется в течение суток (если «вредоносное» содержится в каких-то вызовах проверяемого кода).
Что было стабильно — банился весь домен. И любые загрузки с такого домена потом маркируются вредоносными сразу же. Даже через полгода после «тестов» (тестируемый код был с него удален сразу же).
Что тут сказать, спасибо что не доменными зонами сразу банит. Отлаживать 20кБ кода (с десятками разных запросов и обращений к ресурсам) в таком режиме было очень весело.
С содроганием представляю такой ложный детект в каком-то популярном скрипте, который используется на множестве сайтов. Для любого коммерческого сервиса это почти верная смерть. По крайней мере, если сами сайты из-за этого «лягут» с красной плашкой и пойдут прочие сакнкции.
Вылечилось это просто, при обновлении версии Аваста.
Ну вот мой личный опыт общения с гуглом:
Несколько лет назад я в составе команды занимался разработкой девайса для автоматизации пищевой промышленности. Команда состояла из пяти человек (кто-то делал слаботочную электронику, кто-то силовую, кто-то чертежи рисовал, лично я там софтом занимался). И все мы не рядом находились, а почти в разных городах. Встречались раз в неделю. В результате, по просьбам трудящихся, вся техническая информация о потрохах этого прибора, которая была необходима для взаимодействия разных членов команды (начиная от распайки разъемов, цветов проводов, форматов файлов, синтаксиса команд, кодов сообщений об ошибках, и заканчивая алгоритмами и математическими формулами для обработки данных) хранилась у нас в виде набора документов Google. Ссылки на документы были у всех заинтересованных, то есть все могли быстро уточнить необходимые детали, а также имели возможность что-то добавить/подправить при необходимости. И все мы были счастливы, пока…
… в один не очень прекрасный момент тов Гугль закрыл нам доступ к одному из этих документов. Втихаря, вероломно и без объявления войны. Под тем предлогом, что документ «содержит противоправную информацию».
Пришлось писать в службу поддержки. Дня через два точно так же втихаря доступ к документам вернули. Что уж там Гугль там нашел такого «противоправного» — осталось для нас тайной. То ли им не понравилась формула для пересчета напряжения термопары в температуру, то ли мои выкладки по решению систем уравнений подозрительными показались. (А там весь документ в таком духе и был составлен)
Могли бы и извиниться, вообще-то. Видимо, настроить бота чтобы письмо отправить, оказалось для них слишком сложно.
Но в нашем случае проблема решилась просто: телефонным звонком коллеге и отправкой по е-mail копии документа. А вот когда сервис блокируют — это и врагу не позавидуешь.
Появилась тенденция миграции с Gmail на Protonmail.
В письме от Google предлагали отправить апелляцию, что я немедленно и сделал.
Через два часа пришел ответ, что апелляция отклонена.
И никаких комментариев к ответу.
Знакомо, знакомо. Google… Google never changes.
Отличный прецидент, чтобы подать на Google в суд за ущерб деловой репутации.
Что? Ваше мнение отличается? Пожалте в бан, если вы не с нами, вы против нас. А значит — зло.
Всё якобы чисто, это же не посещаемые URL'и отсылаются, верно? Отсылаются только хэши. Но см. выше, что знает Google о хэше каждого url в интернет.
Но не думайте, это не слежка, это «Safe Browsing». Всё только для пользы. Даром!
P.S.
Коня данайцы вкатили примерно на ~1300 году до нашей эры, т.е. 3319 лет назад.
Жрец Лаокоон, увидев этого коня и зная хитрости данайцев, воскликнул: «Что бы это ни было, а бойтесь данайцев, даже дары приносящих!» (Quidquid id est, timeo Danaos et dona ferentes!) и метнул копьё в коня…
Google уверяет, что проверяет URL сайтов только по хэшу и локально на клиенте, а не на сервере.
И это уверение можно проверить (в Firefox/Chromium) прежде чем разводить теории заговора и теории тотальной слежки. У google safe browsing версии 4 (от мая 2016 года) два варианта api — https://developers.google.com/safe-browsing/v4/ — Lookup API(клиент отсылает полный адрес без каких-либо хэшей! ) и Update API (клиент скачивает базу и проверяет по ней локально — для быстрой и частой проверки, в частности в браузерах).
Firefox использует локальную базу — https://wiki.mozilla.org/Security/Safe_Browsing/V4_Implementation (зайдите в каталог с профилем firefox и проверьте путь safebrowsing/google4/{goog-phish-proto,goog-unwanted-proto,goog-malware-proto,goog-downloadwhite-proto,goog-badbinurl-proto}.{metadata,pset} — должно быть около 6 МБ).
Chromium использует локальную базу https://www.chromium.org/developers/design-documents/safebrowsing — "Checking the safe browsing database is a multistep process. The URL is hashed and a synchronous check against the in-memory prefix list is done. If no match is found, the URL is considered safe immediately. If the prefix matches, an asynchronous request is made to the safe browsing servers for a list of all full hashes matching that prefix. Once the list is returned, the full hash is compared against the list and the URL request can be continued or cancelled."
В предыдущих версиях и в Update API применяются вероятностные структуры. Ранее это были локальные фильтры блума — https://www.quora.com/Why-did-chromium-move-away-from-Bloom-Filters-in-Safe-Browsing и собственные вариации на данную тему https://bugs.chromium.org/p/chromium/issues/detail?id=71832.
Проверяемый адрес сначала локально ищется в фильтре или в базе, и только в случае получения ответа "Возможно адрес содержится" производился запрос хэша к серверам гугла (такие фильтры могут давать ложноположительные срабатывания).
Хэширование у них тоже странное — https://developers.google.com/safe-browsing/v4/urls-hashing — из полного адреса отрезаются лишние поля и символы, затем генерируется 5 сокращений для имени хоста и 6 сокращений для пути на сайте. В роли хэша выступают первые 4 байта от SHA256 (4 млрд возможных значений), т.е. по данному огрызку хэша обязательно будут коллизии и итоговое сравнение полных хэшей производит браузер.
https://developers.google.com/safe-browsing/v4/update-api#checking-urls
To check if a URL is on a Safe Browsing list, the client must first compute the hash and hash prefix of the URL (see URLs and Hashing). The client then queries the local database to determine if there is a match. If the hash prefix is not present in the local database, then the URL is considered safe (not on the Safe Browsing lists).
If the hash prefix is present in the local database (a hash prefix collision), the client must send the hash prefix to the Safe Browsing servers for verification. The servers will return all full-length SHA 256 hashes that contain the given hash prefix. If one of those full-length hashes matches the full-length hash of the URL in question, then the URL is considered unsafe. If none of the full-length hashes match the full-length hash of the URL in question, then that URL is considered safe.
Схемы работы старой версии API (фильтр блума, при совпадении отправляем серверу огрызок хэша, получаем полные хэши с таким префиксом от сервиса и проверяем полные хэши локально) — https://habr.com/ru/company/yandex/blog/127265/ "В Яндекс отправляются только префиксы хешей некоторых масок, которым соответствуют URL просматриваемых страниц, это происходит примерно в 1% случаев просмотра страниц."
Можете открыть developer tools + wireshark + ssl proxy при посещении http://testsafebrowsing.appspot.com/ и изучить реальные запросы.
прежде чем разводить теории заговора и теории тотальной слежки.
Странно что любезно снабжая публику ссылками, вы это делаете выборочно, как вам заблагорассудится. Забывая дать ссылки на
https://ru.wikipedia.org/wiki/Агентство_национальной_безопасности#Другие_программы_слежения
(таблица справа «Программы слежения АНБ», под печатью АНБ)
https://en.wikipedia.org/wiki/PRISM_(surveillance_program)
и почему-то в этом случае небрежно называя давным-давно известные факты © «теории заговора и теории тотальной слежки».
Моя реплика будет базироваться исключительно на вашем сообщении.
Логическая посылка №1:
— «Checking the safe browsing database is a multistep process. The URL is hashed and a synchronous check against the in-memory prefix list is done. If no match is found, the URL is considered safe immediately.
Я её всё же объясню, а то вдруг не всем это понятно.
Если будет совпадение, т.е. match is found, url будет not safe, а отсюда отсылка хэша url на сервер, в результате которой сервер узнает о посещаемом url.
Логическая посылка №2:
Хэширование у них тоже странное
т.е. по данному огрызку хэша обязательно будут коллизии
Логика:
ЕСЛИ («обязательно будут коллизии» = TRUE) И («match is found, visit server» = TRUE)
ТО —?
Что в итоге, какова импликация?
А такова, что утверждение:
Google уверяет, что проверяет URL сайтов только по хэшу и локально на клиенте, а не на сервере.Проверку не прошло. Из-за намеренно введенных частых коллизий хэша, посещаемые сайты отправляются на серверы, а вовсе не всегда проверяются локально.
Утверждение о полной локальной проверке ложно.
Локальная проверка вроде бы и существует как класс. Вот только она намеренно сделана слабой, так что в итоге хэш всё-таки приходится отсылать на сервер. Но не всегда.
Есть и вторая „линия обороны“. Она базируется на недостаточной грамотности в вопросах статистики и криптографии. А именно — на непонимании вопроса легкости восстановления полного хэша по его передаваемой части. Так что если на серверы поступает фрагмент, существует возможность восстановления полного хэша и как следствие — url. Может быть даже не сразу, и скорее всего это делается даже не внутри Google, так что формально он «чист».
match is found, url будет not safe, а отсюда отсылка хэша url на сервер
Клиент (в случае совпадения в своем фильтре) отсылает 4 первых байта от хэша (префикс). Сервер видит от клиента лишь 4 байта и отвечает списком хэшей из базы с данным префиксом, окончательное сравнение полных хешей — локальное.
Можно предположить, что в интернете страниц значительно больше чем 4 млрд (2013 — 30 трлн стр.), т.е. точные ссылки не должны отправляться.
Предлагаю провести эксперимент с локальным sslstrip прокси и перехватить списки отправленных через POST префиксов в https://safebrowsing.googleapis.com/v4/fullHashes:find?.. при визите на подстраницы testsafebrowsing.appspot.com. Либо включить отладку chrome://net-internals ( chrome://net-export + https://chromium.googlesource.com/catapult/+/master/netlog_viewer/). Очень интересно проверить реальное количество одновременно отправляемых префиксов и их размер (по коду вроде от 4 до 32 байтов, точнее разобрать без отладчика не могу).
Вот часть описания:
https://developers.google.com/safe-browsing/v4/update-api#checking-urls
If the hash prefix is present in the local database (a hash prefix collision), the client must send the hash prefix to the Safe Browsing servers for verification. The servers will return all full-length SHA 256 hashes that contain the given hash prefix. If one of those full-length hashes matches the full-length hash of the URL in question, then the URL is considered unsafe.
Вот исходный код https://cs.chromium.org/chromium/src/components/safe_browsing/browser/safe_browsing_url_checker_impl.cc?g=0&l=214
https://cs.chromium.org/chromium/src/components/safe_browsing/db/v4_local_database_manager.cc?g=0&l=796
void V4LocalDatabaseManager::ProcessQueuedChecks() {
DCHECK_CURRENTLY_ON(BrowserThread::IO);
// Steal the queue to protect against reentrant CancelCheck() calls.
QueuedChecks checks;
checks.swap(queued_checks_);
for (auto& it : checks) {
FullHashToStoreAndHashPrefixesMap full_hash_to_store_and_hash_prefixes;
if (!GetPrefixMatches(it, &full_hash_to_store_and_hash_prefixes)) {
RespondToClient(std::move(it));
} else {
pending_checks_.insert(it.get());
PerformFullHashCheck(std::move(it), full_hash_to_store_and_hash_prefixes);
}
}
}
PerformFullHashCheck вызовет void V4GetHashProtocolManager::GetFullHashCachedResults
https://cs.chromium.org/chromium/src/components/safe_browsing/db/v4_get_hash_protocol_manager.cc?g=0&l=383 и наступит
// Case 2: The prefix is not in the cache.
// We need to send a request for full hashes.
const HashPrefix& prefix = matched_it.hash_prefix;
...
unique_prefixes_to_request.insert(prefix);
prefixes_to_request->insert(prefixes_to_request->begin(),
unique_prefixes_to_request.begin(),
unique_prefixes_to_request.end());
data: The 32-bit hash prefix of any potentially bad URLs. The URLs themselves are not sent.
Удалось получить дампы запросов через chrome://net-export + https://netlog-viewer.appspot.com/#events. Теперь требуется декодировать protobuf запрос к v4/fullHashes:find? и извлечь ответ сервера. Этим инструментом можно вручную проверить количество запросов к gsb во время обычной работы.
Но это не самое страшное.
Беда в том, что ошибка не единичная. От нее страдаю не только я.
Это как раз вам повезло.
На единичное обращение они не отреагируют.
А вот на массовое — другое дело.
Так что вам очень повезло, что ошибка массовая.
Давайте выскажем догадку, как может быть спроектирована система Google в общих чертах.
Система обладает эвристикой. Исходный параметр эвристики — рейтинг страницы (т.е. расчетная позиция среди всех страниц/сайтов сети, Google ее ведет).
Должен существовать нижний шумовой порог. Он, как минимум, порядка нескольких единиц, (2..3), иначе система будет непригодна.
Граница срабатывания эвристически-адаптивна и для «мелочи» она будет опять же ничтожна, в пределах десятка. Это будет никак не «массовость», не тысячи, не сотни и даже не десятки.
А отсюда — в случае сайтов с малым рейтингом срабатывание легко вызвать «руками». Выше это подтверждают.
В ходе плановой проверки на Вашем аккаунте было обнаружено подозрительное, потенциально вредоносное, содержимое.
Ниже приведены пути к найденным файлам, а также их описание:
/home/user/www/site1/public_html/.../archive.rar (Rar.Suspect.WinDoubleExtension-rarpwd-3)
Это является нарушением п. 7.2. Приложения № 3 к Публичной оферте:
«Заказчику запрещается публиковать или передавать любую информацию или программное обеспечение, которое содержит в себе компьютерные
«вирусы», иные вредоносные программы или способно нарушить нормальную работу компьютеров, доступных через сеть».
Правда проблема решалась письмом в службу поддержки в стиле «мамой клянусь тут вируса нет», этого было достаточно. Для такого гиганта как гугл оно понятно, не сработает.
Ругался на обфусцированное приложение .NET, которое лежало на фтп уже лет 6.
Написал о проблеме на форумах Google с предложением предоставить исходники и настройки обфускации в случае необходимости, но ответа так и не получил, поэтому решил не рисковать, и просто удалил файл :(
Варианты с фолсами по Delphi и Inno Setup были и раньше известны.Кто-то поюзал инсталлятор для создания вирусов (естественно, не один раз) и теперь Google считает это за вирус. Потому что зачастую это действительно вирус. Похожие истории уже были, вроде.
И любые инструкции читает минимальное число пользователей.
Дополнительная галочка при установке немного эффективнее.
Читает может и мало кто, но если много где вешать — вероятность прочтения (и вероятность отказа от GSB, которая ещё ниже, но связана с первой) повышается.
меня дома Гугл тролит своей капчей, регулярно, а РКН в прошлом году тролил Амазон; монополист будет беспределить, так устроен этот грёбаный мир, но самое странное и беспощадное — отсутствие обратной связи, безответственность крупных игроков.
файлы с установкой видимо, лучше хостить на специальных площадках, где репутация домена условно-высокая по версии этих самых монополистов… Есть такие сервисы? Может, на CDN?
по технике: такого рода системы (типа GSB) действительно запоминают URL, порой без проверки фактического содержимого (см ниже), но у них дифференцированный (и совершенно непрозрачный) подход к репутации сайта/домена, причем "вредоносные" ссылки на странице резко ухудшают домен, цепная реакция. Опасайтесь также выкладывать что-либо на новые, недавно зарегистрированные домены, это может вызвать ещё больше срабатываний.
Почему не проверяют содержимое? Увы, сейчас проверить вредоносность выполняемого файла очень ресурсоемко (из-за криптооберток), и VirusTotal вообще никакой гарантии не даёт, только вероятность.
Удачи Вам.
Может кто-то уже предлагал выше, но всё же. Если первопроблема именно в ссылках (а потом уже в файлах) — возможно стоит попробовать генерировать уникальные ссылки для скачивания. Может каждую загрузку страницы, может каждые 100 скачиваний.
Тогда GSB будет постоянно их помечать как новые и, может, подозрительные, но не будет такого трафика на одну ссылку чтоб однозначно помечать их как опасные.
xakep.ru/2018/07/12/ammyy-admin-site-hijack
Ну и отдельных исков (уже от Роскомнадзора) чтобы блокировали ну очень опасную для детей информацию (вроде списка наркотиков в EVE Online, если кто-то не играл — да, в игре они прописаны, прямо сказано что использование — незаконно по внутримировым правилам, и дают далеко не только бонусы, просто в некоторых случаях — оно того стоит) не только в поиске (о чем уже пробуют) а прямо через этот API.
А вообще был и положительный опыт несколько лет назад — на сайте лежал подписанный .exe-файл, качался пользователями (малым количеством но с разных мест), файл запакован VMProtect'ом (честно купленным), внутри куча вещей системного уровня (например — 'объяснение' вообще левому процессу что на диске якобы есть определенные файлы и надо бы их обработать) + лазание в сеть. От пользователя оно не маскировалось. И никаких проблем. Максимум — фолсы от редких антивирусов вида «запакованный файл».
Хорошо еще, что на северах РФ батареи отопления им не управляются.
GSB переклинило и он заблокировал новый разрабатываемый сайт компании с сообщением «Deceptive site ahead».
Сайт размещен на отдельном домене, закрытый для индексации через robots.txt. И GSB заблокировал весь домен, а не отдельные страницы. Кстати, с такой блокировкой домена все письма, в которых если любая ссылка (даже текстом) на этот домен — прямиком идут в спам! По крайней мере в gmail. Gmail даже не дает их отравить! С такими возможностями GSB может напрочь уничтожить любой бизнес в интернете…
И возвращаемся к проблеме, в Search Console указывается одна опасная страница c «Harmful content» — вход в админку.
По данным Virustotal поблему видел только GSB (Phishing site).
Получается 3 разных, в чем-то противоречивых, сообщения:
— в браузерах: Deceptive website ahead
— в Google Search Console: Harmful content
— в Virustotal (GSB): Phishing site
Для решения проблемы закрыли страницу входа в админку паролем через htaccess и отправили в Google Search Console запрос на проверку, через 3 дня пришел ответ, что Гугл больше не видит никаких проблем и все хорошо. За это время многие антивирусы пометили сайт как фишинговый и пока не торопятся убирать пометку. Пока как-то так…
В итоге конкретную причину так и не удалось выяснить! Есть какие-нибудь предположения?
И еще волнующий для меня вопрос — как подобная блокировка влияет на позиции в Гугл? Есть какая-нибудь информация или может свои наблюдения?
del
Google Safe Browsing — пришла беда откуда не ждали