Czy powinienem dołączyć do swoich aplikacji metodę autodestrukcji?

Niedawno miałem negatywne doświadczenia, gdy klient został zwolniony z rachunku, ale mój pośrednik już przesłał nasze oprogramowanie i projekt na serwer klienta. Klient okazał się znanym przestępcą i oczywiście zmienił wszystkie możliwe hasła serwera.

Nadal jednak mogę uzyskać dostęp do panelu administracyjnego CMS. Niestety okazuje się, że moje oprogramowanie jest bardzo bezpieczne. Próbowałem wstrzyknąć SQL, sfałszować przesyłanie obrazu itp. Jednak nie mogę włamać się do własnego oprogramowania. W każdym razie przygotowuję się do pozwania tej osoby, więc to nie jest problem .. Właśnie myślę teraz, że może powinna istnieć jakaś metoda autodestrukcji wewnętrznej bazy danych. Jeśli więc wystąpi podobny przypadek, mam opcję zabicia oprogramowania.

Mój własny pomysł polega na ukryciu niektórych funkcji w podstawowych plikach. Zakoduj go przy użyciu base64, aby nie było to oczywiste. Więc coś takiego:

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

Zasadniczo stwórz mały skrypt, który pobiera wszystkie pliki oprogramowania, aby je upewnić, a następnie usuwa je.
Wszystkie moje nowsze wersje CMS-a mają menedżerów plików, których mogłem użyć do łatwiejszego hakowania . Ale co, jeśli dostęp do panelu administracyjnego jest ograniczony.

Aby być bardzo jasnym , jest to przeznaczone tylko dla oprogramowania na etapie programowania, na moim osobistym serwerze lub serwerze klienta (ostatnia część jest etycznie wątpliwa). Więc jeśli mój klient powinien ukraść moje oprogramowanie .. Nie będzie to uwzględnione w reklamie -oprogramowanie.
Aby jeszcze bardziej wyjaśnić , mówimy o tych rzadkich zleceniach zewnętrznych. Myślę, że to dość logiczne, że praca najemna nie potrzebuje takich metod. Mówimy więc o tych klientach jumprisk, tylko w trybie programistycznym - kiedy projekt jest gotowy, oczywiście byłoby to bardzo nieetyczne wyjście z twojego oprogramowania.

1. Czy etycznie jest to dobry pomysł? (Pamiętając, że oczywiście go usunę, gdy projekt zostanie wykonany w 100% i za wszystko zapłacono)
2. Czy kiedykolwiek musieliście włamać się do własnego oprogramowania z powodu podobnych problemów z klientem (klientami)?
3. Wszelkie zalecenia dotyczące tego pomysłu, kodu i metody są mądre?
4. Jakie mogą być wady lub reperkusje skryptów autodestrukcji?

Mój wniosek w tej sprawie

Jest trochę smutne, że wszystkie odpowiedzi dotyczyły zakontraktowanych spraw. To naprawdę moja wina, że ​​nie uściśliłem tego w moim pytaniu ... po prostu pomyślałem, że jest całkiem jasne, że przełącznik zabijania nie ma sensu ... kiedy jesteś chroniony przez umowę.
Jeśli jednak wykonujesz pracę na podstawie umowy ... należy to zaznaczyć w umowie - dzięki temu jest to legalne, nawet w obrębie własnego serwera klienta. Jednak posiadanie przełączników typu „kill-switch” na moim osobistym serwerze to naprawdę sprawa nobodies (właśnie tego chciałem wiedzieć).

Postanowiłem stworzyć skrypt kill-switch dla mojego CMS. Głównie dlatego, że wydaje się to ciekawym wyzwaniem. Ale także, że mógłbym użyć tego do moich niezakontraktowanych prac, w których klient jest przyjacielem przyjaciela znajomego. Prawdopodobnie nie użyję tego na serwerze klienta, ale ... w przypadkach, gdy klient lub niektóre pośrednicy mają dostęp do mojego serwera. A moje oprogramowanie zostaje skradzione lub „przeniesione bez mojej wiedzy”, wtedy nie dostaję zapłaty, a oni ograniczają dostęp do oprogramowania.

Przeczytałem tutaj wiele tematów, w których zalecają wysłanie ostrzeżenia, a następnie zdjęcie strony. Cóż, widziałem w tym problem, jak wtedy, gdy mam do czynienia z osobą ... która po prostu skopiuje go w inne miejsce (być może przeprojektuje i sprzedaje) i mówi mi, że został usunięty. Nie chciałbym też „wyłączać strony”, ale ją usuwać. Chociaż myślę, że nadal jest nielegalny dostęp do serwera moich klientów i jego usunięcie. Lub przynajmniej dostęp do niego przez backend, a nie z FTP. Za to dziękuję wszystkim, którzy odpowiedzieli.

Nie jestem prawnikiem. Wygląda na to, że już go masz, aby pozwać klienta; dopóki masz go na utrzymaniu, zaleciłbym uzyskanie porady na ten temat.

Na tej stronie znajdują się inne pytania dotyczące „wyłączników awaryjnych” i innych sposobów wyłączania oprogramowania, za które deweloper nie otrzymał odszkodowania. Zwykle uważa się za zły pomysł po prostu wbudować je w oprogramowanie „pod klucz” (w którym je rozwiniesz, a następnie przekażesz pełne prawa klientowi), bez umowy przewidującej taką możliwość.

Po pierwsze, jeśli twoja umowa nie określa wyraźnie, że możesz wyłączyć oprogramowanie z powodu braku płatności lub że klient nie ma żadnych praw do oprogramowania, dopóki płatność nie zostanie odebrana w całości, nie możesz przełączyć żadnego „przełącznika zabijania” bez naruszanie umowy. Brak jakichkolwiek przeciwnych słów: „posiadanie to dziewięć dziesiątych prawa”, więc jest to jego oprogramowanie, gdy przejmie je w posiadanie, i zniszczenie go byłoby podobne do dynamizacji nowego biurowca, który dla niego zbudowałbyś, gdyby tego nie zrobił za to zapłacić.

Następuje drugi punkt; każda umowa, którą zaoferujesz klientowi, powinna zawierać klauzulę, która brzmi: „Przeniesienie własności intelektualnej po spełnieniu warunków umowy” . Oznacza to, że nawet jeśli dałeś mu kopię oprogramowania do użycia, dopóki nie zapłaci ci w całości, nie jest jej właścicielem. Dałoby to Ci prawo do wyłączenia jego lub dowolnej kopii oprogramowania z dowolnego powodu, dopóki nie zostanie otrzymana pełna płatność, ponieważ nadal należy do Ciebie i możesz robić, co chcesz. Teraz naruszył umowę, a ty tego nie zrobiłeś, więc sprawa jest o wiele łatwiejsza dla twojego prawnika, a tymczasem twój klient nie korzysta z jego źle zdobytych towarów.

Analogia do wykonawcy budowlanego jest taka: gdy budynek w budowie można zabezpieczyć przed nielegalnym wejściem, jest on, a wykonawca na ogół zachowa wszystkie kopie wszystkich kluczy do lokalu, dopóki prace nie zostaną ukończone i podpisane, oraz płatność otrzymana w całości. Nawet po wydaniu kluczy, jeśli płatność wpłynie, może on zastawić nieruchomość, a w skrajnym przypadku odzyskać ją. To samo dotyczy tutaj; możesz dać klientowi klucz, aby dostać się do oprogramowania, ale masz klucz „główny”, a on nie uzyska dostępu administracyjnego, dopóki nie otrzymasz pełnej zapłaty. Jeśli teraz może wejść i nie płaci, możesz po prostu „zmienić blokady” i zablokować go w oprogramowaniu.

Dałeś jednak swojemu klientowi „główny” klucz do oprogramowania, a on zniknął i zmienił wszystkie blokady, więc teraz nie możesz się dostać. To nie tak powinno działać. Nadal możesz dochodzić roszczeń odszkodowawczych, ale w międzyczasie twój nieuczciwy klient może korzystać z oprogramowania, kopiować go w innym miejscu (to duża rzecz, której nie może spotkać wykonawca; jeśli zabierze swój budynek z powrotem, nie musi się martwić, że ty wykonałem dokładną bezpłatną kopię na innej partii) itp. Zasadniczo jedynym rozwiązaniem jest wyegzekwowanie płatności w całości, ponieważ nie możesz zagwarantować, że odzyskałeś wszystkie kopie oprogramowania. Prawdopodobnie nie byłbyś zadowolony z odzyskania oprogramowania, nawet gdybyś mógł zagwarantować, że nie będzie miał dalszych kopii; to prawdopodobnie niestandardowa praca, której nie można po prostu odwrócić i sprzedać komuś innemu.

Zrozum, że niezależnie od twoich praw do oprogramowania, jego dane należą do niego. Nie możesz tego dotknąć. Możesz zatrzymać jego dostęp do oprogramowania, które zbudowałeś, ale jeśli zniszczysz jego dane, to tak, jak spalenie jego mienia po naprawieniu budynku, który zbudowałeś, za który nie zapłacił. Nie masz żadnych praw do tych danych i musisz albo pozostawić je nienaruszone na swoim komputerze, albo jeśli dane nie mogą być dostępne w rozsądny sposób bez twojego oprogramowania, musisz usunąć je z uwikłania w swoje oprogramowanie i przekazać go w użytecznym formacie (takim jak baza danych do użytku przez ludzi lub kopie drukowane lub elektroniczne).

W koncepcji masz rację. Twoje wykonanie jest złe.

Musisz dostarczyć mu licencje próbne, które wygasają. Po pełnej zapłaty daj mu ostateczną licencję „na zawsze”. Wszystko z góry i szczerze.

Nie. Jeśli Twoi klienci się dowiedzą, zostaniesz zlinczowany. To wcale nie jest bezpieczne. Ktoś, niektórzy dowiedzą się, jak go uruchomić, a potem nagle musisz skontaktować się ze wszystkimi klientami, aby im powiedzieć o tym i dlaczego muszą zrobić łatkę awaryjną.

Jeśli go włamiesz, otworzysz się również na postępowanie karne. Zakładam, że masz dowód, że nadal jesteś właścicielem witryny? Czy masz prawo dostępu do niego? Koszt jego działalności może być „astronomiczny”

Istnieją akceptowalne alternatywy. Umieść znak wodny na stronie, aby każda strona wyświetlała komunikat. Po dokonaniu płatności możesz usunąć znak wodny.

To wydaje się fenomenalnie złym pomysłem, który może potencjalnie doprowadzić cię do więzienia.

1. To nieetyczne. Złe zachowanie klienta nie powoduje, że włamujesz się do jego systemu.
2. To nielegalne. Stało się to wcześniej , przy złych wynikach dla stron naruszających prawo.
3. To bezcelowe. Co byś zrobił z tym backdoorem, który nie sprawiłby ci kłopotów? Czy szantażowałbyś klienta?
4. To jest głupie. Nawet jeśli możesz to zrobić, nie dając się złapać, potencjalne ryzyko znacznie przewyższa wszelkie możliwe zyski.

Proszę nie pytać programistów, pytać prawnika. Wyobrażam sobie, że przynajmniej chcesz zawrzeć klauzulę w umowie, mówiącą, że masz prawo robić to, co rozważa twoje pytanie. (Czy klauzula „nieodwracalnej szkody” niektórych umów nie pozwala na natychmiastowe zamknięcie oprogramowania do czasu, aż sąd będzie miał szansę go rozwiązać?) Myślę, że orzeczenie sądowe byłoby dla ciebie o wiele bezpieczniejsze niż bomba kodowa (która może zostać uznana za przestępczą, jeśli sąd uzna, że ​​nie posiadasz oprogramowania, może to być zniszczenie mienia, w Stanach Zjednoczonych może on podlegać łamanym sekcjom dotyczącym szyfrowania cyfrowego ustawy Digital Millennium Act itp.) wyobraź sobie, że wygrywasz odszkodowanie w sądzie cywilnym i nadal jesteś skazany w sądzie karnym).

Zasady będą się różnić w zależności od tego, gdzie ty i twój klient mieszkacie i działacie, więc naprawdę uważam, że chcielibyście mieć prawnika.

Czy etycznie jest to dobry pomysł?

Absolutnie nie. Nie tylko sprawia, że ​​wyglądasz nieprofesjonalnie dla uczciwych, uczciwych klientów, ale uważam, że jest to również szkodliwe dla całego zawodu. Inżynierowie oprogramowania mają obowiązek wobec swojego klienta lub pracodawcy, w tym dostarczanie oprogramowania najwyższej jakości. W przypadku sporu dotyczącego płatności lub umów istnieją odpowiednie kanały. Obniżanie jakości oprogramowania nie jest odpowiednim kanałem.

Czy kiedykolwiek musieliście włamać się do własnego oprogramowania z powodu podobnych problemów z klientem (klientami)?

Nigdy, chociaż nigdy nie pracowałem na podstawie umowy lub pracy na własny rachunek. Zawsze byłem pracownikiem większej organizacji (która w niektórych przypadkach pracowała na podstawie umowy). Dla mnie ta myśl jest nie do pomyślenia. Wolę dostarczać oprogramowanie, z którego jestem dumny, że moje imię zostało przypisane i zostać oszukanym przez niewielki procent klientów, niż obniżać jakość mojego oprogramowania, a także moje obowiązki etyczne wobec użytkowników systemu.

Wszelkie zalecenia dotyczące tego pomysłu, kodu i metody są mądre?

Nie rób tego

Jakie mogą być wady lub reperkusje skryptów autodestrukcji?

Oprócz oczywistych kwestii etycznych martwiłbym się problemami prawnymi. Nie jestem pewien, czy sabotowanie własnej pracy jest legalne, a nawet jeśli jest, użycie takiego exploita może nie być.

Wystarczy wdrożyć moduł licencyjny z ograniczonymi czasowo licencjami, które wyłączą oprogramowanie po wygaśnięciu. Jest to dobrze znana praktyka w branży oprogramowania i Twoi klienci nie powinni się temu sprzeciwiać, ponieważ później usuniesz ograniczenie.

Może się to również przydać, gdy chcesz ograniczyć funkcje i zaoferować różne wersje swojego produktu.

Przełączniki zabijania mają po prostu zbyt wiele zagrożeń i nie są tego warte.

Sekretna funkcja samozniszczenia jest przerażającym pomysłem. Tak, będziesz sprytny i być może będziesz miał okazję przykleić go do okropnego klienta w przyszłości, ale jest to o wiele więcej kłopotów niż wartości.

1. Nadal nie otrzymasz zapłaty za wykonaną pracę. Tak, inna osoba nie będzie używać Twojego kodu; ale nadal będziesz cierpieć z powodu braku płatności. Myślisz, że jakiś przestępca zdecyduje się zdalnie zapłacić osobie, która już sprowadziła swoją stronę? Znajdą nowego gościa, aby zrobić swoją stronę za darmo.

2. Wykorzystanie sekwencji autodestrukcji powoduje, że ponosisz odpowiedzialność za własne problemy prawne. W zależności od jurysdykcji z łatwością można cię postrzegać jako hakowanie / niszczenie ich danych (kiedy mieli zapłacić i mieli wiele okoliczności łagodzących z powodu tego, dlaczego nie zapłacili wcześniej). Nawet jeśli nie zostaniesz skazany / nie zostaniesz skutecznie pozwany, nadal możesz ponieść wysokie koszty prawne i mieć znacznie więcej kłopotów niż jest to warte.

3. Co się stanie, jeśli jakiś dobrze płatny klient przejrzy Twój kod później (lub ma przyjaciela CS, który właśnie go przejrzał, aby wykonać drobne poprawki), widzi funkcję z dziwną częścią base64, jest podobny do tego, próbuje to wykonać i przypadkowo usuwa aplikację internetową (i robi to podczas wakacji, więc naprawa zajmuje trochę czasu)? A może publikujesz na całym świecie kilka publicznych recenzji o tobie, że jesteś nieetyczny i zostawiasz tylne drzwi w swojej pracy? Jasne, że możesz usunąć go z gotowego produktu po zapłaceniu, ale za pomocą VCS mogą przeglądać starsze źródła lub nie chcieć cię na swoim serwerze po zapłaceniu (i to byłaby niezręczna rozmowa; tak, potrzebuję konta ponownie, bo nie mam usunął tajny backdoor samozniszczenia).

4. Co się stanie, jeśli przestępca utworzy kopię zapasową swoich danych? Usuwasz ich serwer sieciowy za pomocą tajnego backdoora, witryna jest offline przez dzień lub dwa, podczas gdy on (lub znajomy) znajduje funkcję backdoora i jego powrót do trybu online.

W przyszłości zachęć ludzi do podpisania prostej umowy, płacenia etapami i nie pozwól, aby kod opuścił serwer programistyczny i komputer, który tylko Ty kontrolujesz, dopóki nie otrzymasz zapłaty. (Jeśli potrzebują, aby zostało uruchomione przed ukończeniem całej pracy; upewnij się, że zapłacili mniej więcej za ułamek kodu, który staje się dostępny). Jeśli chcą, aby praca była w trakcie opracowywania, niech podadzą ci kilka adresów IP, które otworzysz zaporę dla twojego serwera rozwoju (i być może ze sprytnym CNAME z efektemunpaid_work_in_development.example.com). Nie dawaj żadnych gwarancji dostępności serwera deweloperskiego, a jeśli otrzymujesz znacznie większy ruch, niż powinieneś (np. Przekonasz się, że przekierowują wiele osób do Twojej witryny), po prostu zamknij zaporę ogniową, dopóki nie zapłacą. Jeśli muszą wnieść zawartość do twojego serwera WWW, poproś, aby wysłał Ci e-mailem z sugestiami dotyczącymi treści, lub utwórz folder współdzielony Dropbox dla nich, który ma uprawnienia tylko do zapisu w małym podzbiorze plików (pod kontrolą VCS poza Dropbox) może znacząco przyczynić się do (np. szablonów HTML).

Zadałeś złe pytanie. Rzeczą, nad którą należy popracować i poprawić, nie jest dodanie jakiegoś zdalnego przełącznika zabijania (dodanie podatności, z której ty lub ktoś inny możesz skorzystać), ale naprawienie twojego prawdziwego problemu, który był kiepskim sposobem zorganizowania płatności i dostawy. Wygląda na to, że potrzebujesz lepszego systemu depozytowego (lub jakiejkolwiek takiej koncepcji nazywa się miejsce zamieszkania).

Nie marnuj czasu na wyłącznik awaryjny, dowiedz się, gdzie spieprzyłeś część umowy biznesowej.

Myślę, że opracowałbym jakiś mechanizm licencjonowania. Może to być oparte na dowolnej liczbie pomysłów komercyjnych lub domowych i może spowodować, że oprogramowanie przestanie działać po wygaśnięciu licencji. W momencie, gdy system jest akceptowany przez klienta i zapłacił, możesz podać pełną licencję, która nie wygasa.

Takie podejście wymaga również zgody prawnika na twoim terytorium, ale ma tę zaletę, że nie musisz zdalnie wyłączać oprogramowania i możesz zastrzec, że jest to część systemu wcześniej. Jednak wydaje mi się bardzo smutne, że masz do czynienia z ludźmi, którzy w ogóle nie chcą płacić.

Czy to nie nazywa się DRM? Tak długo, jak usuniesz „bombę” po otrzymaniu płatności, nie widzę z nią problemu prawnego. Po prostu upewnij się, że masz łatkę, która jest łatwo dostępna, aby zakryć twój tyłek i pokazać, że nie masz złych zamiarów.

Przypomina mi przepis „pigułka trucizny” w aktach założycielskich niektórych firm, które są aktywowane w przypadku wrogiego przejęcia.

Innymi słowy, mentalność wyrażona przez niektóre inne plakaty tutaj przypomina mi, dlaczego niektórzy programiści są tak często narzucani. Jeśli więcej osób umieści takie bomby w swoim kodzie, myślę, że programiści mogliby otrzymać wynagrodzenie szybciej ... Nie miałbym absolutnie żadnego problemu, gdyby to była norma. Ludzie lubią kraść ciężką pracę innych ludzi. Kropka. A jeśli Apple i in. mogę DRM do cholery z ich rzeczy, to myślę, że niezależni programiści też ...

Praktycznie rzecz biorąc, z pewnością klient sprawdzi swoje dzienniki, znajdzie żądanie zabicia, przywróci kod z kopii zapasowej, usunie przełącznik zabicia i ponownie wdroży.

Szczegóły twojego pytania wyjaśniają, że byłby to absolutnie okropny pomysł. Pierwszy klient, który odkryje taki przełącznik zabijania (prawdopodobnie po jego użyciu i odzyskaniu go z kopii zapasowej) opublikuje przełącznik zabijania i fakt, że umieściłeś go w dostarczonym mu kodzie. Twoja reputacja zostałaby wtedy całkowicie zniszczona.

I zanim powiesz „no cóż, byliby śmiertelni, jak zniszczą moją reputację?” Rozważmy taki scenariusz: klient ma dobrą opinię, ale jeden z jego pracowników bierze kopię kodu. Zwalniają tego pracownika, on patrzy na kod, wymyśla przełącznik zabijania i używa go. Zgadnij, kto ponosi winę? (Wskazówka: to ty.)