Необходимые и достаточные условия
От: gear nuke  
Дата: 15.05.10 12:34
Оценка:
Анализируя ошибки в решениях, заметил, что часто (я бы сказал всегда, но всех случаев не знаю) их можно свести к тому, что автор не видит чем достаточные условия отличаются от необходимых. При этом авторы очевидно понимают разницу между И и ИЛИ.

Почему же получается так, как есть? Невнимательность, agile, нехватка ресурсов, требования рынка?

Вот например Гугол позиционирует Хром как якобы безопасный браузер, архитектура которого препятствует попаданию малвари. В тоже время он никак не защищает от кражи кредиток формграбберами, то есть реальной, а не мнимой угрозы.

Поэтому сомневаюсь, следует ли помещать в список причин выше "использование неподходящих инструментов".
People who are more than casually interested in computers should have at least some idea of what the underlying hardware is like. Otherwise the programs they write will be pretty weird (c) D.Knuth
Re: Необходимые и достаточные условия
От: gear nuke  
Дата: 15.05.10 12:35
Оценка:
GN>Вот например Гугол

что-то с нехваткой ресурсов я потропился
People who are more than casually interested in computers should have at least some idea of what the underlying hardware is like. Otherwise the programs they write will be pretty weird (c) D.Knuth
Re: Необходимые и достаточные условия
От: Ромашка Украина  
Дата: 15.05.10 20:26
Оценка:
Здравствуйте, gear nuke:
> Анализируя ошибки в решениях, заметил, что часто (я бы сказал всегда, но
> всех случаев не знаю) их можно свести к тому, что автор не видит чем
> достаточные условия отличаются от необходимых.

Коллега, так как в своей жизни вы принимали решения и совершали ошибки,
но при этом понимаете различия между необходимым и достаточным условиям,
то из этого можно сделать только один вывод: понимание различий
необходимых и достаточных условий не является достаточным условием для
несовершения ошибок.

> Почему же получается так, как есть? Невнимательность, agile, нехватка

> ресурсов, требования рынка?

Потому что мир построен на ошибках. Вы не можете даже измерить свой стол
без ошибки. Проще нужно относится к ним: программа должна быть написана
так, чтобы ошибки умещались в какую-то дельта, которая в каждом случае
разная.
Posted via RSDN NNTP Server 2.1 beta


Всё, что нас не убивает, ещё горько об этом пожалеет.
Re[2]: Необходимые и достаточные условия
От: gear nuke  
Дата: 15.05.10 22:31
Оценка:
Здравствуйте, Ромашка, Вы писали:

Р>Коллега, так как в своей жизни вы принимали решения и совершали ошибки


Жизнь сложнее компьютерной программы. Люди, в отличие от компьютеров, делают что хотят, а не что просишь. Другие условия, вот и ошибки

Р>Потому что мир построен на ошибках.


Наука пока не знает из чего он построен, в отличие от программ, в которых уже научились защищаться от многих типов не только случайных, но и намеренных ошибок, при помощи методик и/или инструментов.

Р>Вы не можете даже измерить свой стол

Р>без ошибки.

Могу, с определённой погрешностью измерений. Если дальше следовать анологиям, то должны быть способы оценить количество оставшихся багов, например некоторой статистикой.

А как быть с ошибками проектирования? Ведь всего-то нужно учесть хоть одно достаточное условие. Выходит, проектируют не имея полного понимания решаемой задачи?

Р> Проще нужно относится к ним: программа должна быть написана

Р>так, чтобы ошибки умещались в какую-то дельта, которая в каждом случае
Р>разная.

Если программа считает число Пи всего до 10го знака — это корректная программа. Програма с ошибкой считает его не всегда, а в случаях когда пользователь ввел его половину

Или имеются ввиду требование рынка?

— Товарищь генерал, машина не заводится!
— Поехали, потом заведёшь!
People who are more than casually interested in computers should have at least some idea of what the underlying hardware is like. Otherwise the programs they write will be pretty weird (c) D.Knuth
Re: Необходимые и достаточные условия
От: мыщъх США http://nezumi-lab.org
Дата: 16.05.10 02:46
Оценка: 46 (4) +1 :))
Здравствуйте, gear nuke, Вы писали:

GN> Вот например Гугол позиционирует Хром как якобы безопасный браузер, архитектура которого препятствует попаданию малвари.

GN> В тоже время он никак не защищает от кражи кредиток формграбберами, то есть реальной, а не мнимой угрозы.
GN> Поэтому сомневаюсь, следует ли помещать в список причин выше "использование неподходящих инструментов".
безопасность -- это буззворд. юзеры это слово любят и повторяют как мантру, но оценить безопасность не может даже эксперт по этой самой безопасности. атаковать можно все браузеры (ни один не избежал ошибок), но в реальности атакуют все больше IE.

кстати, в хороме уже обнаружен каскад критических ошибок. так что интересно -- в каком именно месте его архитектура чему-то там препятствует? вот у последних IE -- там по умолчанию включен DEP с ASLR и нет JIT. если еще вырубить SWF и прочие ActiveX, то мы получим очень трудно атакуемый браузер. если врубить -- атака в общем-то тривальна. у хрома JIT есть. причем предсказуемый. что существенно облегчает на него атаку, делаяя ее в общем-то тривальной. а не атакуют его потому что он никому не нужен. тут даже лиса только-только атаковать стали, а у хрома популярность в разы ниже.

а необходимое и достаточное в контексте безопасности постоянно путают. вот, например, антивирус не является ни необходимым, ни достаточным, но его ставят почти все. обновления являются и необходимым и (в большинстве случаев) достаточным условием обеспечения безопасности, но ими пренебрегают или обновляют только винду, но забывают про офис.
americans fought a war for a freedom. another one to end slavery. so, what do some of them choose to do with their freedom? become slaves.
Re[3]: Необходимые и достаточные условия
От: FR  
Дата: 16.05.10 04:00
Оценка:
Здравствуйте, gear nuke, Вы писали:

GN>А как быть с ошибками проектирования? Ведь всего-то нужно учесть хоть одно достаточное условие. Выходит, проектируют не имея полного понимания решаемой задачи?


Ошибки проектирования неизбежны, проектирование в общем случае — "грязная проблема":

«Грязная проблема» — это проблема, которую можно ясно определить только путем полного частичного или решения.

Re: Необходимые и достаточные условия
От: FR  
Дата: 16.05.10 04:05
Оценка:
Здравствуйте, gear nuke, Вы писали:

GN>Анализируя ошибки в решениях, заметил, что часто (я бы сказал всегда, но всех случаев не знаю) их можно свести к тому, что автор не видит чем достаточные условия отличаются от необходимых. При этом авторы очевидно понимают разницу между И и ИЛИ.


GN>Почему же получается так, как есть? Невнимательность, agile, нехватка ресурсов, требования рынка?


Неизбежность вытекающая из самой сути процессов, вот цитата от gaperton'а:

Тем, что разработка — empiric process, а не defined process. В случае empiric process точность соблюдения технологии и процесса не гарантирует результата в принципе, потому, что какие бы "типовые" работы не были. Потому, что все они сопряжены с решением проблем, способ решения которых повлияет на структуру результата, и результат определяется не соблюдением технологии, а человеческим вкладом и личными качествами исполнителей.

Re[4]: Необходимые и достаточные условия
От: gear nuke  
Дата: 16.05.10 09:29
Оценка:
Здравствуйте, FR, Вы писали:

FR>Ошибки проектирования неизбежны, проектирование в общем случае — "грязная проблема":


Ну и, в общем случае, wicked problem решается за счет различных "циклических" методик разработки. То есть существование "промежуточной" версии обусловлено требованиями заказчика "надо вчера".

В данном случае я вижу существенную деталь: разработчики осознают неидеальность своих знаний, то есть они пока не поняли какое условие является достатчным для решения проблемы, и ищут его методом "научного тыка", а не "проб и ошибок"; много ресурсов тратится на ресёрч и обратную разработку.

Промежуточная версия — по сути недоделка, а не ошибка.
People who are more than casually interested in computers should have at least some idea of what the underlying hardware is like. Otherwise the programs they write will be pretty weird (c) D.Knuth
Re[2]: Дополню.
От: Gaperton http://gaperton.livejournal.com
Дата: 16.05.10 10:10
Оценка: 310 (18) +1 -1
Здравствуйте, FR, Вы писали:

Ну да. Позже я пришел к выводу, что разделение на defined и empiric процессы само по себе не вполне корректное и не самое точное. Более правильно взглянуть на проблему под чуточку другим углом.

Корень проблемы, лежащий в интуитивном непонимании природы процессов разработки лежит в феномене, который я назвал "производственная ментальность".

В чем отличие проектной деятельности от производственной? Цель производственного процесса — сделать серию как можно более одинаковых изделий. Как этого достичь? Нам нужен процесс, который гарантирует качество. Так и делают.

Результат же каждого проекта уникален — таково определение проектной деятельности, и в этом ее сущность. Можно навесить на нее процесс, который будет гарантировать "качество" результата?

Скажем так, на определенном уровне абстракции, с которого все проекты выглядят для нас одинаково — да. Можно. И этот "процесс" будет нам помогать обеспечивать одинаковость этих абстрактных характеристик.

Но, при этом, совершенно неизбежно данный процесс будет игнорировать тот самый уникальный результат. А именно он, уникальный результат — и есть суть проекта. И, таким образом, обеспечить успех проекта процесс не способен принципиально.

Вывод? Акцент на процессах в проектной деятельности — безусловное зло. Процессные люди руководить разработкой не должны. Акцент должен быть на том самом уникальном результате, он главнее.

Значит ли это, что никакой "процесс" не нужен? Нет. Просто он не должен стоять во главе угла, и касаться частных процедур, которые реально не зависят от результата, и всегда одинаковы. Пример? Процедура чекина.

Эти рассуждения общие для всех видов проектной деятельности. Никакой софтверной специфики для объяснения не требуется.

Все вроде просто и понятно, но "производственная ментальность" интуитивно человеку понятна, и пустила свои корни очень глубоко. Гораздо глубже, чем кажется. И от нее очень непросто избавится. Скажем, ей пронизан весь PMBoK, как это ни смешно. Почему она и заслуживает отдельного названия. Не верите?

Показываю. Процесс понимается как набор активностей, берущих нечто на вход, и преобразующих этот вход в выход. За определенное время. Отличной, и, возможно лучшей нотацией для описания процессов является IDEF0/SADT.

В производстве процесс изготовления изделия описывается комплектом разных документов, часть которых "технологическая карта". Она показывает, из каких деталей и в какие этапы собирается изделие.

То есть, технологическая карта завязана на структуру результата. Подразумевается, что разные элементы (модули) изделия мы изготавливаем отдельно, и потом собираем из них целое. Возможно — в несколько этапов.

Технологическая карта очень похожа на план проекта, с той разницей, что по ней изготавливается много одинаковых изделий. Так как под качеством понимается одинаковость, и изделий много, у нас есть и время и возможность оптимизировать процесс. Так — правильно.

План проекта по классике (возьмем сетевой график) построен на той же концепции, и представляет собой развертку выполнения процесса во времени, в указанном выше понимании. Примерно как технологическая карта. Каждая задача — протяженна во времени. Но каждый проект уникален, и по этой "карте" в нашем случае делается ровно одно изделие. Что нам уже символизирует, правда? Но это еще не все.

Главное в "производственной ментальности" — что? Мы должны в результате проекта по разработке сделать некий артефакт. Разработчики — это такие станки. Они перерабатывают документацию в документацию другого вида, и иногда — документацию в код. Из этого кода собирается большая система.

Программисты — это дорогие станки, и их надо как следует загрузить, они не должны простаивать... И если эти станки перерабатывают документацию в негодный, неправильный код — что надо делать? Поработать над документацией, сделав ее лучше, навесить на выход контроль качества, и, возможно, заменить глючные станки на другие.

Вот что такое "производственная ментальность". И мы попадаем в ее ловушку сразу же, как начинаем писать WBS и составлять сетевой график, от структуры результата, и пользуясь шаблоном процесса. А дальше — она свое возьмет. Процессы начнем оптимизировать, CMMI-и внедрять — логично же все?

В чем проблема? А вы перечитайте, с чего мы начинали. Чтобы более явно почувствовать "когнитивный диссонанс".

Проблема в том, что разработка — это процесс решения проблем, а не изготовления артефактов. Посмотрите цикл разработки RUP — это разумный подход. Он не завязан на активности. Он основан на цикле решения проблем. И решаемые проблемы — вовсе не совпадают со структурой результата, и иерархией модулей. Это все поменяться может в процессе разработки, ибо это один из вариантов _решения_ проблемы.

Главная же проблема, что все объяснения выше для большинства людей как об стенку горох. "Производственная ментальность" — это то, чему людей не надо учить. Это почему-то почти все люди интуитивно понимают, и интуитивно этой ментальности следуют.

Разные Agile-подходы имеют одно общее место — они так или иначе выбивают "производственную ментальность" из головы. Но при этом, за редкими исключениями, херово масштабируются. И вообще — выбить ее их головы — недостаточно. Для сложных проектов нужен нормальный инструмент планирования. Сетевой график же слишком легко использовать неправильно.

"Производственная ментальность" проявляется своей гранью также в интуитивном стиле выдачи заданий. Специально не тренированные люди интуитивно предпочитают решить проблему самостоятельно, и выдать задания подчиненным в терминах одного из вариантов решения этой проблемы. По факту действуя в стиле "сборки изделия", думая об исполнителях как о "станках". Этот стиль выдачи приказов и лидерства в военном деле называется "Befehlstaktik" — детальные приказы в терминах действий, которые надо совершить.

К счастью, военные (которые, как известно, занимаются крайне рискованными проектами в условиях неопределенности) придумали выход для стиля выдачи приказов. Более чем 100 лет назад разобрались с ситуацией. Ибо — дороговато им этот "интуитивный стиль" обходился.
http://en.wikipedia.org/wiki/Mission-type_tactics

Ну раз военные справились, то почему не можем мы? Далее мы логично переходим к методике планирования, в которой в принципе нет активностей. Но это уже другая история. И так оффтопик, че развивать то.
Re[3]: Дополню.
От: Gaperton http://gaperton.livejournal.com
Дата: 16.05.10 10:42
Оценка: 21 (2)
Кросс-пост в моем ЖЖ — там это не будет оффтопиком.

http://gaperton.livejournal.com/45149.html

А процессы описывать "декларативно" — можно. Как набор событий, задаваемых критериями их наступления (набор предусловий-постусловий для "задач"), связанных временными ограничениями — вроде "это событие не может произойти раньше, чем вот это".

Это и есть "декларативное", или "событийное планирование". Данное описание обладает как свойствами описания процесса, так и плана в равной степени. И в дополнение — свойствами decision tree diagram. Трассировка требований отражена в таком плане непосредственно.

Удалось обнаружить матаппарат, стоящий за таким "планом". Для простого случая — это линейная темпоральная логика. План является логическим утверждением — его корректность относительно легко проверяется. Не автоматически правда, а мозгом.
Re[2]: Необходимые и достаточные условия
От: gear nuke  
Дата: 16.05.10 10:45
Оценка:
Здравствуйте, мыщъх, Вы писали:

М>безопасность -- это буззворд. юзеры это слово любят и повторяют как мантру,


Это больше к маркетингу относится, чем к разработке, то есть не должно влиять на "сытых" инженеров.

М>но оценить безопасность не может даже эксперт по этой самой безопасности.


Зачем же говорить за всех?

Тем не менее, спасибо, это откровение похоже и есть ответ на мой вопрос: в ряде случаев проблема в людях. Мда, если определять профи исключительно по принципу "зарабатывает этим на жизнь", туда же попадут и шарлатаны.

Процитирую одного из экспертов:

...я создал математическую утопию — алгоритмы, тысячелетиями хранящие ваши глубочайшие секреты, протоколы передачи данных, обеспечивающие воистину фантастические возможности: неконтролируемые извне финансовые операции, необнаружимую аутентификацию, анонимную оплату. И все это — незаметно и надежно.
...
Как-то однажды коллеги поведали мне, что мир наполнился плохими системами безопасности, сконструированными людьми, прочитавшими "Прикладную криптографию".
...
Прекрасные математические ходы становились никчемными из-за небрежного программирования, гнусной операционной системы или просто выбора кем-то плохого пароля.


М> атаковать можно все браузеры (ни один не избежал ошибок)


Указанная в скобочках причина не является достаточной для обобщения, ты не видел все возможные браузеры (подразумеваю наличие слова "успешно" в цитате выше).

М>кстати, в хороме уже обнаружен каскад критических ошибок. так что интересно -- в каком именно месте его архитектура чему-то там препятствует? вот у последних IE -- там по умолчанию включен DEP с ASLR и нет JIT.


Какое это имеет отношение к предотвращению кражи кредиток, которая выполняется атакой вида man in the browser? Сомневаюсь, что это является хотя бы необходимым условием.

Вот о том и речь: общий вид атаки man in the middle хорошо изучен, есть математически обоснованные способы защиты, которые являются достаточными при современном уровне технических средств. Однако, разработчики почему-то считают что достаточно понимать под каналом передачи данных внешюю линию, тем самым допускают ошибку в реализации безопасного протокола.

М>а необходимое и достаточное в контексте безопасности постоянно путают. вот, например, антивирус не является ни необходимым, ни достаточным, но его ставят почти все


Интересно не это, а причины, но оффтоп показателен.

Да, путают. Антивирус, который не ловит вирусы, суть программа другого рода. Сферический Антивирус, который ловит все возможные вирусы, является достаточным условием.

М> обновления являются и необходимым и (в большинстве случаев) достаточным условием обеспечения безопасности, но ими пренебрегают или обновляют только винду, но забывают про офис.


Обновление Сферическому Антивирусу не является необходимым.
People who are more than casually interested in computers should have at least some idea of what the underlying hardware is like. Otherwise the programs they write will be pretty weird (c) D.Knuth
Re[3]: Дополню.
От: gear nuke  
Дата: 16.05.10 12:23
Оценка:
Здравствуйте, Gaperton,

Если я правильно переварил горох, в общем-то опять же выходит что дело в людях, которые задают провоцирующий ошибки вопрос "и когда же будет релиз?" при этом не понимая, что он должен из себя представлять, и кому следует делегировать "процесс понимания".

G>К счастью, военные (которые, как известно, занимаются крайне рискованными проектами в условиях неопределенности) придумали выход для стиля выдачи приказов. Более чем 100 лет назад разобрались с ситуацией. Ибо — дороговато им этот "интуитивный стиль" обходился.

G>http://en.wikipedia.org/wiki/Mission-type_tactics

Интересно, что военная тематика перекликается с джоэльской "огонь и движение". В последнем случае задачей является "занять вон ту точку", при этом приказ будет звучать точно так же, поэтому их очень легко перепутать. А тут акценты расставлены явно.
People who are more than casually interested in computers should have at least some idea of what the underlying hardware is like. Otherwise the programs they write will be pretty weird (c) D.Knuth
Re[4]: Дополню.
От: Gaperton http://gaperton.livejournal.com
Дата: 16.05.10 15:06
Оценка:
Здравствуйте, gear nuke, Вы писали:

GN>Если я правильно переварил горох, в общем-то опять же выходит что дело в людях, которые задают провоцирующий ошибки вопрос "и когда же будет релиз?" при этом не понимая, что он должен из себя представлять, и кому следует делегировать "процесс понимания".


Скажем так, дело определенно в людях, а точнее — их интуитивны реакциях. Некоторые интуитивные реакции правильны и полезны, и следуя им люди поступают оптимально без всякого обучения. Например — интуитивная реакция на занос заднеприводной машины — правильная.

Другие — вредны и приводят к фатальным последствиям. На переднеприводной машине интуитивная реакция (сбросить газ, вывернуть руль) уже неправильная.

Суть практически полезного обучения — в том, чтобы понимать те места, где "природа" против нас, и бороться с ними. Это — полезное понимание, которое помогает действовать.

В управлении проектами я обнаружил две вредных интуитивных реакции. Армейско-анекдотский стиль выдачи заданий (Befehlstaktik, в терминах "копать здесь, от забора до обеда"), и тенденцию откладывать непонятное и рискованное на потом. Если их устранить — ничему больше можно не учить. Это главное. Все будет ок. Если их не устранять — будет жопа, что бы остальное не делалось. Я даже тренинг двухчасовой на эту тему сделал, читал у Саши Орлова (happy-pm) два раза.

Позже я понял, что Befehlstaktik — частный случай более общей проблемы — "производственной ментальности". Которая здесь и описана. В первый раз, кстати.

G>>К счастью, военные (которые, как известно, занимаются крайне рискованными проектами в условиях неопределенности) придумали выход для стиля выдачи приказов. Более чем 100 лет назад разобрались с ситуацией. Ибо — дороговато им этот "интуитивный стиль" обходился.

G>>http://en.wikipedia.org/wiki/Mission-type_tactics

GN>Интересно, что военная тематика перекликается с джоэльской "огонь и движение". В последнем случае задачей является "занять вон ту точку", при этом приказ будет звучать точно так же, поэтому их очень легко перепутать. А тут акценты расставлены явно.
Re[4]: Дополню.
От: Gaperton http://gaperton.livejournal.com
Дата: 16.05.10 15:12
Оценка: 5 (2)
Здравствуйте, gear nuke, Вы писали:

GN>Интересно, что военная тематика перекликается с джоэльской "огонь и движение". В последнем случае задачей является "занять вон ту точку", при этом приказ будет звучать точно так же, поэтому их очень легко перепутать. А тут акценты расставлены явно.


Военная тематика вообще перекликается. Военное дело — по всей видимости, наиболее близкая к инженерной деятельности тема из всех остальных. Невероятные риски. Большая неопределенность. Большая ответственность. Ограниченные ресурсы. Большие масштабы операций и проектов, требующих филигранной координации. Огромное влияние человеческого фактора — боевой дух идет как 3:1 к прочим факторам (это учитывают в планах операций — скажем, иногда ставят захват стратегически не важной цели вперед, чтобы поднять боевой дух). Политика так же сильно влияет.

И очень-очень ограниченное время реагирования — у нас проще.

При этом — человечество мало в чем настолько профессионально, и накопило такой большой опыт, как в войне.
Re[5]: Дополню.
От: Pavel Dvorkin Россия  
Дата: 16.05.10 16:01
Оценка:
Здравствуйте, Gaperton, Вы писали:

G>Военная тематика вообще перекликается. Военное дело — по всей видимости, наиболее близкая к инженерной деятельности тема из всех остальных. Невероятные риски. Большая неопределенность. Большая ответственность. Ограниченные ресурсы. Большие масштабы операций и проектов, требующих филигранной координации. Огромное влияние человеческого фактора — боевой дух идет как 3:1 к прочим факторам (это учитывают в планах операций — скажем, иногда ставят захват стратегически не важной цели вперед, чтобы поднять боевой дух). Политика так же сильно влияет.


Может, она и перекликается в чем-то, но есть очень существенное отличие. Война — это обязательно противник. И очень быстрый ответ на некие действия. Грубо говоря, если вместо успешного наступления пришлось драпать, то все планы летят к черту, и надо начинать все сначала. Все наработки — в корзину. Причина банальна — против тебя действует противник, он спланировал лучше. На следующем этапе все может поменяться.
Иными словами, тут очень четкая обратная связь, отсюда постоянная коррекция планов. Вряд ли в инженерной деятельности такое реально возможно. Инженерная деятельность — все же вторична, ей предшествует научная. Та должна доказать, что такое сделать вообще возможно, и только если она докажет, за дело возьмутся инженеры. Сначала надо придумать цепную реакцию и лазер, а уж потом атомную бомбу и CDROM.

Вот научная деятельность именно на военную и похоже. Противник — природа, она тайны отдавать не хочет. И если пошли не туда (мировой эфир, к примеру), то надо забыть все, что сделали и идти по другому маршруту. Поэтому серьезная научная деятельность непланируема.

А инженерная деятельность все же планируема.
With best regards
Pavel Dvorkin
Re[3]: Необходимые и достаточные условия
От: мыщъх США http://nezumi-lab.org
Дата: 16.05.10 19:01
Оценка:
Здравствуйте, gear nuke, Вы писали:

М>>безопасность -- это буззворд. юзеры это слово любят и повторяют как мантру,

GN>Это больше к маркетингу относится, чем к разработке, то есть не должно влиять на "сытых" инженеров.
М>>но оценить безопасность не может даже эксперт по этой самой безопасности.
GN>Зачем же говорить за всех?
затем, что это можно доказать. строго и математически. но это долго и утомительно. давайте идти от противного. если вы мне сообщите о существовании способа такой оценки, который работает, то я признаю свою неправоту.

GN> Тем не менее, спасибо, это откровение похоже и есть ответ на мой вопрос:

программу можно счиать условно-безопасной, пока ее не удается атаковать. но, поскольку помимо известных способов атак, существуют и неизвестные, то во всякий момент времени эксперт вынужден сказать, что он не располагает всей полнотой информации и потому его ответ -- это нижняя граница безопасности. скажем, если взять кол-во известных дыр в ie, ff, opera и сравнить их, то, очевидно, опера рвет всех. но дыры есть (были) даже в консольных links и lynx. о чем это говорит?

или вот сделали стек и кучу неисполняемыми и страшно обрадовались -- шелл-коды не смогут работать. но пока импелементировали эту идею хакеры догадались как ее обходить. пихать в стек адреса нужных функций с аргументами. на следующем витке борьбы ms в 64-разрядной версии стала передавать аргументы через регистры. регистры в стек не засунешь, да? и хрен это атакуешь теперь. но ведь атаковали! нашли код в памяти который загружает аргументы со стека в регистры и бросили на него управление. ms добавила рандомизацию (хоть и кривую). и тут хакеры вспомнили, что у нас есть JIT. пишем программку типа a = X ^ Y ^ Z ^ .... ZZZ (где x, Y, Z — оподы зловредных команд) и передаем управление на середину команды. и так мы обходим и DEP и ASLR.

вопрос: и как же оценивали стойкость ASLR эксперты?
ответ: гугл показывает, что оценивали ее многие. симантек вообще длинные репорты писала, указывая на недостаточную энтропию. т.е. чисто математический подход. а вот про JIT не вспомнил никто! потому как нам надо связать в один узел — SWF, JIT, значние опкодов x86,... что в общем-то совсем неочевидно.

М>> атаковать можно все браузеры (ни один не избежал ошибок)

GN> Указанная в скобочках причина не является достаточной для обобщения, ты не видел все возможные браузеры (подразумеваю наличие слова "успешно" в цитате выше).
теоритически, возможно создать браузер, который нельзя атаковать. практически — я курил сплоиты под _все_ существующие браузеры (даже экзотику, типа упомянутого выще рыся).

М>>кстати, в хороме уже обнаружен каскад критических ошибок. так что интересно -- в каком именно месте его архитектура чему-то там препятствует? вот у последних IE -- там по умолчанию включен DEP с ASLR и нет JIT.

GN> Какое это имеет отношение к предотвращению кражи кредиток, которая выполняется атакой вида man in the browser? Сомневаюсь, что это является хотя бы необходимым условием.
это затрудняет выполнение хакерского кода на машине жертвы. а хакерский код может делать все, что угодно, в том числе и похищать кредитки.

GN>Вот о том и речь: общий вид атаки man in the middle хорошо изучен, есть математически обоснованные способы защиты,

но физические имплементации содержат дыры.

GN> Да, путают. Антивирус, который не ловит вирусы, суть программа другого рода. Сферический Антивирус, который ловит все возможные вирусы, является достаточным условием.

звиняйте дядьку. что такое вирус не знает никто. что такое вредоносная программа — тоже. а потому даже сферический антивирус может ловить только известные вирусы, а все остальное... увы.

М>> обновления являются и необходимым и (в большинстве случаев) достаточным условием обеспечения безопасности, но ими пренебрегают или обновляют только винду, но забывают про офис.

GN> Обновление Сферическому Антивирусу не является необходимым.
антивирус (сферический) работает (упрщенно) путем поиска сигнарутр в проверяемом файле. сигнатуры берутся из базы. если база не содержит сигнатур вирусов, которые нас атакуют... интересно, как сферический вирус с ними справиться?
americans fought a war for a freedom. another one to end slavery. so, what do some of them choose to do with their freedom? become slaves.
Re[4]: Необходимые и достаточные условия
От: gear nuke  
Дата: 16.05.10 20:40
Оценка: -3
Здравствуйте, мыщъх, Вы писали:

М>>>но оценить безопасность не может даже эксперт по этой самой безопасности.

GN>>Зачем же говорить за всех?
М>затем, что это можно доказать. строго и математически. но это долго и утомительно. давайте идти от противного.

Зачем перекладывать с больной головы на здоровую? Видвинул гипотезу — обоснуй, тем более, что можно Только не надо убегать в нору, как обычно.

М> если вы мне сообщите о существовании способа такой оценки, который работает, то я признаю свою неправоту.


Стойким считается алгоритм, который для успешной атаки требует от противника недостижимых вычислительных ресурсов

здесь

М>программу можно счиать условно-безопасной, пока ее не удается атаковать. но, поскольку помимо известных способов атак, существуют и неизвестные, то во всякий момент времени эксперт вынужден сказать, что он не располагает всей полнотой информации и потому его ответ -- это нижняя граница безопасности. скажем, если взять кол-во известных дыр в ie, ff, opera и сравнить их, то, очевидно, опера рвет всех. но дыры есть (были) даже в консольных links и lynx. о чем это говорит?


О том, что выбран очевидный частный случай для доказательства общего без применения индукции, то есть о подмене математики демагогией.

А вот случай когда программу можно считать надёжной:

Шифр Вернама является системой шифрования, для которой доказана абсолютная криптографическая стойкость.


М>>> атаковать можно все браузеры (ни один не избежал ошибок)

GN>> Указанная в скобочках причина не является достаточной для обобщения, ты не видел все возможные браузеры (подразумеваю наличие слова "успешно" в цитате выше).
М>теоритически, возможно создать браузер, который нельзя атаковать. практически — я курил сплоиты под _все_ существующие браузеры (даже экзотику, типа упомянутого выще рыся).

Надеюсь, отсюда следует вывод: такой браузер пока не создали? То есть исходное утверждение ложно.

GN>> Какое это имеет отношение к предотвращению кражи кредиток, которая выполняется атакой вида man in the browser? Сомневаюсь, что это является хотя бы необходимым условием.

М>это затрудняет выполнение хакерского кода на машине жертвы. а хакерский код может делать все, что угодно, в том числе и похищать кредитки.

Это затрудняет проникновение кода в систему по одному из векторов атаки, не более того. Ворующий кредитки код DEP&ASLR не остановит.

GN>>Вот о том и речь: общий вид атаки man in the middle хорошо изучен, есть математически обоснованные способы защиты,

М>но физические имплементации содержат дыры.

Да, это я и писал про некоторые из имплементаций. Факт наличия дыр не интересен, другое дело — причины и способы предотвращения, вот например осознать:

разработка — это процесс решения проблем, а не изготовления артефактов


М>звиняйте дядьку. что такое вирус не знает никто


кроме Википедии?

Компьютерный вирус — разновидность компьютерных программ, отличительной особенностью которой является способность к размножению (саморепликация)


М>если база не содержит сигнатур вирусов, которые нас атакуют... интересно, как сферический вирус с ними справиться?


Побочный эффект описан, какие сигнатуры, не каменный же век. Ах, да, ваш NTR тогда курит в сторонке

любая конечная последовательность символов является вирусом для какой-либо машины

People who are more than casually interested in computers should have at least some idea of what the underlying hardware is like. Otherwise the programs they write will be pretty weird (c) D.Knuth
Re[5]: Дополню.
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 16.05.10 20:54
Оценка: +1
Здравствуйте, Gaperton, Вы писали:

G>Военная тематика вообще перекликается. Военное дело — по всей видимости, наиболее близкая к инженерной деятельности тема из всех остальных. Невероятные риски. Большая неопределенность. Большая ответственность. Ограниченные ресурсы. Большие масштабы операций и проектов, требующих филигранной координации. Огромное влияние человеческого фактора — боевой дух идет как 3:1 к прочим факторам (это учитывают в планах операций — скажем, иногда ставят захват стратегически не важной цели вперед, чтобы поднять боевой дух). Политика так же сильно влияет.


Есть и фундаментальное отличие — инженерная деятельность направлена на созидание, военная скорее на разрушение либо на сохранение статус-кво. Ближе к делу — в инженерной деятельности предполагает получение в финале целостного и законченного продукта сложной и заранее неизвестной структуры, а не достижение простых и понятных целей.
... << RSDN@Home 1.2.0 alpha 4 rev. 1471 on Windows 7 6.1.7600.0>>
AVK Blog
Re[5]: Необходимые и достаточные условия
От: мыщъх США http://nezumi-lab.org
Дата: 16.05.10 21:33
Оценка:
Здравствуйте, gear nuke, Вы писали:

GN>Зачем перекладывать с больной головы на здоровую? Видвинул гипотезу — обоснуй, тем более, что можно Только не надо убегать в нору, как обычно.

щас обосную (ниже)

М>> если вы мне сообщите о существовании способа такой оценки, который работает, то я признаю свою неправоту.

GN>

Стойким считается алгоритм, который для успешной атаки требует от противника недостижимых вычислительных ресурсов

GN>здесь
сударь, в реальной жизни атакуется не алгоритм, а его имплементация _ПЛЮС_ окружение в котором он работает. именно потому https не защищает данные от перехвата, даже если сам https реализован должным образом. достаточно одно единственной дыры в браузере, системе или даже посторонних программах. таким образом, использование https для платежей в иннете не является достаточным условием безопасности, хотя сам https может быть вполне математически криптостойким

GN>А вот случай когда программу можно считать надёжной:

GN>

GN>Шифр Вернама является системой шифрования, для которой доказана абсолютная криптографическая стойкость.

хотите взломаю? только не шифр, а ПРОГРАММУ, ЕГО ИСПОЛЬЗУЮЩУЮ? о чем мы вообще тут говорим? о сферических конях или реально работающих системах? как вы себе представляте использование шифра без его имплементации? и без куча стороннего кода, обслуживаюшего эту имплементацию? теоретик вы наш.

GN>>> Какое это имеет отношение к предотвращению кражи кредиток, которая выполняется атакой вида man in the browser? Сомневаюсь, что это является хотя бы необходимым условием.

М>>это затрудняет выполнение хакерского кода на машине жертвы. а хакерский код может делать все, что угодно, в том числе и похищать кредитки.
GN>Это затрудняет проникновение кода в систему по одному из векторов атаки, не более того. Ворующий кредитки код DEP&ASLR не остановит.
действительно, это один из векторов атаки. кто же спорит. а всего их бесконечное множество (включая еще и неоткрытые).

М>>звиняйте дядьку. что такое вирус не знает никто

GN>кроме Википедии?
GN>

Компьютерный вирус — разновидность компьютерных программ, отличительной особенностью которой является способность к размножению (саморепликация)

согласно данному определению, операционная система -- это вирус. предлагаете автоматом удалять с компьютера?

М>>если база не содержит сигнатур вирусов, которые нас атакуют... интересно, как сферический вирус с ними справиться?

GN>Побочный эффект описан, какие сигнатуры, не каменный же век. Ах, да, ваш NTR тогда курит в сторонке
покурите эвристики. там те же самые сигнатуры. только в виде наборов правил и шаблонов. или покажите эвристик который работает иначе. графы — не в счет. по сути дела это препроцессор.

GN>

любая конечная последовательность символов является вирусом для какой-либо машины

вот потому удаляем с диска все на хрен. и спим спокойно
americans fought a war for a freedom. another one to end slavery. so, what do some of them choose to do with their freedom? become slaves.
Re[6]: Необходимые и достаточные условия
От: gear nuke  
Дата: 16.05.10 21:43
Оценка:
Здравствуйте, мыщъх,

"строго и математически" нет смысла ждать?
People who are more than casually interested in computers should have at least some idea of what the underlying hardware is like. Otherwise the programs they write will be pretty weird (c) D.Knuth
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.