Программист разработал для компании сложные таблицы Excel с формулами, которые ссылались на другие таблицы, с формами, кнопками и т. д. По идее, после выполнения заказа таблицы должны были нормально функционировать, а его работа была завершена после окончательного расчёта. Но через некоторое время формы по непонятной причине начинали глючить — и компания обращалась к Тинли за помощью и платной консультацией.
Такие действия Тинли напоминают «запланированное устаревание», которое умышленно планируют производители электроники и компьютеров, чтобы пользователи через несколько лет покупали новый гаджет вместо устаревшего или сломанного. Но если компаниям удаётся выйти сухими из воды, Тинли не сможет избежать наказания: ему грозит до десяти лет лишения свободы.
52-летний Дэвид Тинли признал себя виновным в том, что оставил «логические бомбы» в пользовательских электронных таблицах, которые Siemens использовала для управления заказами на электрогенерирующее оборудование и для медицинской диагностики. После определённой даты этот код создаёт сбои в программе, которые Тинли затем «исправлял» простым переносом даты появления сбоев на более поздний срок, сказали прокуроры.
Ниже выдержка из обвинительного заключения, опубликованного на Scribd.
Тинли был независимым подрядчиком подразделения Siemens в Монровилле, штат Пенсильвания, около 15-ти лет, с начала 2000-х годов. Он написал «автоматизированные электронные таблицы, которые рассчитывали рабочий процесс и смету затрат для заказов клиентов в подразделении производства электроэнергии Siemens».
Прокуратура утверждала, что Тинли вставил «логические бомбы» в защищённый паролем код, чтобы после определённой даты электронные таблицы «начали беспорядочно глючить, создавая сообщения об ошибках и изменяя размер экранных кнопок». Затем Siemens звонили своему проверенному подрядчику, чтобы исправить проблему. Он это делал, открыв свой код и просто передвинув дату, когда электронные таблицы снова перестанут работать.
Тинли отказывался дать кому-либо пароль для изучения или редактирования кода, но его уговорили сделать это в 2016 году, когда он был в отпуске, а Siemens пришлось провести важный и срочный заказ через его систему, которая внезапно начала глючить. Тогда-то он и выдал пароль, а сотрудники Siemens обнаружили саботаж.
Детали судебного разбирательства тоже довольно любопытны. Во-первых, логические бомбы не причинили компании особого ущерба, потому что программист быстро всё исправлял. Более того, на него даже не завели бы уголовного дела, потому что сумма ущерба не превысила положенного по законодательству порога в $5000. Однако прокуроры сказали, что порог ущерба в размере $5000 для классификации преступления как уголовного преступления был соблюден, потому что Siemens потратила около $42 тыс. на оплату сотрудников и адвокатов, которые расследовали, не повредили ли глюки компании и её бизнесу каким-либо образом (оказалось, что не повредили, но это не важно для оценки стоимости работ по аудиту). Ответчик обязан компенсировать эти расходы (вдобавок к потенциальному сроку тюремного заключения). Кроме того, суд постановил конфисковать два его ноутбука (вероятно, как «орудия преступления»).
Во-вторых, сам программист долгое время отрицал свою вину. Он утверждал, что не заработал дополнительных денег на выполнении этих заказов, а ставил пароль на свой код исключительно для защиты интеллектуальной собственности. Но представитель прокуратуры заявил, что формулировка о мотиве Тинли «не была частью изложения фактов в поддержку признания вины, но была поднята его адвокатом в качестве возможного смягчающего фактора для будущего приговора». В результате этого своеобразного юридического казуса программиста вынудили признать вину и согласиться со всеми формулировками прокуратуры, в том числе о корыстном мотиве при установке пароля.
Судья вынесет окончательный приговор Тинли 8 ноября. Ему грозит до 10 лет тюрьмы, штраф в размере 250 000 долларов или и то, и другое. Дело «США против Тинли», № 2:19-cr-00156 рассматривается в Окружном суде США по Западному округу Пенсильвании.
Хотя на первый взгляд преступление программиста кажется совсем небольшой махинацией, но в США такие дела рассматриваются очень строго. Эксперты считают, что у него не так много шансов избежать тюремного заключения, хотя шансы есть из-за незначительности ущерба.
В похожем процессе 2006 года системный администратор компании UBS PaineWebber Роджер Дуронио (Roger Duronio) получил восемь лет тюрьмы за размещение логической бомбы в корпоративную сеть работодателя и сделав ставку на бирже на падение его акций. Этот сотрудник неоднократно жаловался на плохие условия работы в компании, затем он уволился, но 4 марта 2002 года примерно на 1000 из 1500 корпоративных компьютеров сработала логическая бомба, которая начала удалять файлы с машин. Сам он тем временем купил пут-опционы на падение акций UBS после 4 марта на общую сумму $23 тыс. Вероятно, таким способом системный администратор хотел «компенсировать ущерб», который нанесла ему компания своими плохими условиями работы и недоплачивая ему положенные деньги. Сама фирма заявила об ущербе $3,1 млн, которые ответчик должен компенсировать.
В сентябре 2018 года житель Атланты Миттеш Дас (Mittesh Das) был приговорён к двум годам тюрьмы за размещение логической бомбы в бухгалтерское приложение Regional Level Application Software (RLAS) для выплаты жалования солдатам Армии США, что привело к задержкам выплаты зарплаты в 17 дней. Программист перед этим сам два года обслуживал эту базу данных по договору подряда. Логическая бомба сработала, когда заказчик заключил договор на обслуживание с другим подрядчиком. Армия заявила, что потратила $2,6 млн на расследование инцидента и аудит системы RLAS. В итоге разработчик был приговорён к двум годам тюрьмы и выплате $15 млн штрафов и компенсации издержек.
Несмотря на все эти прецеденты, некоторые фрилансеры и сейчас применяют подобные методы, чтобы более надёжно «привязать» к себе выгодного клиента. Более того, отдельные разработчики считают нормальным, что можно дистанционно отключить какой-то модуль или активировать тайм-бомбу, если заказчик не оплатил работу. Программисты зачастую не подозревают, что за это грозит административная и уголовная ответственность.
С другой стороны, в комментариях высказывают мнение, что тайм-бомбу можно спрятать среди логических функций таким образом, что её никогда не обнаружат, а если обнаружат, то не смогут отличать от случайной ошибки, а ведь за ошибки никто не имеет права наказывать. Другими словами, здесь важен факт, смогут ли они доказать наличие умысла при установке бомбы. В общем, к этому делу нужно подходить с умом и иметь далёкий горизонт планирования, а не как у американского программиста, который забыл о дате и ушёл в отпуск перед тем, когда сработала его логическая бомба в электронных таблицах.
Комментарии (110)
Oval
27.07.2019 16:12Пароль в экселе ничего не защищает
Dink
27.07.2019 17:08+3Ну почему, исходя из написанного в статье, пароль в экселе как минимум защищает от аудита сотрудниками самсунга :)
tvr
27.07.2019 17:55+1пароль в экселе как минимум защищает от аудита сотрудниками самсунга :)
Сименсовской самописной системы учёта.
Я всегда не доверял этим ушлым корейцам, оказалось — не зря!
edogs
28.07.2019 14:33+1пароль в экселе как минимум защищает от аудита сотрудниками самсунга :)
Защищает больше чем может показаться. Это скорее юридическая защита, т.к. обход пароля во-первых будет означать уголовную статью, во-вторых полученные нелегальным способом данные нельзя будет использовать как доказательства.
Gibboustooth
28.07.2019 22:51Я не уверен, что тут можно говорить о какой-либо юридической защите. Софт этого инженера скорее всего не был защищен ничем, кроме авторского права. «Обход пароля» как таковой не требуется — сам код программы хранится в файле VbaProject.bin, который не защищен никаким шифрованием, а значит открытие и чтение его не нарушает никаких законов. Почему в Сименс этого не делали — я не знаю. Скорее всего, не видели необходимости разбираться в чужом коде.
edogs
29.07.2019 01:43«Обход пароля» как таковой не требуется — сам код программы хранится в файле VbaProject.bin, который не защищен никаким шифрованием, а значит открытие и чтение его не нарушает никаких законов.
И все же в данном случае нарушило бы.
Проникновение в чужую собственность (код) все равно проникновение, даже если заход был через непостроенную стену (незащищенный файл), при наличии закрытой двери (пароля). Основной нюанс в том, что дверь была закрыта и сименс об этом знал, поэтому проход через непостроенную стену это уже «обход пароля», а не просто «чтение файла».Iv38
29.07.2019 04:07Сложный вопрос. В данном случае софт сделан по заказу, и в зависимости от договора заказчику могут принадлежать все имущественные права на него. Но даже если это не так, то законы могут позволять декомпилировать и изменять софт для обеспечения его функционирования, как это позволяет конечному пользователю ГК РФ, например.
xfaetas
27.07.2019 17:16"Логическая бомба" — как-то слишком громко звучит для тупого триггера по дате. Вот нарушение логического закона тождества A = A в C-подобных языках программирования — это да, бомба так бомба.
imanushin
27.07.2019 17:58На самом деле это важный прецендент. При заказной разработке зачастую код получается "немного не по guideline'ам". Как следствие — программа перестает работать на новой версии операционной системы/браузера (так как разработчик использовал хаки и нюансы текущей, без оглядки на будущее).
Как следствие — компания-заказчик обращается к тому же поставщику (так как в подобном коде уже никто другой особо разобраться и не сможет задешево), а потом еще раз и так далее. Получается такой мягкий vendor lock-in.
Так вот: в таком сценарии намеренное игнорирование рекомендаций Google по разработке сайтов в некотором смысле являются теми же таймбомбами.
ialexander
27.07.2019 18:20Как вы плавно перевели от Excel к разработке сайтов по рекомендации Google.
Надеюсь, за игнорированиям этих рекомендаций в суд пока не тянут? А то стало страшно.
vedenin1980
27.07.2019 18:53Получается такой мягкий vendor lock-in.
Хуже всего многие, наемные программисты в штате могут считаться такими супер-гуру, которые единственные знают как работет написанная ими (или его командой) система, и могут ее исправлять. Ну, и поскольку они незаменивые получают значительно больше остальных и гарантию от уволнения.
А по факту причина в ужасном дизайне и коде (ненамеренном или даже сознательном). В результате, получается такая отрицательная обратная связь, чем лучше и понятнее ты пишешь — тем более вероятно, что тебя уволят, и наоборот, чем хуже пишешь — тем надежнее и выше зарплата.
nikolayv81
27.07.2019 23:05+1Всё же сложность системы зависит не только от качества кода но и от заложенной логики, а как раз внутренней разработкой часто и занимаются там, где не выходит купить и использовать "коробочное" решение.
vedenin1980
27.07.2019 23:21Любую самую простую логику можно обернуть таким кол-вом абстракций и условно нужных фич, что после этого потребуются многие недели, чтобы просто понять, что происходит.
Да, в «коробочном» решении тоже самое, если документации и api идеальны никто не купит техподержку и допиливание фич или закажет их у любого другого стороненного разработчика. Поэтому часто разрабочик заинтересован не делать продукт слишком хорошо.
Greendq
27.07.2019 23:46Любую самую простую логику можно обернуть таким кол-вом абстракций и условно нужных фич, что после этого потребуются многие недели, чтобы просто понять, что происходит.
Очень часто подобное наблюдается в индусском коде — абстракция на абстракции сидит и абстракцией погоняет.
adictive_max
27.07.2019 19:30+5А вот нифига. Специально делать закладки в СВОЁМ коде, специально направленные на то, чтобы он перестал работать — это одно дело. А предвидеть наперёд всё, что теоретически может поменяться — это совсем другое. У вас, например, есть список на следующие 15 лет, какие функции в WinAPI или Web-стандартах станут работать по-другому или перестанут работать вообще, в том числе не намеренно, а из-за сайд-эффектов от других изменений?
sumanai
27.07.2019 21:48+2рекомендаций Google по разработке сайтов
Кто такой этот Google, чтобы давать рекомендации?DrPass
27.07.2019 23:08+5А, это такая группа чуваков, которая за вас решает, найдут ли ваш сайт другие пользователи или не найдут.
kinjalik
28.07.2019 03:08А теперь ещё и решают, в большинстве случаев, увидите ли вы сайт в принципе (нет SSL даже на текстовом сайте без персональных данных? Бан!)
sumanai
28.07.2019 11:08Пока ещё никого не забанили, насколько я знаю. Перечёркнутые замки в браузере, понижение в поиске, это да. Но не бан.
aram_pakhchanian
27.07.2019 21:49Здесь важно доказать намерение. Иначе даже простую ошибку можно зачесть за саботаж.
maxbrown
27.07.2019 18:05Deprecated: mysql_connect(): The mysql extension is deprecated and will be removed in the future: use mysqli or PDO instead in
Для не понявших юмора: использовать функции, о которых точно известно, что через некоторое время они перестанут работать сами, безо всяких логических бомб.
В ту же копилку тотальное кэширование и логирование без средств очистки. Туда же «не замеченные» баги в ТЗ, особенно в случае формального отсутствия такового. И ещё тысячи способов, от всех никаким договором не защитишься.
Но нафига?
По уму если, то вовсе не надо никаких таких гадостей делать, а нужно выбирать проекты, которым неиминуемо потребуется доработка в связи с развитием. Да, для такого предвидения необходим опыт, но странно, что 52-летний чувак им не обладал либо поленился и предпочёл вместо этого пойти к успеху кривой дорожкой.
wxmaper
27.07.2019 21:46+2использовать функции, о которых точно известно, что через некоторое время они перестанут работать сами, безо всяких логических бомб.
Вообще, если вдаваться в детали, то сами они работать не перестанут. Только в результате конкретных действий — обновления.
ittakir
27.07.2019 18:11Если вы фрилансер, просто делайте работу хорошо, и к вам опять обратятся старые клиенты с новыми заказами. А если хитрить, оставлять закладки и т.п. — в лучшем случае вашу работу просто выкинут, и больше с вами не будут иметь дела.
А в худшем — поставят плохой отзыв или подадут в суд, и с фрилансом вы можете распрощаться навсегда.
AllexIn
27.07.2019 20:12+8Делать работу хорошо — требует усилий.
А раз в пол года для десяти заказчиков менять дату в коде — это ничего не стоит, а деньги приносит.
Так что то что вы предлагаете и то что делал герой статьи — это не одно и тоже.
Ну и в целом, про делайте работу хорошо, немного личного опыта:
Пришел заказчик, просит сделать некую софтину для большого клиента. Я не помню деталей, но не суть.
Я думаю: сделаю хорошо и удобно. Пусть заказчик порадуется.
В итоге сделал удобный конфиг с настройками, чтобы и urlы все можно было удобно настраивать, и дизайн менять удобно и верстку.
И что вы думаете? Через пару месяцев мою прогу переверстали без моего участия и продали еще одному заказчику. А потом еще и еще.
В следующий раз я всё захардкодил, все редакторы которые сделал для верстки и настройка оставил себе. И что вы думаете? Через месяц ко мне пришли за редизайном.
И вот с тех пор я каждый раз думаю, а выгодно ли мне делать заказчику хорошо? И каждый раз отвечаю: нет, мне выгодно делать по ТЗ. А хорошо — только за отдельные деньги.
androidovshchik
28.07.2019 09:18-5Бывают проекты типа прототипа на 1-2 дня. Мне заключать договоры по ним или надеяться на порядочность неизвестного заказчика? Без бомб не вижу смысла браться за такие работы. В остальном да. Крупные и средние проекты требуют большой ответственности, меня до сих пор мучают мысли, что несколько таких запорол и в свое время бросил, потому что либо угорел, либо были другие причины. Лучше десять раз подумать и в полной мере оценить, прежде чем хвататься без разбора за подобные. За 4 года у меня было несколько конфликтов, но они все решились (один раз даже до суда накал был), цепляться за старых заказчиков можно, но не всегда получается держать ценовую планку, как ни странно, потому что чем дольше работаю с определенным заказчиком, тем меньше в результате получаю по деньгам. Парадокс для меня
ialexander
27.07.2019 18:24+1Мне кажется сомнительным как прокурор притянул за уши размер ущерба. Так ведь можно невзначай лист бумаги со стола оборонить, а компания наймёт дорогих аудиторов для анализа ущерба за десятки тысяч долларов. И получится уголовное дело на десяток лет тюрьмы и пару сотен тысяч долларов штрафа.
DarkWolf13
27.07.2019 20:49+1тут скорее всего рассмотрение и публичность обозначена для того, чтобы другим не повадно было, а то один человек целую корпорацию почти развел.
1c80
27.07.2019 19:28-5Ну то есть желательно работать вообще без договора и спокойно оставлять закладки, тогда
и прицепиться не к чему, договора не было и работы соответственно тоже, а уж что там заказчик запустил, его проблема.
Sergey6661313
27.07.2019 19:28+2одно не понятно — если он дал пароль это ведь обозначает что компания может сама вбросить туда тайм бомбу. Как именно суд постановил что виноват именно Дэвид? Как доказали что именно он написал этот код? Если вводили пароль и смотрели код в присутствии нотариуса и понятых и на камеру — даже в этом случае в компьютере заранее могла быть написана программа которая вставляла бы вредоносный код в xls фаилы сразу как получают к ним доступ. Таких программ на самом деле сотни. Всякие win locker-ы которые потом после того как ломают файлы вымогают перевести деньги на биткоин кошельки.
Либо я чего то не понимаю, либо сейчас подставить человека слишком легко.vedenin1980
27.07.2019 19:32+1Вероятно, как обычно — пришли свидетели с обоих сторон, дали показания, а суд решал кому он больше верит.
сейчас подставить человека слишком легко.
Да это всегда было легко. Дали работнику и партнеру доступ к проду, а потом заявили, что именно он его сломал специально. Как доказать обратно? Или даже не на прод, мало ли вирус в сеть запустил, троян поставил, багов в код накидал, информацию конкурентам сливал и т.п.
funca
27.07.2019 20:14Он сам признал себя виновным. Судя по информации ранее ему предлагали уладить спор, но он все отрицал. Затем пробовал сослаться на то, что ошибки были вызваны не обнаруженными закладками, а несовместимостью с новыми апдейтами Excel. В результате дело дошло до полномасштабных слушаний. Решения пока нет, приговор будет вынесен в ноябре.
amaksr
27.07.2019 20:11+3Программист разработал для компании сложные таблицы Excel с формулами
пароль на свой код исключительно для защиты интеллектуальной собственности
По логике, время, которое он потратил на разработку, оплачено компанией. Значит разработанная интеллектуальная собственность тоже переходит компаниии.
Какая тут может быть защита того, что ему уже не принадлежит? Пароль, по идее, тоже должен быть передан компании вместе с таблицей. Странно, что они его не потребовали сразу.AllexIn
27.07.2019 20:19+2Нет.
У меня есть заказчик, для которого я делаю софт достаточно уникальный и на который при этом чуть ли не весь бизнесу у заказчика завязан. Если я пропаду — он сможет это пережить, но стресс в его бизнесе будет приличный скорее всего.
Так вот, вопрос передачи исходников не поднимался никогда.
Я по косвенным признакам пришел к выводу, что заказчик уже с таким сталкивался и ему зарядили огромную цену за передачу исходников. Поэтому он считает, что нет смысла меня просить об этом.
Хотя по факту, я бы сразу передал. Впрочем думаю через некоторое время, когда проект стабилизируется полностью — я по своей инициативе сорсы передам, а то тупость какая-то — Помру например, а у людей честно оплативших работу бизнес просядет.nikolayv81
27.07.2019 23:18С другой стороны это вводимая сейчас всеми "сервисная модель" т.е. вам платят не за АО а за услугу его предоставления на срок :)
В это части очень интересна ситуация с крупными корпорациями рискующими попасть под санкции, как-то присутствовал на демонстрации одного иностранного продукта(в общем его предполагалось использовать как замену живым людям, которых соответственно предполагалось "оптимизировать") который поставляется только по timeshare лицензии на год, и во время презентации меня всё гложил вопрос, а как же непрерывность деятельности и санкции…
Так вот в итоге когда этот вопрос был задан, уровень оптимизма у презентовавших продукт как-то поубавился, но уверили что работают по данному направлению.
funca
27.07.2019 20:19+1Вот интересно, куда смотрел менеджмент организовавший работу так, что столь важные процессы держались на одном контракторе. А если бы автобус? А может ситуация была выгодна не только 62 летнему программисту? У них похоже есть повод для проведения ещё и внутренних расследований.
VBKesha
27.07.2019 21:49+6Итак независимый подрядчик который написал какуюто софтина, и на её поддержку за 15 лет потратили меньше $5000(около 28$ в месяц). И с которого потом ещё и поимели 42000$
Я думаю они достаточно хороши.DrPass
27.07.2019 23:15Судя по статье, $5000 — это рассчитанная сумма ущерба, а не сумма оплаты труда программисту. Ну т.е. сюда входит лишь стоимость ликвидаций очередных срабатываний таймбомбы и возможно какой-то доказанный ущерб от простоя. Очевидно, платили-то ему больше.
funca
27.07.2019 23:495000 это минимальная сумма, после которой подобные инцеденты начинают рассматриваться как преступление. 42000 это ущерб, который предъявила компания, исходя из своих затрат связанных с инцедентом. Выплаты контрактору за разработку и поддержку софта в деле не фигурируют.
На поддержку обычно выделяются отдельные бюджеты. Затраты как правило меньше. Возможно при таком иске было бы сложнее доказать наличие ущерба. А может у них были какие-то свои схемы, которые не хотят придавать огласке.
nikolayv81
27.07.2019 23:32+1Все понимали, что если что исправить можно, это вам не неизвестный exe файл из-под непонятного компилятора. Просто дешевле было так, а в какой-то момент когда уже были подозрения человека наверняка спросили, а он в отказ пошёл (ну или просто заказчик считает что мошенники должны сидеть а тюрьме).
Tsimur_S
28.07.2019 01:21Он утверждал, что не заработал дополнительных денег на выполнении этих заказов, а ставил пароль на свой код исключительно для защиты интеллектуальной собственности. Но представитель прокуратуры заявил, что формулировка о мотиве Тинли «не была частью изложения фактов в поддержку признания вины, но была поднята его адвокатом в качестве возможного смягчающего фактора для будущего приговора». В результате этого своеобразного юридического казуса программиста вынудили признать вину и согласиться со всеми формулировками прокуратуры, в том числе о корыстном мотиве при установке пароля.
Кто нибудь может объяснить этот абзац? В чем заключается казус и как он может вынудить признать вину если он уже изложил факты «в поддержку признания вины»? Или весь смысл фразы что обвиняемый просто пошел на сделку с правосудием?SergeyMax
28.07.2019 07:43Первоначально он не признал вину («да, я поставил пароль для того, чтобы никто не узнал, как я всех нахлобучиваю»), а попытался изложить версию таким образом, чтобы смягчить своё положение («поставил пароль для защиты интеллектуальной собственности»). Для того, чтобы рассчитывать на сделку, нужно было признать вину полностью. Я понимаю этот абзац как-то так.
mig126
28.07.2019 10:08-1Какой смысл наказания от тюрьмы? Кормить, поить, одевать десять лет, чтобы потом получить ни на что не годного человека, пошедшего по кривой дорожке.
В шахты их и пусть работает за еду, если срок десять лет или более к примеру. Отличный контроль, самоокупаемость, хороший страх для остальных.vedenin1980
28.07.2019 10:48+2Было уже при Сталине, когда миллионами зеков строили БАМ'ы и подобные проекты. По факту, получался такой рабовладельческий строй. Очень соблазнительно для любой власти, особенно если в лагеря отправлять за любые проступки и доносы.
mig126
28.07.2019 11:51Читайте внимательно. От десяти лет и более, когда вышедший к мирной жизни(как и вышедшие на пенсию военные) не пригоден, т.к. не имеет ни актуальной профессии, ни желания работать за копейки.
Перегибать палку могут все и нужна система сдерживания и контроля.Fenzales
28.07.2019 15:05От десяти лет и более, когда вышедший к мирной жизни(как и вышедшие на пенсию военные) не пригоден
Это проблема реализации, а не концепции тюрем.
Andry81
28.07.2019 11:52+2А зачем тюрьме самоокупаемость?
Заключенный это мой согражданин и я обязан его кормить. Это форма наказания, а не рабства.
tyomitch
28.07.2019 11:58+2В развитых странах — это форма реабилитации, где и профессии научат, и социализируют, и психику подправят.
Gar02
28.07.2019 16:04-1Ага, конечно. В «оплоте демократии», например, заключённые частных тюрем делают кевларовые каски для военных. И много чего чего другого. Там не просто самоокупаемость, там — не хилые прибыли.
mig126
28.07.2019 16:53Вот вот, но наши любят перенимать только плохой опыт. Либо игнорировать проблему пока поздно не станет, а потом спешно затыкать щели в рушащейся плотине.
Andry81
28.07.2019 18:02+1Это приводит к подобным случаям, в России тоже ЗК много где работают, причем зарабатывая для своих патронов большие деньги и для себя ничтожные
Я где-то уже слышал, что Россия это нищие США, вот только не знаю расценивать это как комплимент или как оскорбление?
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 году
Fenzales
28.07.2019 19:32Поэтому в США процент рецидивов — 76%, а в Норвегии — 20%.
mig126
28.07.2019 19:48+1Не берут их никуда после тюрьмы, вот и безвыходная ситуация.
А в Норвегии об этом задумались и сделали или какие нибудь льготы на таких сотрудников или в случае жалобы на немотивированный отказ компании прилетает штраф.
Gar02
28.07.2019 16:02+5Интересно, удалось ли наказать хоть одну компанию-разработчика ПО или железа за применение «запланированного устаревания»? Вот прямо с миллионными компенсациями и уголовными сроками.
Сдаётся мне, что нет.Iv38
29.07.2019 04:18Это ж ещё поди докажи. Редко когда запланированное устаревание явное. Но из таких случаев можно вывернуться. Как Apple со снижением частоты процессора у старых смартфонов. Факт как бы установлен, но формально цель благая — обеспечить функционирование аппарата с изношенной батареей. Да и разве есть законы, позволяющие за такое наказать? Ну кроме картельных сговоров производителей. Так-то никто не мешает уменьшать срок эксплуатации собственных изделий. Потребитель по идее может проголосовать деньгами против этого.
lotse8
28.07.2019 16:16+1Так поступать нельзя по многим причинам. От юридических до моральных. Показательную посадку сделают, чтобы другие задумались.
Antonariy
30.07.2019 20:49Ну тупыыые (в сименсе). Пароль снимается щелчком пальцев, как тут уже заметили. вскрыть, проанализировать и сделать вид, что оно само вскрылось (или как там они добрались до сути проблемы и обвинения в суде через тернии авторского права), можно было еще годы назад.
tvr
Немного не в тему, но около неё.
А как квалифицируется случай, когда исполнитель закладывает тайм-бомбу в качестве страховки на случай неоплаты заказчиком его творения и этот случай таки наступает?
121212121
Смотря какой случай наступит.
Если творение не будет оплачено и сработает бомба — ну так оно еще и не принадлежит заказчику, какие могут быть вопросы в исполнителю.
А вот если заказчик оплатит, а бомба сработает — ну тогда будет сценарий, как в статье.
DrPass
С юридической точки зрения — нет, в общем случае сценарий как в статье (точнее, не как в статье, а помягче, т.к. тут-то имеются признаки мошенничества) будет даже если ещё не оплачено. Вот если исполнитель позаботился о себе, и указал в договоре с заказчиком пункт, что «права на использование программного обеспечения переходят к заказчику только после полной оплаты», тогда к нему претензий нет. Если же подобного пункта в договоре нет, то передача программы в пользование и оплата за неё — два независимых обязательства, и нарушение обязательств со стороны заказчика никак не избавляет программиста от ответственности за нарушение обязательств со своей стороны.
vitalyvitaly
А как будет отличаться случай, когда заказчики грубо говоря стырят сырую незаконченную версию кода и начнут им пользоваться, на самом деле и не собираясь за него платить, и тем не менее предъявят претензии автору, когда сработают баги сырой версии?
DrPass
А это смотря как договаривались. Если есть договор с условиями поставки и оплаты, то вот за нарушение условий договора можно с заказчиком судиться. Если договора нет, то судиться тоже можно, т.к. понятие «устный договор» в ГК тоже предусмотрено, но какие-либо претензии друг другу выставить, дело гиблое.
И в любом случае, встраивать таймбомбы — это полный идиотизм со стороны разработчика, и создание самому себе потенциальной проблемы на пустом месте. Хотите обезопасить себя от неуплаты со стороны заказчика, впишите в договор пункт о передаче прав после оплаты, и сделайте вместо таймбомбы обычный триал, допустим, на месяц, с сообщением после этого: «Вы пользуетесь нелицензионной версией программного обеспечения. Для продолжения использования, пожалуйста, приобретите ключ».
AlexWenner
Адекватные люди понимают, что за встроенную в ПО подлянку может прилететь ответка.
Да, она может быть даже несправедливой.
И даже вне рамок правового поля.
Поэтому выстраивать сотрудничество надо таким образом, чтобы мыслей о подобного рода защите не возникало.
VBKesha
Например работать по предоплате, чего как раз очень не любит заказчик.
vitalyvitaly
Microsoft, кстати, вставлял логические бомбы в самые ранние версии Word для DOS (периода 1982-83 годов). Там есть фрагмент кода с вызовом сообщения в духе «Копия Word пиратская, стираю ваш жесткий диск в наказание». Читал об этом. Но не ясно, рабочая ли это была ветка когда и срабатывала ли она у кого-то реально. Особенно весело было, видимо, если она срабатывала у законного покупателя программы.
vitalyvitaly
А смысл минусовать? Это реальная история, оказывается, они так с отладчиками боролись по одной из версий. «The early versions of Word also included copy protection mechanisms that tried to detect debuggers, and if one was found, it produced the message „The tree of evil bears bitter fruit. Only the Shadow knows. Now trashing program disk.“ and performed a zero seek on the floppy disk (but did not delete its contents» (wiki-en)
toastytech.com/guis/word1153.html
saboteur_kiev
В те годы в программах вообще было очень много пасхалок и шуток. Если вы сами прочитаете статью по ссылке, то увидите что там около 20 шутливых сообщений, и это — всего лишь одно из них. Никакого реального удаления или стирания — не было, только вывод сообщения, и в худшем случае (в дос) перезагрузка.
saboteur_kiev
А пруфы?
А то вики говроит, что первая версия ворда вышла только в конце 83.
vitalyvitaly
Выше в комментарии ссылка. На самом деле, как я понимаю, они только пугали пользователей, хотя дергать головки дисков для пугающих звуковых эффектов и пугать юзеров страшными надписями не лучший метод.
tyomitch
Персоналок с жёстким диском в 1982-83 ещё тупо не существовало.
vitalyvitaly
Так вполне существовали. ST-506 на 5 мегабайт выпустили еще в 1980. Другое дело, что стандартной для PC стала только следующая модель ST-412 и поддержка HDD в DOS появилась только со второй версии. Но нестандартные способы подключения существовали и в 1981 году. Выпуск жесткого диска для Apple III — сентябрь 1981 года collection.maas.museum/object/457105
Что не меняет того факта, что первый комментарий писался еще по памяти и там на самом деле скорее всего в виду имелась дискета. (Правда, ранние нестандартные способы подключения HDD тоже могли использовать этот интерфейс. В частности, еще потому, что в PC не было и поддержки HDD в BIOS. Однако это можно было обойти кастомным перешиванием BIOSa. Некоторые сведения были в старой книжке Питера Нортона «Работа с жестким диском IBM PC» )
DrPass
Так поддержка HDD в BIOS материнки там и не требовалась, соответствующая прошивка была в контроллере.
vitalyvitaly
В PC и XT очень даже требовалась. Во-первых, диск бы тупо не увиделся с BIOSи не было бы никакой возможности загрузки с него. Никакого автоопределения параметров не было еще много лет. И кстати работал BIOS поначалу только со строго определенным списком дисков, параметры которых были прописаны в нем же. Сначала вроде 23 модели, потом 46, и уже на продвинутых 286-х появился знаменитый тип 47, где можно было указать параметры диска вручную. Но еще без автоопределения, поэтому их надо было знать или подсмотреть на корпусе самого винчестера. С неподдерживаемыми типами FDD (а-ля 5.25 1.2 мб, 3.5 дюйма) ранние PC/XT BIOS точно так же не умели работать. Стандартного способа добавить эту поддержку программно не было. Но я все про стандартную брендовую технику IBM раннего периода. Не уверен, что там на клонах могли наворотить. Говорят, что так без поддержки BIOS мог загружаться интерфейс ESDI (?), но это вроде уже конец восьмидесятых. Вспомню еще поддержку жесткого диска советским монстром «Искра-226», восходящим к технологиям ранних семидесятых. В какой-то из комплектаций он имел жесткий диск, по-моему, клон все того же 5-мегабайтного ST-506 и поддержка HDD (низкоуровневая!) была прямо во встроенном Бейсике — low level format и посекторный доступ. Настоящий динозавр технологий.
DrPass
Не требовалась. BIOS в PC и XT имел одну универсальную функцию загрузки — сканировал память выше ОЗУ на предмет специальной сигнатуры, и передавал туда управление, если находил.
Соответственно, если в системе был какой-либо контроллер, он отображал на память свою прошивку с этой сигнатурой и загрузчиком. И функции int 13h, int 19h для управления жестким диском и загрузки с него соответственно были непосредственно реализованы уже в самом контроллере, а не в BIOS материнки
vitalyvitaly
Вот теперь мне интересно, откуда взялось ограничение " Supports up to 528MB from a table of drive descriptions in BIOS ROM. No support for >1024 cylinders or drives >528MB or LBA." в Original XT Bios. Как я понимаю, это все-таки ограничение самого Bios XT, если правильно понимаю. И вот вышеизложенное Вами — это скорее всего в основном для типов ST506/MFM (?), потому что были и клоны XT со встроенным 8-битным IDE, кажется, ранние PS/2 с 8088 процессором кажется такие были, и там вроде бы эта поддержка перенесена в системный ROM и в остальном все как «на двойке» и диск должен выбираться из нескольких заданных типов. Thanks. Причем и сам IDE-диск должен был поддерживать 8-битный тип. У меня был такой диск Seagate на 40 мегабайт, с переключателем, видимо, один из последних таких.
Вроде как не оригинальный BIOS PC, а только версии после августа 1982 года. Вроде бы IBM потом рассылала новый чип владельцам старых систем.
DrPass
Это ограничение в параметрах int 13h. Собственно, даже не ограничение, а всего лишь предел возможностей прямой адресации CHS. Макс. количество головок * макс. кол-во цилиндров * макс. кол-во секторов = 528 Мб. Это касается любого накопителя с прямой адресацией.
Потом уже, когда места в микросхемах ПЗУ стало больше, как и потребностей в дисковом пространстве, добавили виртуальную адресацию, когда указывался просто виртуальный номер сектора, а в реальные адреса на накопителе уже транслировала прошивка. Это тот самый LBA.
Это справедливо для всех РС/РС ХТ, независимо от того, какой контроллер туда ставили, оригинальный MFM или всякого рода альтернативные, в том числе и IDE. Но естественно, никто не запрещал производителям клонов делать всё, что угодно. Очевидно, что среди них могли быть и девайсы с драйвером HDD в BIOS. Собственно, далеко не надо ходить, например, советский/украинский Поиск-2, или там ЕС 1842 имели код для поддержки винта уже в BIOS. Но это, минуточку, конец 1980-х, когда в западном мире уже 386-е вовсю выпускались, и вот-вот 486 пойдут.
Насчет этого не в курсе, если честно. Вполне может быть.
vitalyvitaly
Да, все правильно. На карте контроллера есть свой 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 вроде точно была. Только сейчас эту древность вспомнил.
DrPass
Да я знаю, я же не совсем посторонний чувак в отношении к контроллерам накопителей PC XT. Вон, см, надпись на плате:
s005.radikal.ru/i211/1404/be/e0c2256ddff3.jpg
vitalyvitaly
Круто!
vitalyvitaly
Ранние BIOS IBM PC 5150 до версии от 27 октября 1982 года не умели читать ROM с карт контроллеров. Также известны, как «544 K» BIOS, там стояло по дизайну ограничение памяти в 544 Кб. Вот даже фото знаменитого апгрейд-набора от IBM нашлось в сети
www.minuszerodegrees.net/5150/early/5150_bios_upgrade_kit.jpg
DrPass
Интересный момент, спасибо, не знал
vitalyvitaly
В BIOS была функция 40H для дискет и 13H вроде бы вставал на ее место. Не уверен, можно ли назвать это фирменным хаком и использовали ли IBM для этого то, что интерфейс ST/506 и произошел от контроллера гибких дисков и, видимо, наследственная совместимость сохранялась для упрощения работы. Но как-то становятся понятнее описанные когда-то Нортоном дикие ухищрения ранних 80х вроде контроллеров ленточных стримеров, которые имитировали привод гибких дисков и сажались на этот же интерфейс.
vitalyvitaly
В общем случае, как я понимаю, нужен был контроллер с загрузочным ROM, что и было стандартом во времена XT. Ко временам 286 с мультикартами IDE, с которыми я больше имел дела, загрузочный ROM с мультикарт убрали и перенесли в стандартный BIOS на материнской плате. Для XT загрузочный ROM занимает 8 килобайт в памяти, которые могут читаться с любого чипа BIOS на картах расширения www.insentricity.com/a.cl/244/adding-a-hard-drive-to-an-original-ibm-pc-using-a-raspberry-pi
Iv38
Я думаю, срабатывание таймбомбы и ущерб от нее будут квалифицироваться как отдельное дело, а факт нарушения условий договора заказчиком как ещё одно. Так что я думаю, таймбосбы в софте это в любом случае плохая идея. Должен быть грамотный договор и/или триал.
DrPass
Именно так. Причем факт нарушения условий договора заказчиком вообще никак не будет квалифицироваться, пока разработчик не соберёт доказательства и не подаст иск в суд. При этом между обоими фактами разница огромная, т.к. нарушение условий договора — это обычный хозяйственный спор, а закладки/таймбомбы в ПО проходят по уголовке.
vsb
Суть таймбомбы во введении в заблуждение заказчика? Т.е. если я считаю неправильный результат, это плохо, если я показываю MessageBox мол оплатите лицензию, это нормально? А если я падаю с access violation, это таймбомба или триал?
DrPass
В сознательном создании скрытых функций, выводящих из строя программное обеспечение. Это статья в УК. Показывать MessageBox с требованиями законно. А вот подгаживать втихаря — незаконно. Отдельный вопрос, можно ли доказать, что AV сделано намеренно, а не нечаянно. Но то такое. Первым должен идти вопрос «зачем мне это надо, если можно добиться того же результата легальным методом».
saboteur_kiev
Некоторые программы вполне могут подгаживать без лицензии. Finereader этим страдал, многие игры страдали.
Но есть разница — когда пользуются ворованным нелицензионным софтом на свой страх и риск, и то, что сделал программист — нагадил в рабочем коде, за который ему уже полностью заплатили.
holomen
Просто не нужно было делать явное сравнение с датой когда срабатывать, а чтобы оно выглядело как просто ошибка/опечатка. Я обычно такие баги с долгим периодом срабатывания намеренно не лечу до полной оплаты, а потом выкатываю апдейт «я тут противный баг нашел, который может сработать при таких вот условиях, вот исправленная версия». И не подкопаешься. Конечно, если по договору передаются исходники есть шанс что будут проводить аудит и найдут эту ошибку, но все равно не подкопаешься — баги у всех бывают. А если закопать глубоко в логике в редко срабатывающей ветке, да еще и просто всю дорогу считается что-то, кладется, потом опять считается, опять кладется, и так опять и снова. А потом когда-нибудь опять явно ничего не проверяется — просто если изначальный «ключ» был неверным, где-то далеко в глубине не те данные начнут обрабатываться в один прекрасный момент и глюки будут потихоньку нарастать. «Ну, ошибся в константе — опечатался...» Если кто помнит, Медноногов примерно так «Черный ворон» защищал.
SergeyMax
Признание — царица доказательств (с)
holomen
Вы про меня или про программиста из статьи?
Если про статью, то он совершил две ошибки — явно сравнивал с датой и признался. Хотя и с самим признанием из статьи не все ясно, т.к. непонятно чем его додавили чтобы он признался.
Если про меня, то даже вышенаписанное не может ничего доказать, т.к. четко доказать что именно в этом проекте это именно заложенная тайм-бомба а не баг — крайне сложно, практически невозможно. «Мало-ли чего в интернете писал. И вообще вспоминал что вытворял когда был молодой и глупый ))» Точнее можно, но при одном условии — я дам доступ к собственному гиту и там по истории может быть получится найти эксперименты с таким багом. Чего, конечно-же, я в трезвом уме и здравой памяти не сделаю никогда.
Source
Я ещё не понял, если он заранее знал дату срабатывания, зачем он в отпуск то уехал на эту дату?
holomen
А вот кстати да, тоже интересный вопрос. В общем складывается впечатление что горизонт планирования у этого программиста такой-же как и у «укравшего» телефон из недавней статьи.
tvr
Расслабился — ведь всё же обычно проходило гладко, в штатном (для него) режиме.
Source
Так штатный режим заключался в том, что в заранее известную дату компания обращается к нему за тех.поддержкой, он меняет дату и получает оплату. И тут он сам лишил себя возможности поменять дату...
DarkWolf13
не совсем. В наших реалиях на просторах бывшего соцлагеря все зависит от того насколько офигел заказчик. Бывает что даже то что данные тайм закладки и обозначаются отладочным или деморежимом и явно на это указывается, все равно могут вменить вымогательство. так что договор на разработку над составлять, к сожалению, с оглядкой на возможное кидалово. Некоторые очень «умные» считают, что раз нельзя потрогать руками, то можно и не платить. и тут даже если трудовой спор будет в нашу пользу, По могут продолжать пытаться пользоваться, а с отладочно-демо режимом это будет несколько затруднительно. Можно даже вспомнить некоторые европейские станки которые идут с ограничением места использования, после того как доблестные азиатские инженера начали копировать все подряд
softaria
Вы вряд ли найдете заказчика, который подпишет подобный договор. Так как у вас полно конкурентов, не настаивающих на таких условиях.
DarkWolf13
по опыту, если заказчик начинает «изобретать» с договором и не соглашается хотя бы на часть оговорок, значит он может кинуть… и тут либо обсудить сразу в чем проблема, либо идти дальше к следующему заказчику,- бесплатно работать и выезжать на доработки вне ТЗ это точно не мое… а то наладишь промустановку люди радостные думаю от эйфории, что можно кинуть… а конкурентов не так уж и много и мои заказчики ко мне приходят.
softaria
Есть еще забавный вариант. Заказчик находит бомбу. Немедленно переводит деньги за работу и сразу же подает в суд. Теперь система оплачена, и исполнитель вряд ли сможет что-то доказать.
JamboJet
Думаю, результат ещё зависит и от последствий «бомбы». Если в результате «бомбы» погибли люди (медоборудование) или причинен серьезный ущерб (взрыв газопровода) это уже совсем другое дело.
Wesha
Если "ОАО НПП „ХХХ“ не оплатило разработку это приложения", то в 5 часов утра на охраняемый объект проникают диверсанты.
edogs
Потому что любой код может повести себя непредсказуемо в любой момент времени, а в данном случае это деструктивный код о котором не знает его непосредственный пользователь.
gm1
Когда клиент платит очень часто такой сюрприз программисты делают, чтоб без денег не сидеть.