Как стать автором
Обновить

Программист внедрил логическую бомбу в таблицы Excel, чтобы гарантировать себе заказы на техподдержку

Время на прочтение 5 мин
Количество просмотров 44K
Всего голосов 48: ↑44 и ↓4 +40
Комментарии 111

Комментарии 111

НЛО прилетело и опубликовало эту надпись здесь
Смотря какой случай наступит.
Если творение не будет оплачено и сработает бомба — ну так оно еще и не принадлежит заказчику, какие могут быть вопросы в исполнителю.
А вот если заказчик оплатит, а бомба сработает — ну тогда будет сценарий, как в статье.
Если творение не будет оплачено и сработает бомба — ну так оно еще и не принадлежит заказчику, какие могут быть вопросы в исполнителю.

С юридической точки зрения — нет, в общем случае сценарий как в статье (точнее, не как в статье, а помягче, т.к. тут-то имеются признаки мошенничества) будет даже если ещё не оплачено. Вот если исполнитель позаботился о себе, и указал в договоре с заказчиком пункт, что «права на использование программного обеспечения переходят к заказчику только после полной оплаты», тогда к нему претензий нет. Если же подобного пункта в договоре нет, то передача программы в пользование и оплата за неё — два независимых обязательства, и нарушение обязательств со стороны заказчика никак не избавляет программиста от ответственности за нарушение обязательств со своей стороны.
А как будет отличаться случай, когда заказчики грубо говоря стырят сырую незаконченную версию кода и начнут им пользоваться, на самом деле и не собираясь за него платить, и тем не менее предъявят претензии автору, когда сработают баги сырой версии?
А это смотря как договаривались. Если есть договор с условиями поставки и оплаты, то вот за нарушение условий договора можно с заказчиком судиться. Если договора нет, то судиться тоже можно, т.к. понятие «устный договор» в ГК тоже предусмотрено, но какие-либо претензии друг другу выставить, дело гиблое.
И в любом случае, встраивать таймбомбы — это полный идиотизм со стороны разработчика, и создание самому себе потенциальной проблемы на пустом месте. Хотите обезопасить себя от неуплаты со стороны заказчика, впишите в договор пункт о передаче прав после оплаты, и сделайте вместо таймбомбы обычный триал, допустим, на месяц, с сообщением после этого: «Вы пользуетесь нелицензионной версией программного обеспечения. Для продолжения использования, пожалуйста, приобретите ключ».
Адекватные люди понимают, что за встроенную в ПО подлянку может прилететь ответка.
Да, она может быть даже несправедливой.
И даже вне рамок правового поля.

Поэтому выстраивать сотрудничество надо таким образом, чтобы мыслей о подобного рода защите не возникало.
Например работать по предоплате, чего как раз очень не любит заказчик.
Microsoft, кстати, вставлял логические бомбы в самые ранние версии Word для DOS (периода 1982-83 годов). Там есть фрагмент кода с вызовом сообщения в духе «Копия Word пиратская, стираю ваш жесткий диск в наказание». Читал об этом. Но не ясно, рабочая ли это была ветка когда и срабатывала ли она у кого-то реально. Особенно весело было, видимо, если она срабатывала у законного покупателя программы.
А смысл минусовать? Это реальная история, оказывается, они так с отладчиками боролись по одной из версий. «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
В те годы в программах вообще было очень много пасхалок и шуток. Если вы сами прочитаете статью по ссылке, то увидите что там около 20 шутливых сообщений, и это — всего лишь одно из них. Никакого реального удаления или стирания — не было, только вывод сообщения, и в худшем случае (в дос) перезагрузка.
А пруфы?

А то вики говроит, что первая версия ворда вышла только в конце 83.
Выше в комментарии ссылка. На самом деле, как я понимаю, они только пугали пользователей, хотя дергать головки дисков для пугающих звуковых эффектов и пугать юзеров страшными надписями не лучший метод.
Microsoft, кстати, вставлял логические бомбы в самые ранние версии Word для DOS (периода 1982-83 годов). Там есть фрагмент кода с вызовом сообщения в духе «Копия Word пиратская, стираю ваш жесткий диск в наказание».

Персоналок с жёстким диском в 1982-83 ещё тупо не существовало.
Так вполне существовали. 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» )
В частности, еще потому, что в PC не было и поддержки HDD в BIOS.

Так поддержка HDD в BIOS материнки там и не требовалась, соответствующая прошивка была в контроллере.
В 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 и посекторный доступ. Настоящий динозавр технологий.
В PC и XT очень даже требовалась. Во-первых, диск бы тупо не увиделся с BIOSи не было бы никакой возможности загрузки с него.

Не требовалась. BIOS в PC и XT имел одну универсальную функцию загрузки — сканировал память выше ОЗУ на предмет специальной сигнатуры, и передавал туда управление, если находил.
Соответственно, если в системе был какой-либо контроллер, он отображал на память свою прошивку с этой сигнатурой и загрузчиком. И функции int 13h, int 19h для управления жестким диском и загрузки с него соответственно были непосредственно реализованы уже в самом контроллере, а не в BIOS материнки
Вот теперь мне интересно, откуда взялось ограничение " 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 и 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 вроде точно была. Только сейчас эту древность вспомнил.
Да я знаю, я же не совсем посторонний чувак в отношении к контроллерам накопителей PC XT. Вон, см, надпись на плате:
s005.radikal.ru/i211/1404/be/e0c2256ddff3.jpg
Круто!
Ранние BIOS IBM PC 5150 до версии от 27 октября 1982 года не умели читать ROM с карт контроллеров. Также известны, как «544 K» BIOS, там стояло по дизайну ограничение памяти в 544 Кб. Вот даже фото знаменитого апгрейд-набора от IBM нашлось в сети

www.minuszerodegrees.net/5150/early/5150_bios_upgrade_kit.jpg
Интересный момент, спасибо, не знал
В BIOS была функция 40H для дискет и 13H вроде бы вставал на ее место. Не уверен, можно ли назвать это фирменным хаком и использовали ли IBM для этого то, что интерфейс ST/506 и произошел от контроллера гибких дисков и, видимо, наследственная совместимость сохранялась для упрощения работы. Но как-то становятся понятнее описанные когда-то Нортоном дикие ухищрения ранних 80х вроде контроллеров ленточных стримеров, которые имитировали привод гибких дисков и сажались на этот же интерфейс.
В общем случае, как я понимаю, нужен был контроллер с загрузочным 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

Я думаю, срабатывание таймбомбы и ущерб от нее будут квалифицироваться как отдельное дело, а факт нарушения условий договора заказчиком как ещё одно. Так что я думаю, таймбосбы в софте это в любом случае плохая идея. Должен быть грамотный договор и/или триал.

Я думаю, срабатывание таймбомбы и ущерб от нее будут квалифицироваться как отдельное дело, а факт нарушения условий договора заказчиком как ещё одно

Именно так. Причем факт нарушения условий договора заказчиком вообще никак не будет квалифицироваться, пока разработчик не соберёт доказательства и не подаст иск в суд. При этом между обоими фактами разница огромная, т.к. нарушение условий договора — это обычный хозяйственный спор, а закладки/таймбомбы в ПО проходят по уголовке.
НЛО прилетело и опубликовало эту надпись здесь
Суть таймбомбы во введении в заблуждение заказчика?

В сознательном создании скрытых функций, выводящих из строя программное обеспечение. Это статья в УК. Показывать MessageBox с требованиями законно. А вот подгаживать втихаря — незаконно. Отдельный вопрос, можно ли доказать, что AV сделано намеренно, а не нечаянно. Но то такое. Первым должен идти вопрос «зачем мне это надо, если можно добиться того же результата легальным методом».
Некоторые программы вполне могут подгаживать без лицензии. Finereader этим страдал, многие игры страдали.

Но есть разница — когда пользуются ворованным нелицензионным софтом на свой страх и риск, и то, что сделал программист — нагадил в рабочем коде, за который ему уже полностью заплатили.
Просто не нужно было делать явное сравнение с датой когда срабатывать, а чтобы оно выглядело как просто ошибка/опечатка. Я обычно такие баги с долгим периодом срабатывания намеренно не лечу до полной оплаты, а потом выкатываю апдейт «я тут противный баг нашел, который может сработать при таких вот условиях, вот исправленная версия». И не подкопаешься. Конечно, если по договору передаются исходники есть шанс что будут проводить аудит и найдут эту ошибку, но все равно не подкопаешься — баги у всех бывают. А если закопать глубоко в логике в редко срабатывающей ветке, да еще и просто всю дорогу считается что-то, кладется, потом опять считается, опять кладется, и так опять и снова. А потом когда-нибудь опять явно ничего не проверяется — просто если изначальный «ключ» был неверным, где-то далеко в глубине не те данные начнут обрабатываться в один прекрасный момент и глюки будут потихоньку нарастать. «Ну, ошибся в константе — опечатался...» Если кто помнит, Медноногов примерно так «Черный ворон» защищал.
Признание — царица доказательств (с)
Вы про меня или про программиста из статьи?
Если про статью, то он совершил две ошибки — явно сравнивал с датой и признался. Хотя и с самим признанием из статьи не все ясно, т.к. непонятно чем его додавили чтобы он признался.
Если про меня, то даже вышенаписанное не может ничего доказать, т.к. четко доказать что именно в этом проекте это именно заложенная тайм-бомба а не баг — крайне сложно, практически невозможно. «Мало-ли чего в интернете писал. И вообще вспоминал что вытворял когда был молодой и глупый ))» Точнее можно, но при одном условии — я дам доступ к собственному гиту и там по истории может быть получится найти эксперименты с таким багом. Чего, конечно-же, я в трезвом уме и здравой памяти не сделаю никогда.

Я ещё не понял, если он заранее знал дату срабатывания, зачем он в отпуск то уехал на эту дату?

А вот кстати да, тоже интересный вопрос. В общем складывается впечатление что горизонт планирования у этого программиста такой-же как и у «укравшего» телефон из недавней статьи.
НЛО прилетело и опубликовало эту надпись здесь

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

не совсем. В наших реалиях на просторах бывшего соцлагеря все зависит от того насколько офигел заказчик. Бывает что даже то что данные тайм закладки и обозначаются отладочным или деморежимом и явно на это указывается, все равно могут вменить вымогательство. так что договор на разработку над составлять, к сожалению, с оглядкой на возможное кидалово. Некоторые очень «умные» считают, что раз нельзя потрогать руками, то можно и не платить. и тут даже если трудовой спор будет в нашу пользу, По могут продолжать пытаться пользоваться, а с отладочно-демо режимом это будет несколько затруднительно. Можно даже вспомнить некоторые европейские станки которые идут с ограничением места использования, после того как доблестные азиатские инженера начали копировать все подряд
Вы вряд ли найдете заказчика, который подпишет подобный договор. Так как у вас полно конкурентов, не настаивающих на таких условиях.
по опыту, если заказчик начинает «изобретать» с договором и не соглашается хотя бы на часть оговорок, значит он может кинуть… и тут либо обсудить сразу в чем проблема, либо идти дальше к следующему заказчику,- бесплатно работать и выезжать на доработки вне ТЗ это точно не мое… а то наладишь промустановку люди радостные думаю от эйфории, что можно кинуть… а конкурентов не так уж и много и мои заказчики ко мне приходят.
Есть еще забавный вариант. Заказчик находит бомбу. Немедленно переводит деньги за работу и сразу же подает в суд. Теперь система оплачена, и исполнитель вряд ли сможет что-то доказать.
Думаю, результат ещё зависит и от последствий «бомбы». Если в результате «бомбы» погибли люди (медоборудование) или причинен серьезный ущерб (взрыв газопровода) это уже совсем другое дело.
как квалифицируется случай, когда исполнитель закладывает тайм-бомбу в качестве страховки на случай неоплаты заказчиком его творения и этот случай таки наступает?
Как откровенное мудачество, без вариантов.
Потому что любой код может повести себя непредсказуемо в любой момент времени, а в данном случае это деструктивный код о котором не знает его непосредственный пользователь.
Когда клиент платит очень часто такой сюрприз программисты делают, чтоб без денег не сидеть.

Пароль в экселе ничего не защищает

Ну почему, исходя из написанного в статье, пароль в экселе как минимум защищает от аудита сотрудниками самсунга :)

НЛО прилетело и опубликовало эту надпись здесь
пароль в экселе как минимум защищает от аудита сотрудниками самсунга :)
Защищает больше чем может показаться. Это скорее юридическая защита, т.к. обход пароля во-первых будет означать уголовную статью, во-вторых полученные нелегальным способом данные нельзя будет использовать как доказательства.
Я не уверен, что тут можно говорить о какой-либо юридической защите. Софт этого инженера скорее всего не был защищен ничем, кроме авторского права. «Обход пароля» как таковой не требуется — сам код программы хранится в файле VbaProject.bin, который не защищен никаким шифрованием, а значит открытие и чтение его не нарушает никаких законов. Почему в Сименс этого не делали — я не знаю. Скорее всего, не видели необходимости разбираться в чужом коде.
«Обход пароля» как таковой не требуется — сам код программы хранится в файле VbaProject.bin, который не защищен никаким шифрованием, а значит открытие и чтение его не нарушает никаких законов.
И все же в данном случае нарушило бы.
Проникновение в чужую собственность (код) все равно проникновение, даже если заход был через непостроенную стену (незащищенный файл), при наличии закрытой двери (пароля). Основной нюанс в том, что дверь была закрыта и сименс об этом знал, поэтому проход через непостроенную стену это уже «обход пароля», а не просто «чтение файла».
Сложный вопрос. В данном случае софт сделан по заказу, и в зависимости от договора заказчику могут принадлежать все имущественные права на него. Но даже если это не так, то законы могут позволять декомпилировать и изменять софт для обеспечения его функционирования, как это позволяет конечному пользователю ГК РФ, например.

"Логическая бомба" — как-то слишком громко звучит для тупого триггера по дате. Вот нарушение логического закона тождества A = A в C-подобных языках программирования — это да, бомба так бомба.

НЛО прилетело и опубликовало эту надпись здесь

Вы про NaN? (который, как известно, не равен сам себе)

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


Как следствие — компания-заказчик обращается к тому же поставщику (так как в подобном коде уже никто другой особо разобраться и не сможет задешево), а потом еще раз и так далее. Получается такой мягкий vendor lock-in.


Так вот: в таком сценарии намеренное игнорирование рекомендаций Google по разработке сайтов в некотором смысле являются теми же таймбомбами.

Как вы плавно перевели от Excel к разработке сайтов по рекомендации Google.


Надеюсь, за игнорированиям этих рекомендаций в суд пока не тянут? А то стало страшно.

Получается такой мягкий vendor lock-in.

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

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

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

Любую самую простую логику можно обернуть таким кол-вом абстракций и условно нужных фич, что после этого потребуются многие недели, чтобы просто понять, что происходит.

Да, в «коробочном» решении тоже самое, если документации и api идеальны никто не купит техподержку и допиливание фич или закажет их у любого другого стороненного разработчика. Поэтому часто разрабочик заинтересован не делать продукт слишком хорошо.
Любую самую простую логику можно обернуть таким кол-вом абстракций и условно нужных фич, что после этого потребуются многие недели, чтобы просто понять, что происходит.


Очень часто подобное наблюдается в индусском коде — абстракция на абстракции сидит и абстракцией погоняет.
А вот нифига. Специально делать закладки в СВОЁМ коде, специально направленные на то, чтобы он перестал работать — это одно дело. А предвидеть наперёд всё, что теоретически может поменяться — это совсем другое. У вас, например, есть список на следующие 15 лет, какие функции в WinAPI или Web-стандартах станут работать по-другому или перестанут работать вообще, в том числе не намеренно, а из-за сайд-эффектов от других изменений?
НЛО прилетело и опубликовало эту надпись здесь
А, это такая группа чуваков, которая за вас решает, найдут ли ваш сайт другие пользователи или не найдут.
А теперь ещё и решают, в большинстве случаев, увидите ли вы сайт в принципе (нет SSL даже на текстовом сайте без персональных данных? Бан!)
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
Я-то про DDG в курсе. Но он мне никак не поможет решить проблему. По крайней мере, пока вы не придумаете способа перейти на него всем остальным пользователям.

Здесь важно доказать намерение. Иначе даже простую ошибку можно зачесть за саботаж.

Deprecated: mysql_connect(): The mysql extension is deprecated and will be removed in the future: use mysqli or PDO instead in
Для не понявших юмора: использовать функции, о которых точно известно, что через некоторое время они перестанут работать сами, безо всяких логических бомб.
В ту же копилку тотальное кэширование и логирование без средств очистки. Туда же «не замеченные» баги в ТЗ, особенно в случае формального отсутствия такового. И ещё тысячи способов, от всех никаким договором не защитишься.
Но нафига?
По уму если, то вовсе не надо никаких таких гадостей делать, а нужно выбирать проекты, которым неиминуемо потребуется доработка в связи с развитием. Да, для такого предвидения необходим опыт, но странно, что 52-летний чувак им не обладал либо поленился и предпочёл вместо этого пойти к успеху кривой дорожкой.
использовать функции, о которых точно известно, что через некоторое время они перестанут работать сами, безо всяких логических бомб.

Вообще, если вдаваться в детали, то сами они работать не перестанут. Только в результате конкретных действий — обновления.

… обновления, произведённого партнёром (хостером) в лучшем случае с уведомлением клиента по email, но в любом случае без даже совещательного голоса этого самого клиента.
Если вы фрилансер, просто делайте работу хорошо, и к вам опять обратятся старые клиенты с новыми заказами. А если хитрить, оставлять закладки и т.п. — в лучшем случае вашу работу просто выкинут, и больше с вами не будут иметь дела.
А в худшем — поставят плохой отзыв или подадут в суд, и с фрилансом вы можете распрощаться навсегда.
Делать работу хорошо — требует усилий.
А раз в пол года для десяти заказчиков менять дату в коде — это ничего не стоит, а деньги приносит.
Так что то что вы предлагаете и то что делал герой статьи — это не одно и тоже.

Ну и в целом, про делайте работу хорошо, немного личного опыта:
Пришел заказчик, просит сделать некую софтину для большого клиента. Я не помню деталей, но не суть.
Я думаю: сделаю хорошо и удобно. Пусть заказчик порадуется.
В итоге сделал удобный конфиг с настройками, чтобы и urlы все можно было удобно настраивать, и дизайн менять удобно и верстку.
И что вы думаете? Через пару месяцев мою прогу переверстали без моего участия и продали еще одному заказчику. А потом еще и еще.

В следующий раз я всё захардкодил, все редакторы которые сделал для верстки и настройка оставил себе. И что вы думаете? Через месяц ко мне пришли за редизайном.

И вот с тех пор я каждый раз думаю, а выгодно ли мне делать заказчику хорошо? И каждый раз отвечаю: нет, мне выгодно делать по ТЗ. А хорошо — только за отдельные деньги.
Бывают проекты типа прототипа на 1-2 дня. Мне заключать договоры по ним или надеяться на порядочность неизвестного заказчика? Без бомб не вижу смысла браться за такие работы. В остальном да. Крупные и средние проекты требуют большой ответственности, меня до сих пор мучают мысли, что несколько таких запорол и в свое время бросил, потому что либо угорел, либо были другие причины. Лучше десять раз подумать и в полной мере оценить, прежде чем хвататься без разбора за подобные. За 4 года у меня было несколько конфликтов, но они все решились (один раз даже до суда накал был), цепляться за старых заказчиков можно, но не всегда получается держать ценовую планку, как ни странно, потому что чем дольше работаю с определенным заказчиком, тем меньше в результате получаю по деньгам. Парадокс для меня

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

тут скорее всего рассмотрение и публичность обозначена для того, чтобы другим не повадно было, а то один человек целую корпорацию почти развел.
Ну то есть желательно работать вообще без договора и спокойно оставлять закладки, тогда
и прицепиться не к чему, договора не было и работы соответственно тоже, а уж что там заказчик запустил, его проблема.
одно не понятно — если он дал пароль это ведь обозначает что компания может сама вбросить туда тайм бомбу. Как именно суд постановил что виноват именно Дэвид? Как доказали что именно он написал этот код? Если вводили пароль и смотрели код в присутствии нотариуса и понятых и на камеру — даже в этом случае в компьютере заранее могла быть написана программа которая вставляла бы вредоносный код в xls фаилы сразу как получают к ним доступ. Таких программ на самом деле сотни. Всякие win locker-ы которые потом после того как ломают файлы вымогают перевести деньги на биткоин кошельки.
Либо я чего то не понимаю, либо сейчас подставить человека слишком легко.
Вероятно, как обычно — пришли свидетели с обоих сторон, дали показания, а суд решал кому он больше верит.

сейчас подставить человека слишком легко.

Да это всегда было легко. Дали работнику и партнеру доступ к проду, а потом заявили, что именно он его сломал специально. Как доказать обратно? Или даже не на прод, мало ли вирус в сеть запустил, троян поставил, багов в код накидал, информацию конкурентам сливал и т.п.

Он сам признал себя виновным. Судя по информации ранее ему предлагали уладить спор, но он все отрицал. Затем пробовал сослаться на то, что ошибки были вызваны не обнаруженными закладками, а несовместимостью с новыми апдейтами Excel. В результате дело дошло до полномасштабных слушаний. Решения пока нет, приговор будет вынесен в ноябре.

Например, он отправил файл по электронной почте.
Программист разработал для компании сложные таблицы Excel с формулами

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

По логике, время, которое он потратил на разработку, оплачено компанией. Значит разработанная интеллектуальная собственность тоже переходит компаниии.
Какая тут может быть защита того, что ему уже не принадлежит? Пароль, по идее, тоже должен быть передан компании вместе с таблицей. Странно, что они его не потребовали сразу.
Нет.
У меня есть заказчик, для которого я делаю софт достаточно уникальный и на который при этом чуть ли не весь бизнесу у заказчика завязан. Если я пропаду — он сможет это пережить, но стресс в его бизнесе будет приличный скорее всего.
Так вот, вопрос передачи исходников не поднимался никогда.
Я по косвенным признакам пришел к выводу, что заказчик уже с таким сталкивался и ему зарядили огромную цену за передачу исходников. Поэтому он считает, что нет смысла меня просить об этом.
Хотя по факту, я бы сразу передал. Впрочем думаю через некоторое время, когда проект стабилизируется полностью — я по своей инициативе сорсы передам, а то тупость какая-то — Помру например, а у людей честно оплативших работу бизнес просядет.

С другой стороны это вводимая сейчас всеми "сервисная модель" т.е. вам платят не за АО а за услугу его предоставления на срок :)
В это части очень интересна ситуация с крупными корпорациями рискующими попасть под санкции, как-то присутствовал на демонстрации одного иностранного продукта(в общем его предполагалось использовать как замену живым людям, которых соответственно предполагалось "оптимизировать") который поставляется только по timeshare лицензии на год, и во время презентации меня всё гложил вопрос, а как же непрерывность деятельности и санкции…
Так вот в итоге когда этот вопрос был задан, уровень оптимизма у презентовавших продукт как-то поубавился, но уверили что работают по данному направлению.

Не нужно путать трудовые отношения с гражданско-правовыми.

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

Итак независимый подрядчик который написал какуюто софтина, и на её поддержку за 15 лет потратили меньше $5000(около 28$ в месяц). И с которого потом ещё и поимели 42000$
Я думаю они достаточно хороши.
Судя по статье, $5000 — это рассчитанная сумма ущерба, а не сумма оплаты труда программисту. Ну т.е. сюда входит лишь стоимость ликвидаций очередных срабатываний таймбомбы и возможно какой-то доказанный ущерб от простоя. Очевидно, платили-то ему больше.

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 году
Поэтому в США процент рецидивов — 76%, а в Норвегии — 20%.
Не берут их никуда после тюрьмы, вот и безвыходная ситуация.
А в Норвегии об этом задумались и сделали или какие нибудь льготы на таких сотрудников или в случае жалобы на немотивированный отказ компании прилетает штраф.
Интересно, удалось ли наказать хоть одну компанию-разработчика ПО или железа за применение «запланированного устаревания»? Вот прямо с миллионными компенсациями и уголовными сроками.
Сдаётся мне, что нет.
Это ж ещё поди докажи. Редко когда запланированное устаревание явное. Но из таких случаев можно вывернуться. Как Apple со снижением частоты процессора у старых смартфонов. Факт как бы установлен, но формально цель благая — обеспечить функционирование аппарата с изношенной батареей. Да и разве есть законы, позволяющие за такое наказать? Ну кроме картельных сговоров производителей. Так-то никто не мешает уменьшать срок эксплуатации собственных изделий. Потребитель по идее может проголосовать деньгами против этого.
Так поступать нельзя по многим причинам. От юридических до моральных. Показательную посадку сделают, чтобы другие задумались.
НЛО прилетело и опубликовало эту надпись здесь
Ну тупыыые (в сименсе). Пароль снимается щелчком пальцев, как тут уже заметили. вскрыть, проанализировать и сделать вид, что оно само вскрылось (или как там они добрались до сути проблемы и обвинения в суде через тернии авторского права), можно было еще годы назад.
Зарегистрируйтесь на Хабре , чтобы оставить комментарий

Другие новости

Истории