Если вы заинтересованы в выяснении причин, то можно попробовать делать это методом исключения:
1) наличие/отсутствие трояна проверить полным сканированием последней версией антивируса, отключив предварительно интернет (на случай если кто-то следит через RDP) и возможно загрузившись с внешнего носителя.
2) Проверить, можно ли подключиться к гугловскому аккаунту через SMTP/IMAP по незашифрованным портам. Если можно — может быть, был перехвачен пароль при авторизации почтовой программы, использовавшей незащищенный порт. В настройках гуглопочты можно запретить вход через небезопасное соединение.
3) Проверить настройки гуглопочты — а не появились ли там переадресации и разрешение доступа с других емайлов?
Насчет расширения — а почему нет? Их никто не проверяет, разработчик мог в одном обновлении добавить вредоносный код, в следующем убрать. Или, что более вероятно, в расширении, взаимодействующем со страницей, может быть уязвимость, позволяющая пробросить и выполнить свой JS-код внутрь расширения. Хотя, мне конечно, это кажется сложным и маловероятным, вместо того чтобы ломать голову и ковырять расширения, которые использует 0.0000% пользователей, выгоднее купить старый добрый эксплойт против Adobe/Java и получить полный контроль над машиной.
Теоретически Гугл мог оставить дыру в веб-интерфейсе, через которую угнали авторизационные данные, но это маловероятно. Об этом бы трубили по всему интернету.
Вообще, конечно, это все выглядит странно, учитывая неслабый комплекс мер, которые вы принимаете.
И да, не вздумайте пользоваться grep. Это древняя-предревняя утилита комнадной строки, которая удобна лишь фанатикам-линуксоидам, которые видимо привыкли в молодости сидеть уткнувшись носом в экран, и до сих пор не хотят перейти на современное ПО, видимо мозги застыли. Лучше используйте редактор вроде Sublime Text который делает поиск и навигацию по результатам наглядной и удобной.
Если доступ только по FTP, то кто мешает выкачть код на локалхост и искать там? Никто. Более того, выкачать код все равно придется, чтобы вноситть изменения.
Вы даете ужасные советы. Какой кофескрипт, сначала надо в совершенстве изучить JS/DOM, а потом уже думать, нужен ли (по моему, не нужен) этот кофескрипт. Boilerplate — лишний ненужный код. Less опять же может пригодиться разве что в огромном проекте, в маленьких задачах это оверкилл.
Бутстрап нужен, если у вас нет дизайна, а надо чтобы страница не выглядела страшно. Если дизайн вам рисует дизайнер. он опять же даром не нужен.
Ну, если у вас есть какой-то абсолютно одинаковый блок, который встречается в нескольких разных страницах (вроде блока последних постов на Хабре), я бы его вынес в отдельный шаблон и инклудил. Не знаю, позволяет ли это используемая вами технология, если нет, то это очень плохо, придется и дальше страдать копипастом со всеми вытекающими.
Также, я бы посоветовал как-то системно организовать шаблоны, по папкам и файлам. чтобы не надо было «по страницам их выискивать», а сразу было ясно, где находится тот или иной код.
Что касается сниппетов — это проще, чем вы думаете, достаточно одной страницы и таблицы с 2 колонками: слева — код, справа — как это выглядит (то есть, тот же код, только вставленный как HTML). Но это вариант именно для штук вроде кнопок, окошек, иконок, уголков — таких элементов, которые всюду встречаются.
А в зомби в Линукс процесс превращается только в 1 случае: если его родитель жив, ребенок завершился, а родитель не собрал информацию о завершении (детали в man wait).
Готовое опенсурс решение не обазательно будет лучше и содержать более качественный код, чем свое. Пример: вордпресс, Друпал и Джумла — опен сурс, а код страшный как 3-я мировая.
Чтобы повысить время реакции, при отсутсвии задач надсмотрщик может постоянно опрашивать базу, или например слушать UDP порт (через который его можно пнуть и сказать что появилась новая задача).
> Если псле преоброзования фурье, сложного сигнала (ЭЭГ) в спектре есть пики 70, 140, 280 Hz… можно предположить, что основная частота 70, а последующие это ее гармоники?
Надо наблюдать изменение сигнала во времени, если эти гармоники появляются/двигаются/ичезают вместе с основной частотой, то скорее всего, да. Гармоники появляются, когда у нас есть периодический (то есть повторяющийся в каждом периоде), но при этом не идеально синусоидальный сигнал. То есть, малейшее отклонение от формы синусоиды вызовет появление на спектрограмме кратных гармоник. А идеальная синусоида дает на спектрограмме ровно 1 идеальный пик. А если частота синусоиды (или сигнала) не идеальная, а плавает, или плавает амплитуда, пик утолщается и размазывается.
И откуда в человеке возьмется частота 70 Гц? Это наверно какие-то наводки. Я вообще сомневаюсь, что человек способен генерировать хоть сколько-нибудь стабильный сигнал.
Вот тут stackoverflow.com/questions/1596782/how-to-unset-a-javascript-variable написано, что delete удаляет только элементы из хеша. От себя добавлю, что людей, которые пытаются или хотят удалить локальную переменную в яваскрипте надо пинками выгонять вон — за непрофессионализм и отсутствие здравого смысла.
Ну и раз локальные переменные никогда не удаляются, проверять их на существование тоже нет никакого смысла. Ну а проверять наличие элемента в хеше надо не с помощью typeof и костылей, а с помощью in — только по той причине что он предназначен специально для этого. А то это то же, что и забивать гвозди пассатижами — молоток для этих целей подходит гораздо лучше.
Те, кто пишут typeof вместо in, им либо стоит для начала получше изучить язык, на котором пишут, либо стоит не копировать бездумно где-то увиденный неправильный код.
Это плохой и неправильный код из 90-х. Не стоит его использовать. Чтобы проверить наличие ключа в хеше, есть специально для этого сделанное для этого предназначенное слово in:
if ('alert' in window) {… }
Или, можно в данном случае сделать еще проще:
if (window.alert) {… }
> как сделать переменную неустановленной?
variable = undefined, так? А зачем. если не секрет?
P.S. Тем, кто устроил обсуждение выше, какой вид равно быстрее: ребята, вы наркоманы.
Methos а зачем вообще нужен isset(), что, программист сам не помнит, какие переменные он использует? Можно воспользоваться поиском по слову var. А isset — это какой-то костыль.
1) наличие/отсутствие трояна проверить полным сканированием последней версией антивируса, отключив предварительно интернет (на случай если кто-то следит через RDP) и возможно загрузившись с внешнего носителя.
2) Проверить, можно ли подключиться к гугловскому аккаунту через SMTP/IMAP по незашифрованным портам. Если можно — может быть, был перехвачен пароль при авторизации почтовой программы, использовавшей незащищенный порт. В настройках гуглопочты можно запретить вход через небезопасное соединение.
3) Проверить настройки гуглопочты — а не появились ли там переадресации и разрешение доступа с других емайлов?
Насчет расширения — а почему нет? Их никто не проверяет, разработчик мог в одном обновлении добавить вредоносный код, в следующем убрать. Или, что более вероятно, в расширении, взаимодействующем со страницей, может быть уязвимость, позволяющая пробросить и выполнить свой JS-код внутрь расширения. Хотя, мне конечно, это кажется сложным и маловероятным, вместо того чтобы ломать голову и ковырять расширения, которые использует 0.0000% пользователей, выгоднее купить старый добрый эксплойт против Adobe/Java и получить полный контроль над машиной.
Теоретически Гугл мог оставить дыру в веб-интерфейсе, через которую угнали авторизационные данные, но это маловероятно. Об этом бы трубили по всему интернету.
Вообще, конечно, это все выглядит странно, учитывая неслабый комплекс мер, которые вы принимаете.