Чи варто включати метод самозашкодження до моїх додатків?

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

Однак я все одно можу отримати доступ до панелі адміністратора CMS. На жаль, виявляється, що моє програмне забезпечення дуже захищене. Пробував SQL-ін'єкцію, підробляти завантаження зображень і т. Д. Однак я не можу зламати власне програмне забезпечення. У будь-якому разі, я готуюсь подати в суд на цю особу, щоб це не було Проблема .. Я зараз думаю лише про те, що, можливо, має бути якийсь метод самозашкодження, Тож у випадку подібного випадку у мене є можливість вбити програмне забезпечення.

Моя власна ідея - приховати якусь функцію в основних файлах. Зашифруйте його base64, щоб це не було очевидно. Тож щось подібне:

eval(base64_decode('ZWNobyAnSGVsbG8gd29ybGQhJzs=')); // echo 'Hello world!';

І в основному зробіть невеликий сценарій, який бере всі файли програмного забезпечення, chmod's, щоб бути впевненим, а потім видаляє їх.
Мої новіші версії CMS мають усі файлові менеджери, які я міг би використовувати для легшого злому . Але що робити, якщо доступ до адміністративної панелі обмежений.

Щоб бути дуже зрозумілим , це призначене лише для програмного забезпечення на стадії розробки, на моєму персональному сервері або на сервері клієнтів (остання частина - етично сумнівна). Тож якщо мій клієнт повинен вкрасти моє програмне забезпечення. Цей вміст не повинен бути включений у комерційний -програмне забезпечення.
І щоб бути ще більш зрозумілим , ми говоримо про ті рідкісні позаштатні роботи. Я думаю, що цілком логічно, що контрактна робота не потребує таких методів. Таким чином , ми говоримо про тих jumprisk-клієнтів, тільки в режимі розробки - коли проект буде готовий, то , очевидно , це було б дуже і дуже неетично бекдор , щоб усередині вашого програмного забезпечення.

1. Етично це гарна ідея? (Маючи на увазі, що явно його зніму, коли проект на 100% і все оплачено)
2. Вам, хлопцям, колись доводилося зламати власне програмне забезпечення через подібні проблеми з клієнтом?
3. Будь-які рекомендації щодо цієї ідеї, коду та методу розумні?
4. Які можуть бути можливі недоліки чи наслідки сценаріїв саморуйнування?

Мій висновок з цього приводу

Трохи сумно, що всі відповіді були орієнтовані на договірні справи. Насправді я винен, що я не став більш чітким у своєму питанні .. просто подумав, що цілком зрозуміло, що немає сенсу в перемикачі на знищення .. коли ви захищені контрактом.
Однак якщо ви виконуєте контрактну роботу .. тоді це має бути зазначено в договорі - це робить його законним навіть у власному сервері клієнтів. Однак мати перемикачі kill на моєму особистому сервері - це справді нікому не діло (це те, що я дуже хотів знати.)

Я вирішив зробити сценарій kill-switch для моєї CMS. Головним чином, тому що це здається цікавим викликом. Але також, що я міг би використати це для моїх робіт, що не мають контракту, коли клієнт є другом товариша друга .. Я, мабуть, не буду використовувати це на сервері клієнтів, але ... для тих випадків, коли клієнт чи деякі посередники мають доступ до мого сервера. І моє програмне забезпечення викрадається або "пересувається без мого відома", я не отримую оплати, і вони скорочують доступ до програмного забезпечення.

Я прочитав тут багато тем, де вони рекомендують надіслати попередження, а потім зняти сторінку. Ну, я бачив у ньому проблему, як коли я маю справу з людиною .. хто просто скопіює її кудись інше (можливо, ребрендує і продасть) і каже мені, що її зняли. А також я б не "вимикав сайт", а видаляв його. Хоча, мабуть, все одно незаконно отримувати доступ до сервера моїх клієнтів та видаляти його. Або, принаймні, отримати доступ до нього через бекенд, а не з FTP. За це я дякую всім вам, хто відповів.

Я не юрист. Це здається, що у вас вже є такий, щоб подати до суду на свого клієнта; тоді як ви його чи її утримуєте, я б рекомендував отримати їх поради щодо цього.

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

По-перше, якщо у вашому контракті конкретно не вказано, що ви можете відключити програмне забезпечення за неплатеж або що клієнт не має жодних прав на програмне забезпечення до отримання платежу в повному обсязі, ви не можете перевести будь-який перемикач "вбити" без з порушенням договору. Якщо відсутні будь-які слова, навпаки, "володіння - це дев'ять десятих частин закону", тож його програмне забезпечення, як тільки він буде надане у власність, і знищити його було б схоже на динаміку нової офісної будівлі, яку ви побудували для нього, якби він цього не зробив не плачу за це.

Випливає другий пункт; будь-який контракт, який Ви пропонуєте будь-якому клієнту, повинен мати застереження про те, що: "Передача інтелектуальної власності на задоволення договору" . Це означає, що навіть якщо ви надали йому копію програмного забезпечення, яке він повинен використовувати, поки він не оплатить вас повністю, він не володіє ним. Це МОЖЕ дати вам право відключити його або будь-яку копію програмного забезпечення з будь-якої причини до отримання повної оплати, оскільки воно все ще залишається вашим, і ви можете робити як завгодно. Тепер він порушив контракт, а ви цього не зробили, тож ця справа набагато простіша для представлення свого адвоката, а тим часом ваш клієнт не отримує ніякої користі від його недоброзичливих товарів.

Аналогія з підрядником будівництва дотримується: як тільки будівля, що будується, зможе бути забезпечена проти незаконного в'їзду, вона є, і підрядник, як правило, зберігає всі копії всіх ключів від приміщення, поки робота не буде завершена і не підписана, і оплата отримана в повному обсязі. Навіть після вручення ключів, якщо платіж проходить через нього, він може встановити заставу на майно і, в крайньому випадку, повернути його у власність. Те ж саме справедливо і тут; ви можете дати клієнтові ключ, щоб увійти в програмне забезпечення, але ви тримаєте "головний" ключ, і він не отримає адміністративного доступу, поки ви не заплатите повністю. Якщо він може зайти зараз і не заплатить вам, ви можете просто "змінити замки" і заблокувати його з програмного забезпечення.

Однак ви надали своєму клієнтові "головний" ключ до програмного забезпечення, і він пішов і змінив усі замки, так що тепер ВАС не зможете ввійти. Це не так, як це має працювати. Ви все ще можете вимагати відшкодування збитків, але тим часом ваш кривий клієнт може використовувати програмне забезпечення, скопіювати його в іншому місці (це велика річ, яка не може трапитися з підрядником; якщо він поверне свою будівлю назад, він не повинен турбуватися, що ви Ви зробили точну безкоштовну копію на іншій партії) тощо, тощо. В основному, єдиним засобом захисту є здійснення платежу в повному обсязі, оскільки ви не можете гарантувати, що ви відшкодували всі копії програмного забезпечення. Ви, мабуть, не були б раді повернути ваше програмне забезпечення, навіть якщо ви могли б гарантувати, що у нього більше немає копій; це певна спеціальна робота, яку ви не можете просто розвернути і продати комусь іншому.

Зрозумійте, що незалежно від ваших прав на програмне забезпечення, його дані належать йому. Ви не можете доторкнутися до нього. Ви можете зупинити його доступ до програмного забезпечення, яке ви створили, але якщо ви знищите його дані, це як спалення його володінь після повернення будівлі, яку ви побудували, за яку він не заплатив. Ви не маєте жодного права на ці дані, і повинні або залишити їх на своєму комп’ютері неушкодженими, або якщо дані не можуть бути доступними розумним чином без вашого програмного забезпечення, ви повинні вийняти їх із заплутаного програмного забезпечення та надати його його у корисному форматі (наприклад, базі даних, що споживаються людиною, або друкованими або електронними копіями).

У концепції ви праві. Ваша страта - це все неправильно.

Вам потрібно надати йому пробні ліцензії, термін дії яких закінчується. Після повної оплати надайте йому остаточну ліцензію "назавжди". Всі наперед і чесні.

Ні. Якщо ваші клієнти дізналися, ви би линчили. Це зовсім не безпечно. Хтось, хтось як дізнається, як його запустити, а потім раптом у вас з’явиться завдання зв’язатися з усіма вашими клієнтами, щоб повідомити їм про це і чому вони повинні робити аварійний виправлення.

Якщо ви зламаєте це, ви також відкриваєте кримінальне провадження. Я припускаю, що у вас є докази, що ви все ще є власником сайту? Що ви маєте право на доступ до нього? Вартість його бізнесу може бути "астрономічною"

Є прийнятні альтернативи. Поставте водяний знак на сайті, щоб кожна сторінка відображала повідомлення. Після оплати можна видалити водяний знак.

Це здається феноменально поганою ідеєю, яка потенційно може посадити вас у в'язницю.

1. Це неетично. Погана поведінка вашого клієнта не робить вас правильним для злому їх системи.
2. Це незаконно. Це траплялося і раніше , з поганими наслідками для порушників.
3. Це безглуздо. Що ви, можливо, зробите з цим заднім куточком, який би не потрапив у біду? Ви б шантажували клієнта?
4. Це німо. Навіть якби ви могли це зробити, не потрапляючи, потенційні ризики набагато перевищують будь-який можливий прибуток.

Будь ласка, не запитуйте програмістів, попросіть юриста. Я б припустив, що ви хотіли б включити в свій договір пункт, в якому сказано, що ви маєте право робити те, що передбачає ваше запитання. (Чи не застереження про деякі договори "непоправна шкода" дає вам судове рішення про негайне вимкнення програмного забезпечення, поки суд не має шансів розібратися?) Я думаю, що судовий наказ був би для вас набагато безпечнішим, ніж кодова бомба (що може вважатися злочинним; якщо суд визнав, що ви не володієте програмним забезпеченням, це може бути знищенням майна, в США це може потрапити під порушення розділів цифрового шифрування Закону про цифрове тисячоліття тощо). уявіть собі перемогу відшкодування збитків у цивільному суді та все ще засуджене у кримінальному суді).

Правила будуть різними залежно від того, де ви та ваш клієнт проживаєте та працюєте, тому я дуже думаю, що ви хочете отримати адвоката.

Етично це гарна ідея?

Абсолютно не. Це не тільки змушує вас виглядати непрофесійно на чесних, добросовісних клієнтів, але я відчуваю, що це також згубно для професії в цілому. Інженери програмного забезпечення несуть обов'язки перед своїм клієнтом або роботодавцем, у тому числі постачають програмне забезпечення найвищої якості. Якщо має бути суперечка щодо оплати чи контрактів, є відповідні канали. Зниження якості вашого програмного забезпечення не є відповідним каналом.

Вам, хлопцям, колись доводилося зламати власне програмне забезпечення через подібні проблеми з клієнтом?

Ніколи, хоча я ніколи не робив контрактних чи позаштатних робіт. Я завжди був співробітником більшої організації (яка в деяких випадках працювала за контрактом). Для мене думка немислима. Я б швидше поставив програмне забезпечення, з яким я пишаюся тим, що моє ім'я приписується і обманюється невеликим відсотком клієнтів, ніж знижує якість мого програмного забезпечення, а також мої етичні обов'язки перед користувачами системи.

Будь-які рекомендації щодо цієї ідеї, коду та методу розумні?

Не робіть цього.

Які можуть бути можливі недоліки чи наслідки сценаріїв саморуйнування?

Окрім очевидних етичних питань, я б переймався юридичними проблемами. Я не впевнений, чи саботаж вашої власної роботи законний, і навіть якщо він є, використання такого подвигу може не бути.

Просто реалізуйте модуль ліцензування з обмеженими у часі ліцензіями, які відключать програмне забезпечення після закінчення терміну дії. Це добре відома практика в галузі програмного забезпечення, і ваші клієнти не повинні заперечувати проти цього, оскільки ви усунете обмеження згодом.

Це також може стати в нагоді, коли ви хочете обмежити функції та запропонувати різні версії свого продукту.

Вмикачі просто мають занадто багато ризиків, і цього не варто.

Таємна особливість самознищення - жахлива ідея. Так, ви будете розумними і, можливо, будете мати можливість в майбутньому прив’язати її до жахливого клієнта, але його шлях буде більше клопоту, ніж варто.

1. Ви все одно не отримаєте зарплату за виконану роботу. Так, інша людина не використовуватиме ваш код; але ви все одно будете відчувати відсутність оплати. Ви думаєте, що якийсь злочинець вирішить виплатити людині, яка вже збила їхню ділянку один раз дистанційно? Вони знайдуть новий кубок, щоб зробити свій сайт безкоштовно.

2. Використовуючи послідовність саморуйнування, ви несете відповідальність за власні юридичні проблеми. Залежно від юрисдикції, ви можете легко сприймати як злом / знищення їхніх даних (коли вони збиралися платити і мали чимало пом'якшуючих обставин, чому вони раніше не платили). Навіть якщо ви не засуджені / успішно подані до суду, ви все одно можете стягувати здорові судові збори і мати набагато більше проблем, ніж коштує.

3. Що робити, якщо якийсь хороший клієнт, який платить, перегляне ваш код пізніше (або у нього є друг CS, який просто переглянув його, щоб зробити незначну настройку), побачить функцію із дивною базовою частиною64, це як те, що це, намагається виконати її та випадково видаляє веб-додаток (і чи це, поки ви у відпустці, щоб зайняти певний час)? Або ви публікуєте купу публічних відгуків про вас скрізь, де стверджується, що ви неетичні та залишаєте задом на роботі? Звичайно, ви можете вилучити його з готового продукту після того, як вони заплатять, але за допомогою VCS вони можуть переглядати старі джерела або не хочуть вас на їхньому сервері після того, як вони заплатили (і це буде незручна розмова; так, мені знову потрібен обліковий запис, тому що у мене немає не видалили секрет самозашкодження заднього куточка).

4. Що робити, якщо злочинець створює резервну копію своїх даних? Ви видаляєте їх веб-сервер із секретним заднім кутом, веб-сайт перебуває в режимі офлайн на добу або два, поки вони (або друг) знаходять функцію, що порушує функцію заднього дому, і її назад в Інтернеті.

Надалі змушуйте людей підписувати простий контракт, платити вам поетапно, і не дозволяйте коду залишати сервер розробки та комп’ютер, яким керують лише ви, поки ви не отримаєте оплату. (Якщо їм потрібно, щоб вони були в прямому ефірі до того, як робота закінчиться; переконайтеся, що вони приблизно заплатили за частину коду, що стає в реальному часі). Якщо вони хочуть розглянути роботу як розробку, запропонуйте їм надати кілька IP-адрес, за допомогою яких ви відкриєте брандмауер для свого сервера розробки (і, можливо, з розумним CNAME для ефектуunpaid_work_in_development.example.com). Не дайте гарантій тривалості роботи вашого сервера розробників, і якщо ви отримуєте набагато більше трафіку, ніж ви повинні бути (наприклад, ви виявите, що вони переспрямовують багато людей на ваш сайт), просто закривайте брандмауер, поки вони не оплатять. Якщо їм потрібно надати вміст вашому веб-серверу, змусити їх або надіслати вам електронну пошту із пропозиціями щодо вмісту, або створити для них спільну папку, що має лише доступ, для запису до невеликого підмножини файлів (під управлінням VCS поза папки), що вони може суттєво сприяти (наприклад, HTML-шаблони).

Ви поставили неправильне запитання. Справа над покращенням та вдосконаленням полягає не в тому, щоб додати якийсь вимикач віддаленого вбивства (додавання вразливості, яким ви чи хтось інший може скористатися), а щоб виправити свою справжню проблему, яка була поганим способом організації оплати та доставки. Здається, що вам потрібна краща система депозитування (або як би там не називалося таке поняття, де ви живете).

Не витрачайте час на перемикач на вбивство, з’ясуйте, де ви накрутили частину його ділової угоди.

Я думаю, я б розробив якийсь механізм ліцензування. Це може ґрунтуватися на будь-якій кількості комерційних і домашніх ідей і може призвести до припинення роботи програмного забезпечення після закінчення терміну дії ліцензії. Після того, як система приймається клієнтом, і він заплатив, ви можете надати повну ліцензію, яка не закінчується.

Цей підхід також потребує схвалення юриста на вашій території, але має перевагу в тому, що вам не потрібно віддалено відключати програмне забезпечення, і ви можете встановити, що це є частиною системи перед цим. Однак мені здається дуже сумним, що ти маєш справу з людьми, які відмовляються платити в першу чергу.

Це не називається DRM? Поки ви знімаєте "бомбу" після отримання платежу, я не бачу з цим юридичних проблем. Просто переконайтеся, що у вас є доступний патч, щоб прикрити попу і показати, що у вас не було зловмисних намірів.

Мені це нагадує положення про "отруєння таблетками" у статутних документах деяких компаній, які активуються у разі ворожого поглинання.

На кшталт менталітету, вираженого деякими іншими плакатами, тут нагадує мені, чому деякі програмісти постійно наступають. Якби більше людей ставлять такі бомби у свій код, я думаю, що програмісти можуть отримати більш швидку оплату ... Я б не мав абсолютно жодних проблем, якби це було нормою. Люди люблять красти чужу працю. Період. І якщо Apple, та ін. Чи може DRM захистити свої речі, тоді я думаю, що програмісти-фрілансери теж можуть ...

На практичній записці, безумовно, клієнт перевірить свої журнали, знайде запит на вбивство, відновить код із резервної копії, видалить перемикач на знищення та повторно розгорнеться.

Деталі вашого запитання дають зрозуміти, що це була б абсолютно жахлива ідея. Перший клієнт, який виявив такий перемикач на знищення (можливо, після його використання та відновлення з резервної копії), опублікує перемикач на знищення та факт, що ви включили його у код, який ви їм передали. Тоді ваша репутація буде повністю знищена.

І перш ніж ви скажете "ну, вони були б мертвим битвом, як вони зруйнують мою репутацію?" Розглянемо такий сценарій: Замовник перебуває в доброму стані, але один з їх співробітників бере копію коду. Вони звільняють цього співробітника, він дивиться на код, з'ясовує перемикач на вбивство та використовує його. Здогадайтесь, хто винен у цьому? (Підказка: Це ти.)