Перейти к содержимому
Калькуляторы

sw29

Пользователи
  • Публикации

    24
  • Зарегистрирован

  • Посещение

Все публикации пользователя sw29


  1. И даже больше! Там черным по белому написано про несоотвтетствие версии ПО Ревизор заявленной в сертификате. Это точно что-то новое!
  2. Полагаю, тут все же вопрос был в юридической оценке. Мы-то - да, ловить должны все движения. Но выглядит все это как-то неверно.
  3. А можно эту мысль чуть подробнее? Что именно хотелось бы? Пытаюсь понять, чего вам не хватает, и почему я не испытываю необходимости в этом же дополнении. Я без стеба - реально интересно.
  4. По большому счету они думают. И именно поэтому не делают совсем уж резких действий. Но как известно, слона надо есть по частям. И они его планируют съесть. Поэтому медленно, потихоньку, будут поджимать. Обратите внимание, как пример, уже Youtube, находящийся вне юрисдикции РФ, идет навстречу и прикрывает ролики на нашей территории, не нравящиеся государству. Да, они не смогут сделать все быстро. Но потихоньку подготавливая, все же добъются своего. Если хватит терпения и не перестараются.
  5. От РЧЦ получили устное, но официальное объяснение (версию). Идея такова: в РФ достаточное количество тормознутых ДНС (имеются в виду не очень высокого уровня) c периодом обновления до недели. Именно поэтому было принято решение чекать не только свежие дестинейшены, полученные от ДНС, но и старые - полученные из реестра. В ответ мы указали на то, тчо теория о недельном обновлении не очень сочетается с практикой чекания адресов двухгодичной давности. Нас точно услышали и с большой вероятностью учтут в каком-то будущем. Вопрос в том, что им придется прикручивать изменения, а это - как минимум время. Поэтому пока что это просто нужно все иметь в виду и заворачивать на фильтра все, что просят.
  6. Дмитрий, а скажите пожалуйста... Действительно ли отвечает требованиям законодательства инициатива проверять доступ к сайтам с использованием IP-адресов, которые уже невозможно получить через сервера DNS? (я понимаю, что бывают и cdn-сервисы, и разные IP для разных гео-зон) Где-то тут мелькала отписка от представителей РЧЦ: "ответ от начальника Отдела организации мониторинга интернет-ресурсов Аппарата управления РЧЦ, В.А. Минакова: Отвечаю на поставленный ниже вопрос всем филиалам. В соответствии со 149-ФЗ, оператор обязан заблокировать любые указатели в сети интернет, которые позволяют идентифицировать запрещенный ресурс. К указателям относятся как URL-запись, так и IP-адрес. Соответственно, все записи из реестра должны быть заблокированы." Это дейставительно так согласно букве закона? Или там настолько ОБЩЕ написано, что можно трактовать и так и сяк? Вроде как первоначальная трактовка IP-адреса в реестре предполагала использование данного IP для блокировок при невозможности фильрации по URL. Но это мое мнение, а я не юрист. Поэтому интересно, есть ли тут хоть какой-то шанс трепыхаться.
  7. А главное - абсолютно бесполезно блокировать доступ Ревизору к другим днс-серверам: он к ним не лезет. Повторюсь, что узнал от сотрудника РЧЦ: ревизор делает опрос ресурсов с использованием ДНС, полученного по DHCP, после чего выполняет опрос тех же доменов, но целевыми IP для GET-запросов выступают IP-адреса, взятые из Реестра.
  8. Сегодня имел возможность поговорить по телефону с неким представителем регионального РЧЦ. Из полученной информации следует, что в ходе проверки Ревизор теперь проверяет доступность ресурсов сначала с использованием настроенного DNS, а затем (вот только не знаю, сразу или вторым кругом) с использованием IP адреса из реестра. При этом URL в GET-запросе не изменяется, т.е. IP туда не подставляется, о чем я грешным делом допускал. В общем, куда копать - стало ясно. Что осталось непонятным (требует перечитывания Рекомендаций) - должны ли мы были изначально так делать? Или разрезолвленных доменов должно было хватать для следования рекомендациям?
  9. Да, я видел это. Осталось понять, что именно такое они запрашивают, что имеется в виду под "запрашивают и по IP теперь". Мне непонятно. что за запросы они делают, что в итоге что-то окрывается. Есть предположение (только предположение!), что они делают запросы вида http://ip-address, где ip-address - айпишники полученые разрешением всех хостов. И поскольку на некоторых IP по умолчанию действительно открывается какая-то страничка (например It's work!!!), то она и попадает в отчет? Коллеги, кто разобрался, прошу подсказку.
  10. Коллеги, а никто не узнавал новую процедуру проверки блокировок ревизором? Что именно они там изменили? Я знаю лишь, что это связано с IP-адресами. Но вот что такого они с ними делают... И отчего в отчете о пропусках появились страницы и домены не имеющие отношения к Реестру?.. Эх, знать бы методику проверки...
  11. Необходимость блокировки только того, что в реестре - поддерживаю. Ну и какое-то количество по локальным предписаниям. Я правильно понимаю, что в данном случае (у нас тоже выскочило некоторое количество ссылок, отсутствующих в реестре, в том числе и упомянутая www.ameliadavismd.com) можно не сильно париться? Я порекомендовал своим ркн-контактерам связаться с куратором и сообщить о таком странном отчете. Результатов пока не знаю.
  12. Коллеги, большое спасибо за уделенное внимание! Предварительно для себя выношу, что точно не стоит этим заниматься (идентификацией по инономерам), себе дороже встанет. Однако, надо все же заметить, что пребывание иностранцев в РФ станет чуть менее комфортным. Допустим, в отеле они успешно получат доступ по документам. Но ни в музеях, ни в кафе (и наверное в метро тоже) этого уже не получится. Разве что на каждом углу свой паспорт позволять фотографировать. Ну и правильно! Пусть практикуют живое общение :)
  13. Коллеги, совсем никто не сталкивался? Есть у кого-то опыт работы с идентификацией иностранцев при работе с общественным Wi-Fi?
  14. Всех приветствую! Поскольку тема все же называется маневры с DNS, позволю себе задать вопрос не про используемое обсуждаемое решение: Есть в реестре запись за номером 355671 - луковая ссылка, да еще и с подчеркиванием в третьем уровне. Кто как реализовал блокировку? Блокировать весь onion.link как-то неправильно, а организовать зону для домена с подчеркиванием - bind не позволяет.
  15. Всем доброго времени! Дмитрий, простите, вашей цитатой привлекаю ваше внимание, поскольку очень рассчитываю на ваш ответ на основе накопленного опыта. Идентификация пользователей Wi-Fi в местах коллективного доступа - тема во многом понятная и уже не особо вызывающая споры. Но. Прошу помочь с таким вопросом: является ли достаточной и приемлемой идентификация пользователя при условии, что он это делает с использованием номера мобильного телефона зарегистрированного за пределами РФ? Интересны мнения представителей операторов реализующих у себя подобную идентификацию. Возможно кто-то на этом уже "съел собаку", возможно получены разъяснения или "Ай-яй-яй" от представителей надзорных органов. История возникновения вопроса - как-то обрывочно слышал, что якобы кто-то получал комментарии из "компетентных" органов, мол импортный номер не является однозначным идентификатором (про местные симки продающиеся на всех бойких углах нашей необъятной предлагаю не вспоминать). ЗЫ: А тема-то уже три месяца не ворошилась... У всех видать вопросов нет уже. Надеюсь, не только мне будет это интересно. В конце концов к примеру, в том же Эрмитаже подобную услугу сложно представить без идентификации иностранцев, проще не предоставлять. Кстати, не знаю, есть ли он там...
  16. Коллеги, а в итоге сейчас какая практика реальная на этот счет? В каждом регионе у каждого инспектора свой взгляд? Т.е. одна незаблоканная ссылка - уже гарантировано разбирательство, или есть все же допустимый процент на что они глаза закрывают? Или все же у каждого региона своя песня? (всё это интересует для случая с установленным ревизором, не про ручные проверки выездных мобильных групп. Себе пока не поставили еще, в процессе переписки\заказа)
  17. Я тоже блокирую домен целиком. Но есть недопонимание в алгоритмах работы DPI, хотел уточнить, как оно у людей. Записи в дампе с id 368546, 340515, 367295 к примеру. Они все только https ссылку имеют. Согласен. Дмитрий, я не учел серьезность формулировок. На момент вчера это было что-то типа устного ай-яй-яй. Коллеги выпросили двое суток на разбор ситуации. Ждем завтра снова в гости. Сейчас ни акта, ни протокола, ни претензиий оформленных нет. Надеюсь, удастся убедить товарищей, что отсутствие ссылок в реестре предполагает свободный доступ к ним.
  18. Коллеги, есть вопрос, возможно наивный. Не имел никогда на руках DPI, поэтому хочется спросить у счастливых владельцев, эксплуатирующих данные железки в условиях суровой действительности давления со стороны РКН. В итоге, HTTPS-ссылки блокируются данными устройствами поштучно, или на уровне домена? И есть ли случаи с ненадлежащей блокировкой? (видел выше идеи об ответственности производителей, которая пока не прописана в договорах) И в дополнение, поскольку пока ограничен в количестве сообщений: Вчера представители РКН выкатили претензию по результатам предварительной проверки с кучей незаблокированных ресурсов. При подробном рассмотрении выяснилось, что нам вменяют неблокировку http-страниц при наличии в дампе реестра ТОЛЬКО https-ссылки. То есть новое прочтение рекомендаций случилось. Но не в этом вопрос. Тестирование проводилось неким ПО WebEye. Слышал ли кто-то о таком чуде? Допускаю, что это пока еще сырой софт на смену старенькому RegisterCheck, типа с новыми алгоритмами, учитывающими последние рекомендации. Что скажете?
  19. Так и оказалось. Запуск rusrknconvertor, а затем и RegisterCheck на компе с установленным Excel дали положительный результат. Все отработало, отчеты получены. Спасибо!
  20. Благодарю! Файл формируется нормально, хоть и не похож на выложенную мной таблицу. Настраиваю столбцы, код заглушки... Получаю ошибку "Произошла ошибка при получении данных из файла. Дальнейшая работа не возможна!" Есть версия, что это может быть связано с отсутствием офиса на моем ПК. Попробую позже на другом. Но если будут идеи, или кто-то побеждал уже в свое время эту беду - с благодарностью выслушаю.
  21. Пробую приложить файл.... Это несколько строк из шестиметрового файла годичной давности Файл в екселевском виде мне загрузить не разрешили условия форума, прикладываю картинку
  22. Коллеги, прошу прощения, что с не совсем свежим вопросом... Но может ли кто-то помочь понять, как на основе xml-файла выгрузки из Реестра сформировать файл для РКН-новской программки RegisterCheck (vs1.9.9)? Есть ли человеческие способы, или нужно писать самому? На крайний случай, поделитесь свежим файлом. Нужно буквально для однократного запуска. Но на всякий случай хочется уметь его делать, если человеческий способ все же существует. Заранее благодарен! P.S. Удалось найти на форуме упоминания про rusrknconvertor.zip выложенный на Я-диск, но архив не скачивается.
  23. Коллеги, прошу прощения, что с не совсем свежим вопросом... Но может ли кто-то помочь понять, как на основе xml-файла выгрузки из Реестра сформировать файл для РКН-новской программки RegisterCheck (vs1.9.9)? Есть ли человеческие способы, или нужно писать самому? На крайний случай, поделитесь свежим файлом. Нужно буквально для однократного запуска. Но на всякий случай хочется уметь его делать, если человеческий способ все же существует. Заранее благодарен!
  24. Добрый день! Извиняюсь за беспокойство, но очень прижала необходимость раздобыть свежий файл для программки Register Check. Как минимум - разово рабочий файл, а если сможете научить, как его лепить из xml-реестра - буду премного благодарен.

    С уважением.