5.5.1.1 Требования к нумерации группы кадров:
а) Группы кадров должны нумероваться последовательно по возрастанию.
б) Нумерация должна начинаться с 1.
в) Шаг нумерации равен 1.
Где начало нумерации?
Предположим, у меня отдельно камера и отдельно регистратор, который пишет видео на SD-карту и при этом добавляет подпись. Каждый час он создает новый файл. Вопрос — при этом номер группы кадров сбрасывается?
Как я понимаю, это требования к форматам контейнеров, на основании соответствия которым можно будет делать вывод о защите видеоданных в контейнере по уровню I или уровню II.
У меня есть такие вопросы:
1. Некоторые IP-камеры вместе с видео передают еще и аудио. Почему в стандарте не предусмотрена возможность защищать от случайных или намеренных искажений еще и аудио?
2. Существуют ли стандартизованные на сей день контейнеры, в которые требуемую согласно уровню I электронную подпись можно поместить уже сейчас без поломки читающего их ПО? [подозреваю, что в MPEG-TS будет достаточно отдельного PID'а]
3. Определение опорного кадра в стандарте отличается от общепринятого — так и задумано? Существенное изменение картинки вовсе не обязательно. Некоторые камеры расставляют опорные кадры (в понимании стандарта H.264) просто периодически. IMHO, если такое отличие не задумано, лучше будет делегировать определение опорного кадра стандарту на используемый видеокодек.
4. «Номер последнего опорного кадра для сжатых кадров» — что туда полагается писать, если речь идет о потоке без опорных кадров (H.264 такое допускает — ошибки «самозалечиваются» при декодировании с любого кадра)? Или следует признать, что такие потоки не могут быть защищены по уровню защиты I?
5. «Источники видеоинформации должны иметь техническую защиту, исключающую возможность съема и/или подмены закрытого ключа» — правильно ли я понимаю, что я не должен иметь возможность его перегенерировать (заменить на новый случайный, неизвестный мне), даже зная пароль для настройки?
6. Почему стандарт не предусматривает техническую защиту от несанкционированного изменения показаний часов?
Почему-то в статье к команде swapon не добавлена опция -d, которая заставляет ядро делать discard на блоки swap'а, которые не нужны. Без этой опции, если система попользуется swap'ом и потом посчитает, что больше ей там хранить нечего, сжатые страницы ей не вернутся.
Посмотрел доку тут: nokogiri.org/Nokogiri/XML/ParseOptions.html — на вид это обычный binding к libxml2. Т.е. при включенной опции NOENT и выключенной опции NONET все бомбы, кроме первой, должны сработать. После обновления до версии libxml2 из git может перестать работать вторая бомба.
Согласен, валидация по схеме не имеет перечисленных недостатков, т.к. схема не является частью самого XML-документа. Но мало ли — вдруг хакер решит проверить, не забыли ли вы отключить валидацию входящих документов по DTD.
Существует ли простой пример, в котором каждый шаг итеративного подхода не натыкается на вырожденную или близкую к вырожденной матрицу, но сам итеративный процесс не является сходящимся?
Если известно, что приложение будет исполняться в типичном UNIX-окружении, то, несмотря на обратное утверждение автора статьи, настройки SMTP-сервера можно и захардкодить: 127.0.0.1:25 без авторизации, т.к. в рассматриваемом окружении это всегда правильно. Это уже дело локального почтового сервера переслать письмо через правильный почтовый релей с авторизацией под правильной учетной записью.
Или тупо вызвать sendmail, который работает (складывает письмо в очередь) даже если собственно smtp-демон в данный момент перезапускается. Лишь бы хватало места и inodes.
Если известно, что приложение будет исполняться в типичном UNIX-окружении, то, несмотря на обратное утверждение автора статьи, настройки SMTP-сервера можно и захардкодить: 127.0.0.1:25 без авторизации, т.к. в рассматриваемом окружении это всегда правильно. Это уже дело локального почтового сервера переслать письмо через правильный почтовый релей с авторизацией под правильной учетной записью.
Признаю, что допустил ошибку в подаче материала. Давайте не будем зацикливаться на этом частном примере, где сотрудник Роскомнадзора не выбросил сессионный параметр из URL'а. Перейдем к более общему случаю.
В каждом элементе XML, по факту, есть элемент <url>. В большинстве случаев, там корневой URL сайта. И что, при проверке Вы будете утверждать, что Роскомнадзор действительно хочет, чтобы заблокированы были только главные страницы? Это же нелепо, и проверяющий скажет Вам, что это нелепо! На этом аргументы и кончатся, так как правило сравнения URL'ов в запросе и в реестре не определено. А так как речь идет об административном правонарушении, то действует презумпция вины. А если бы такое правило сравнения было, то на него можно было бы опереться и установить, кто на самом деле прав — в чем и смысл статьи.
Отвечать-то придется тому сотруднику, к которому придет проверка из прокуратуры. И в неправильном с точки зрения проверяющих (т.е. «надо заблокировать только /index.php» а не «надо заблокировать весь сайт») прочтении мыслей Роскомнадзора виноват будет тоже он. Проблема именно в том, что приходится учиться читать мысли. Вы же сами пишете: «конкретный урл или префикс». Так можете определиться, URL или префикс, не читая мысли?
P.S. При отсутствии технической возможности блокировать ровно те страницы, которые нарушают закон, Роскомнадзор разрешает блокировать больше, чем нужно. А блокировать меньше чем нужно — не разрешает.
Где начало нумерации?
Предположим, у меня отдельно камера и отдельно регистратор, который пишет видео на SD-карту и при этом добавляет подпись. Каждый час он создает новый файл. Вопрос — при этом номер группы кадров сбрасывается?
У меня есть такие вопросы:
1. Некоторые IP-камеры вместе с видео передают еще и аудио. Почему в стандарте не предусмотрена возможность защищать от случайных или намеренных искажений еще и аудио?
2. Существуют ли стандартизованные на сей день контейнеры, в которые требуемую согласно уровню I электронную подпись можно поместить уже сейчас без поломки читающего их ПО? [подозреваю, что в MPEG-TS будет достаточно отдельного PID'а]
3. Определение опорного кадра в стандарте отличается от общепринятого — так и задумано? Существенное изменение картинки вовсе не обязательно. Некоторые камеры расставляют опорные кадры (в понимании стандарта H.264) просто периодически. IMHO, если такое отличие не задумано, лучше будет делегировать определение опорного кадра стандарту на используемый видеокодек.
4. «Номер последнего опорного кадра для сжатых кадров» — что туда полагается писать, если речь идет о потоке без опорных кадров (H.264 такое допускает — ошибки «самозалечиваются» при декодировании с любого кадра)? Или следует признать, что такие потоки не могут быть защищены по уровню защиты I?
5. «Источники видеоинформации должны иметь техническую защиту, исключающую возможность съема и/или подмены закрытого ключа» — правильно ли я понимаю, что я не должен иметь возможность его перегенерировать (заменить на новый случайный, неизвестный мне), даже зная пароль для настройки?
6. Почему стандарт не предусматривает техническую защиту от несанкционированного изменения показаний часов?
Или тупо вызвать sendmail, который работает (складывает письмо в очередь) даже если собственно smtp-демон в данный момент перезапускается. Лишь бы хватало места и inodes.
В каждом элементе XML, по факту, есть элемент <url>. В большинстве случаев, там корневой URL сайта. И что, при проверке Вы будете утверждать, что Роскомнадзор действительно хочет, чтобы заблокированы были только главные страницы? Это же нелепо, и проверяющий скажет Вам, что это нелепо! На этом аргументы и кончатся, так как правило сравнения URL'ов в запросе и в реестре не определено. А так как речь идет об административном правонарушении, то действует презумпция вины. А если бы такое правило сравнения было, то на него можно было бы опереться и установить, кто на самом деле прав — в чем и смысл статьи.
P.S. При отсутствии технической возможности блокировать ровно те страницы, которые нарушают закон, Роскомнадзор разрешает блокировать больше, чем нужно. А блокировать меньше чем нужно — не разрешает.