Комментарии 111
Если творение не будет оплачено и сработает бомба — ну так оно еще и не принадлежит заказчику, какие могут быть вопросы в исполнителю.
А вот если заказчик оплатит, а бомба сработает — ну тогда будет сценарий, как в статье.
Если творение не будет оплачено и сработает бомба — ну так оно еще и не принадлежит заказчику, какие могут быть вопросы в исполнителю.
С юридической точки зрения — нет, в общем случае сценарий как в статье (точнее, не как в статье, а помягче, т.к. тут-то имеются признаки мошенничества) будет даже если ещё не оплачено. Вот если исполнитель позаботился о себе, и указал в договоре с заказчиком пункт, что «права на использование программного обеспечения переходят к заказчику только после полной оплаты», тогда к нему претензий нет. Если же подобного пункта в договоре нет, то передача программы в пользование и оплата за неё — два независимых обязательства, и нарушение обязательств со стороны заказчика никак не избавляет программиста от ответственности за нарушение обязательств со своей стороны.
И в любом случае, встраивать таймбомбы — это полный идиотизм со стороны разработчика, и создание самому себе потенциальной проблемы на пустом месте. Хотите обезопасить себя от неуплаты со стороны заказчика, впишите в договор пункт о передаче прав после оплаты, и сделайте вместо таймбомбы обычный триал, допустим, на месяц, с сообщением после этого: «Вы пользуетесь нелицензионной версией программного обеспечения. Для продолжения использования, пожалуйста, приобретите ключ».
Да, она может быть даже несправедливой.
И даже вне рамок правового поля.
Поэтому выстраивать сотрудничество надо таким образом, чтобы мыслей о подобного рода защите не возникало.
toastytech.com/guis/word1153.html
А то вики говроит, что первая версия ворда вышла только в конце 83.
Microsoft, кстати, вставлял логические бомбы в самые ранние версии Word для DOS (периода 1982-83 годов). Там есть фрагмент кода с вызовом сообщения в духе «Копия Word пиратская, стираю ваш жесткий диск в наказание».
Персоналок с жёстким диском в 1982-83 ещё тупо не существовало.
Что не меняет того факта, что первый комментарий писался еще по памяти и там на самом деле скорее всего в виду имелась дискета. (Правда, ранние нестандартные способы подключения HDD тоже могли использовать этот интерфейс. В частности, еще потому, что в PC не было и поддержки HDD в BIOS. Однако это можно было обойти кастомным перешиванием BIOSa. Некоторые сведения были в старой книжке Питера Нортона «Работа с жестким диском IBM PC» )
В частности, еще потому, что в PC не было и поддержки HDD в BIOS.
Так поддержка HDD в BIOS материнки там и не требовалась, соответствующая прошивка была в контроллере.
В PC и XT очень даже требовалась. Во-первых, диск бы тупо не увиделся с BIOSи не было бы никакой возможности загрузки с него.
Не требовалась. BIOS в PC и XT имел одну универсальную функцию загрузки — сканировал память выше ОЗУ на предмет специальной сигнатуры, и передавал туда управление, если находил.
Соответственно, если в системе был какой-либо контроллер, он отображал на память свою прошивку с этой сигнатурой и загрузчиком. И функции int 13h, int 19h для управления жестким диском и загрузки с него соответственно были непосредственно реализованы уже в самом контроллере, а не в BIOS материнки
BIOS в PC и XT имел одну универсальную функцию загрузки
Вроде как не оригинальный BIOS PC, а только версии после августа 1982 года. Вроде бы IBM потом рассылала новый чип владельцам старых систем.
Как я понимаю, это все-таки ограничение самого Bios XT, если правильно понимаю
Это ограничение в параметрах int 13h. Собственно, даже не ограничение, а всего лишь предел возможностей прямой адресации CHS. Макс. количество головок * макс. кол-во цилиндров * макс. кол-во секторов = 528 Мб. Это касается любого накопителя с прямой адресацией.
Потом уже, когда места в микросхемах ПЗУ стало больше, как и потребностей в дисковом пространстве, добавили виртуальную адресацию, когда указывался просто виртуальный номер сектора, а в реальные адреса на накопителе уже транслировала прошивка. Это тот самый LBA.
И вот вышеизложенное Вами — это скорее всего в основном для типов ST506/MFM
Это справедливо для всех РС/РС ХТ, независимо от того, какой контроллер туда ставили, оригинальный MFM или всякого рода альтернативные, в том числе и IDE. Но естественно, никто не запрещал производителям клонов делать всё, что угодно. Очевидно, что среди них могли быть и девайсы с драйвером HDD в BIOS. Собственно, далеко не надо ходить, например, советский/украинский Поиск-2, или там ЕС 1842 имели код для поддержки винта уже в BIOS. Но это, минуточку, конец 1980-х, когда в западном мире уже 386-е вовсю выпускались, и вот-вот 486 пойдут.
Вроде как не оригинальный BIOS PC, а только версии после августа 1982 года. Вроде бы IBM потом рассылала новый чип владельцам старых систем.
Насчет этого не в курсе, если честно. Вполне может быть.
Это справедливо для всех РС/РС ХТ, независимо от того, какой контроллер туда ставили, оригинальный MFM или всякого рода альтернативные, в том числе и IDE
Да, все правильно. На карте контроллера есть свой ROM. Например «WD1002A-WX1, feature F300R — Half-slot size hard disk controller card with an ST506/ST412 interface. It supports 2 MFM drives with up to 16 heads and 1024 cylinders and is jumper configurable for secondary addressing and default drive tables. Built in ROM BIOS supports non-standard drive types, virtual drive formatting, dual drive operation, bad track formatting and dynamic formatting». Примерно так же должен вести себя и контроллер ESDI, хотя они исполнялись и в вариантах с ROM и без него, во втором случае поддержка диска должна быть через BIOS stason.org/TULARC/pc/hard-disk-floppy-controllers/U-Z/WESTERN-DIGITAL-CORPORATION-Two-ESDI-drives-WD1007-110.html
Вообще, был совет с MFM/RLL контроллерами при наличии Bios Setup (286+) ставить тип диска в 0 или 1, я сейчас прочитал и тоже вспомнил его. Диск определял сам контроллер. Но с 16-битными мультикартами c IDE-интерфейсом такой трюк уже точно не проканывал до появления автодетекта в BIOS на поздних 486. Эти карты были слишком примитивны по сути, а контроллер убрали в сам диск. Но на раритетных 8-битных IDE контроллерах, видимо, ROM таки имелся. Но кстати утилита, заменявшая автодетект, для 286-386 с IDE вроде точно была. Только сейчас эту древность вспомнил.
s005.radikal.ru/i211/1404/be/e0c2256ddff3.jpg
www.minuszerodegrees.net/5150/early/5150_bios_upgrade_kit.jpg
Я думаю, срабатывание таймбомбы и ущерб от нее будут квалифицироваться как отдельное дело, а факт нарушения условий договора заказчиком как ещё одно. Так что я думаю, таймбосбы в софте это в любом случае плохая идея. Должен быть грамотный договор и/или триал.
Я думаю, срабатывание таймбомбы и ущерб от нее будут квалифицироваться как отдельное дело, а факт нарушения условий договора заказчиком как ещё одно
Именно так. Причем факт нарушения условий договора заказчиком вообще никак не будет квалифицироваться, пока разработчик не соберёт доказательства и не подаст иск в суд. При этом между обоими фактами разница огромная, т.к. нарушение условий договора — это обычный хозяйственный спор, а закладки/таймбомбы в ПО проходят по уголовке.
Суть таймбомбы во введении в заблуждение заказчика?
В сознательном создании скрытых функций, выводящих из строя программное обеспечение. Это статья в УК. Показывать MessageBox с требованиями законно. А вот подгаживать втихаря — незаконно. Отдельный вопрос, можно ли доказать, что AV сделано намеренно, а не нечаянно. Но то такое. Первым должен идти вопрос «зачем мне это надо, если можно добиться того же результата легальным методом».
Но есть разница — когда пользуются ворованным нелицензионным софтом на свой страх и риск, и то, что сделал программист — нагадил в рабочем коде, за который ему уже полностью заплатили.
Если про статью, то он совершил две ошибки — явно сравнивал с датой и признался. Хотя и с самим признанием из статьи не все ясно, т.к. непонятно чем его додавили чтобы он признался.
Если про меня, то даже вышенаписанное не может ничего доказать, т.к. четко доказать что именно в этом проекте это именно заложенная тайм-бомба а не баг — крайне сложно, практически невозможно. «Мало-ли чего в интернете писал. И вообще вспоминал что вытворял когда был молодой и глупый ))» Точнее можно, но при одном условии — я дам доступ к собственному гиту и там по истории может быть получится найти эксперименты с таким багом. Чего, конечно-же, я в трезвом уме и здравой памяти не сделаю никогда.
Я ещё не понял, если он заранее знал дату срабатывания, зачем он в отпуск то уехал на эту дату?
Если "ОАО НПП „ХХХ“ не оплатило разработку это приложения", то в 5 часов утра на охраняемый объект проникают диверсанты.
как квалифицируется случай, когда исполнитель закладывает тайм-бомбу в качестве страховки на случай неоплаты заказчиком его творения и этот случай таки наступает?Как откровенное мудачество, без вариантов.
Потому что любой код может повести себя непредсказуемо в любой момент времени, а в данном случае это деструктивный код о котором не знает его непосредственный пользователь.
Пароль в экселе ничего не защищает
Ну почему, исходя из написанного в статье, пароль в экселе как минимум защищает от аудита сотрудниками самсунга :)
пароль в экселе как минимум защищает от аудита сотрудниками самсунга :)Защищает больше чем может показаться. Это скорее юридическая защита, т.к. обход пароля во-первых будет означать уголовную статью, во-вторых полученные нелегальным способом данные нельзя будет использовать как доказательства.
«Обход пароля» как таковой не требуется — сам код программы хранится в файле VbaProject.bin, который не защищен никаким шифрованием, а значит открытие и чтение его не нарушает никаких законов.И все же в данном случае нарушило бы.
Проникновение в чужую собственность (код) все равно проникновение, даже если заход был через непостроенную стену (незащищенный файл), при наличии закрытой двери (пароля). Основной нюанс в том, что дверь была закрыта и сименс об этом знал, поэтому проход через непостроенную стену это уже «обход пароля», а не просто «чтение файла».
"Логическая бомба" — как-то слишком громко звучит для тупого триггера по дате. Вот нарушение логического закона тождества A = A в C-подобных языках программирования — это да, бомба так бомба.
На самом деле это важный прецендент. При заказной разработке зачастую код получается "немного не по guideline'ам". Как следствие — программа перестает работать на новой версии операционной системы/браузера (так как разработчик использовал хаки и нюансы текущей, без оглядки на будущее).
Как следствие — компания-заказчик обращается к тому же поставщику (так как в подобном коде уже никто другой особо разобраться и не сможет задешево), а потом еще раз и так далее. Получается такой мягкий vendor lock-in.
Так вот: в таком сценарии намеренное игнорирование рекомендаций Google по разработке сайтов в некотором смысле являются теми же таймбомбами.
Как вы плавно перевели от Excel к разработке сайтов по рекомендации Google.
Надеюсь, за игнорированиям этих рекомендаций в суд пока не тянут? А то стало страшно.
Получается такой мягкий vendor lock-in.
Хуже всего многие, наемные программисты в штате могут считаться такими супер-гуру, которые единственные знают как работет написанная ими (или его командой) система, и могут ее исправлять. Ну, и поскольку они незаменивые получают значительно больше остальных и гарантию от уволнения.
А по факту причина в ужасном дизайне и коде (ненамеренном или даже сознательном). В результате, получается такая отрицательная обратная связь, чем лучше и понятнее ты пишешь — тем более вероятно, что тебя уволят, и наоборот, чем хуже пишешь — тем надежнее и выше зарплата.
Всё же сложность системы зависит не только от качества кода но и от заложенной логики, а как раз внутренней разработкой часто и занимаются там, где не выходит купить и использовать "коробочное" решение.
Да, в «коробочном» решении тоже самое, если документации и api идеальны никто не купит техподержку и допиливание фич или закажет их у любого другого стороненного разработчика. Поэтому часто разрабочик заинтересован не делать продукт слишком хорошо.
Здесь важно доказать намерение. Иначе даже простую ошибку можно зачесть за саботаж.
Для не понявших юмора: использовать функции, о которых точно известно, что через некоторое время они перестанут работать сами, безо всяких логических бомб.
В ту же копилку тотальное кэширование и логирование без средств очистки. Туда же «не замеченные» баги в ТЗ, особенно в случае формального отсутствия такового. И ещё тысячи способов, от всех никаким договором не защитишься.
Но нафига?
По уму если, то вовсе не надо никаких таких гадостей делать, а нужно выбирать проекты, которым неиминуемо потребуется доработка в связи с развитием. Да, для такого предвидения необходим опыт, но странно, что 52-летний чувак им не обладал либо поленился и предпочёл вместо этого пойти к успеху кривой дорожкой.
использовать функции, о которых точно известно, что через некоторое время они перестанут работать сами, безо всяких логических бомб.
Вообще, если вдаваться в детали, то сами они работать не перестанут. Только в результате конкретных действий — обновления.
А в худшем — поставят плохой отзыв или подадут в суд, и с фрилансом вы можете распрощаться навсегда.
А раз в пол года для десяти заказчиков менять дату в коде — это ничего не стоит, а деньги приносит.
Так что то что вы предлагаете и то что делал герой статьи — это не одно и тоже.
Ну и в целом, про делайте работу хорошо, немного личного опыта:
Пришел заказчик, просит сделать некую софтину для большого клиента. Я не помню деталей, но не суть.
Я думаю: сделаю хорошо и удобно. Пусть заказчик порадуется.
В итоге сделал удобный конфиг с настройками, чтобы и urlы все можно было удобно настраивать, и дизайн менять удобно и верстку.
И что вы думаете? Через пару месяцев мою прогу переверстали без моего участия и продали еще одному заказчику. А потом еще и еще.
В следующий раз я всё захардкодил, все редакторы которые сделал для верстки и настройка оставил себе. И что вы думаете? Через месяц ко мне пришли за редизайном.
И вот с тех пор я каждый раз думаю, а выгодно ли мне делать заказчику хорошо? И каждый раз отвечаю: нет, мне выгодно делать по ТЗ. А хорошо — только за отдельные деньги.
Мне кажется сомнительным как прокурор притянул за уши размер ущерба. Так ведь можно невзначай лист бумаги со стола оборонить, а компания наймёт дорогих аудиторов для анализа ущерба за десятки тысяч долларов. И получится уголовное дело на десяток лет тюрьмы и пару сотен тысяч долларов штрафа.
и прицепиться не к чему, договора не было и работы соответственно тоже, а уж что там заказчик запустил, его проблема.
Либо я чего то не понимаю, либо сейчас подставить человека слишком легко.
сейчас подставить человека слишком легко.
Да это всегда было легко. Дали работнику и партнеру доступ к проду, а потом заявили, что именно он его сломал специально. Как доказать обратно? Или даже не на прод, мало ли вирус в сеть запустил, троян поставил, багов в код накидал, информацию конкурентам сливал и т.п.
Он сам признал себя виновным. Судя по информации ранее ему предлагали уладить спор, но он все отрицал. Затем пробовал сослаться на то, что ошибки были вызваны не обнаруженными закладками, а несовместимостью с новыми апдейтами Excel. В результате дело дошло до полномасштабных слушаний. Решения пока нет, приговор будет вынесен в ноябре.
Программист разработал для компании сложные таблицы Excel с формулами
пароль на свой код исключительно для защиты интеллектуальной собственности
По логике, время, которое он потратил на разработку, оплачено компанией. Значит разработанная интеллектуальная собственность тоже переходит компаниии.
Какая тут может быть защита того, что ему уже не принадлежит? Пароль, по идее, тоже должен быть передан компании вместе с таблицей. Странно, что они его не потребовали сразу.
У меня есть заказчик, для которого я делаю софт достаточно уникальный и на который при этом чуть ли не весь бизнесу у заказчика завязан. Если я пропаду — он сможет это пережить, но стресс в его бизнесе будет приличный скорее всего.
Так вот, вопрос передачи исходников не поднимался никогда.
Я по косвенным признакам пришел к выводу, что заказчик уже с таким сталкивался и ему зарядили огромную цену за передачу исходников. Поэтому он считает, что нет смысла меня просить об этом.
Хотя по факту, я бы сразу передал. Впрочем думаю через некоторое время, когда проект стабилизируется полностью — я по своей инициативе сорсы передам, а то тупость какая-то — Помру например, а у людей честно оплативших работу бизнес просядет.
С другой стороны это вводимая сейчас всеми "сервисная модель" т.е. вам платят не за АО а за услугу его предоставления на срок :)
В это части очень интересна ситуация с крупными корпорациями рискующими попасть под санкции, как-то присутствовал на демонстрации одного иностранного продукта(в общем его предполагалось использовать как замену живым людям, которых соответственно предполагалось "оптимизировать") который поставляется только по timeshare лицензии на год, и во время презентации меня всё гложил вопрос, а как же непрерывность деятельности и санкции…
Так вот в итоге когда этот вопрос был задан, уровень оптимизма у презентовавших продукт как-то поубавился, но уверили что работают по данному направлению.
Не нужно путать трудовые отношения с гражданско-правовыми.
Вот интересно, куда смотрел менеджмент организовавший работу так, что столь важные процессы держались на одном контракторе. А если бы автобус? А может ситуация была выгодна не только 62 летнему программисту? У них похоже есть повод для проведения ещё и внутренних расследований.
Я думаю они достаточно хороши.
5000 это минимальная сумма, после которой подобные инцеденты начинают рассматриваться как преступление. 42000 это ущерб, который предъявила компания, исходя из своих затрат связанных с инцедентом. Выплаты контрактору за разработку и поддержку софта в деле не фигурируют.
На поддержку обычно выделяются отдельные бюджеты. Затраты как правило меньше. Возможно при таком иске было бы сложнее доказать наличие ущерба. А может у них были какие-то свои схемы, которые не хотят придавать огласке.
Все понимали, что если что исправить можно, это вам не неизвестный exe файл из-под непонятного компилятора. Просто дешевле было так, а в какой-то момент когда уже были подозрения человека наверняка спросили, а он в отказ пошёл (ну или просто заказчик считает что мошенники должны сидеть а тюрьме).
Он утверждал, что не заработал дополнительных денег на выполнении этих заказов, а ставил пароль на свой код исключительно для защиты интеллектуальной собственности. Но представитель прокуратуры заявил, что формулировка о мотиве Тинли «не была частью изложения фактов в поддержку признания вины, но была поднята его адвокатом в качестве возможного смягчающего фактора для будущего приговора». В результате этого своеобразного юридического казуса программиста вынудили признать вину и согласиться со всеми формулировками прокуратуры, в том числе о корыстном мотиве при установке пароля.
Кто нибудь может объяснить этот абзац? В чем заключается казус и как он может вынудить признать вину если он уже изложил факты «в поддержку признания вины»? Или весь смысл фразы что обвиняемый просто пошел на сделку с правосудием?
В шахты их и пусть работает за еду, если срок десять лет или более к примеру. Отличный контроль, самоокупаемость, хороший страх для остальных.
Перегибать палку могут все и нужна система сдерживания и контроля.
Заключенный это мой согражданин и я обязан его кормить. Это форма наказания, а не рабства.
Я где-то уже слышал, что Россия это нищие США, вот только не знаю расценивать это как комплимент или как оскорбление?
ru.wikipedia.org/wiki/%D0%94%D0%B5%D0%BB%D0%BE_%D0%BE_%D0%BF%D1%80%D0%BE%D0%B4%D0%B0%D0%B6%D0%B5_%D0%B4%D0%B5%D1%82%D0%B5%D0%B9_%D0%B2_%D0%BE%D0%BA%D1%80%D1%83%D0%B3%D0%B5_%D0%9B%D1%8E%D0%B7%D0%B5%D1%80%D0%BD
«Дело о продаже детей» (англ. Kids for cash) — уголовное дело по факту должностного преступления, совершённого судьями округа Люзерн, которые незаконно передавали осуждённых несовершеннолетних лиц в частные ювенальные тюрьмы штата Пенсильвания; оно было раскрыто в 2009 году
Сдаётся мне, что нет.
Программист внедрил логическую бомбу в таблицы Excel, чтобы гарантировать себе заказы на техподдержку